tobbebex
Buffer writes not happening in the right order
I have some code like this:
-- RenderObjects existentially quantify their uniform/shader values
renderObject :: RenderObject os -> GLFWContext os ()
renderObject r = case r of
RenderObject shader chunks -> render $ renderAction shader chunks
RenderObjectUniforms uniform uValue shader chunks -> do
writeBuffer uniform 0 [uValue]
render $ renderAction shader chunks
RenderObjectUniformReference uniform uValueRef shader chunks -> do
uValue <- liftIO uValueRef
writeBuffer uniform 0 [uValue]
render $ renderAction shader chunks
-- inside the render loop:
do
writeBuffer viewmatrixBuffer 0 . pure $ matrix
render $ do
clearWindowColor win (V4 0.05 0.10 0.15 1.0 :: Fractional b => V4 b)
clearWindowDepth win 1
renderObject `mapM_` renderObjs
swapWindowBuffers win
When using a uniform to position the rendered objects, they flicker around wildly and overlap, presumably due to the buffer writes within the renderObject calls not necessarily being run before their respective render calls execute. I've only tried this code on one computer, so it might be related to the specific graphics drivers I'm using; I really have no clue.
Are you still having this issue?
It looks like your renderObject function could write uniform data or render arbitrary objects depending on the constructor of RenderObject os. This could perhaps create the behavior you're describing depending on the order of elements in your renderObjs list (and the constructors used)?
Yeah, this was used to maintain a list of render objects, some with uniform information attached, that were rendered every frame. But even in cases where the same list of items in the same order was being used to render things across many frames the flickering still happened. Certainly some render objects could inherit the uniforms of a prior render object that set them, but as far as I can tell an individual chunk of geometry wouldn't flicker back and forth between two positions unless the uniforms writes were untethered from the specific shader call.
I eventually switched over to development on a different computer, and there the bug stopped occurring at all, so I'm assuming the root case was some combination of default linux video drivers, poorly-installed video drivers, and an old computer, so ultimately something a bit beyond the scope of GPipe itself.