ZDoom

Turning on FXAA will cause the rendering to be glitched like this:

Tested with a AMD Radeon RX 460.

Are you seeing this only with FXAA or does other postprocessing effects cause similar effects?

dpJudas wrote:Are you seeing this only with FXAA or does other postprocessing effects cause similar effects?

Only FXAA, so far.

Finally got around to test this. It doesn't happen on my computer.

Which operating system are you using?

Also, I could use some help from someone with an AMD card to try FXAA and report back. Need to narrow down what the conditions are for this to happen.

dpJudas wrote: Which operating system are you using?

It happens with both Windows 10 and Windows 7.
Edit: Turning off Bloom postprocessing fixes the glitched rendering a bit, only the weapon sprites are affected.

Postprocessing is causing allot of issues for me

It's happening to me as well, FXAA set to low:


GPU: RX 580, CPU: AMD FX 8320

If you want me to test anything i'm here.

@Batandy: if you turn on dynamic lights and play E1M1 like Cacodemon did, are you also getting halos around the light sources? And is it also isolated to only being FXAA or does other postprocess effects create similar effects?

Im getting exactly what Batandy is getting and if you turn on anything else in PP it gets worse. no halos though

Fixed in addcad8.

Just out of curiosity, why do we have "Vulkan" in DFrameBuffer::gl_vendorstring instead of actual vendor?
Disabled discard seems to have zero influence on performance, so it's not a big deal anyway.

_mental_ wrote: Disabled discard seems to have zero influence on performance, so it's not a big deal anyway.

That entirely depends on the hardware. When I tested this on an Intel HD 4000 the difference between a shader with and without 'discard' was roughly 50%, this was why it was made optional, i.e. on OpenGL it should only be active when really needed.

_mental_ wrote:Just out of curiosity, why do we have "Vulkan" in DFrameBuffer::gl_vendorstring instead of actual vendor?

Mostly because I didn't quickly find the right field in the vulkan device properties at the time. You're welcome to map it up to the correct field if you know which matches.

I wonder why this fix works. Did the GLSL compiler miscompile? Does the AMD driver have a bug? Did the removal of the discard simply mean all the pixels now finish simultaneously and by doing so hides a bug in an image pipeline barrier? I have a feeling this bug may return - we'll see in time I guess.

My guess would be that NVidia has a lot mess involving image layouts and transitioning. I wouldn't be surprised if AMD needed some specific layouts for this to work.

dpJudas wrote:Mostly because I didn't quickly find the right field in the vulkan device properties at the time. You're welcome to map it up to the correct field if you know which matches.

I mapped three well-known vendor IDs to their corresponding names.

dpJudas wrote:I wonder why this fix works. Did the GLSL compiler miscompile? Does the AMD driver have a bug? Did the removal of the discard simply mean all the pixels now finish simultaneously and by doing so hides a bug in an image pipeline barrier?

I have no idea what happens in their drivers. All I know is the glitch was caused by these lines. Complete removal of this block fixes the problem as well.

I found the reason for why removing the discard keyword made a difference.

According to PPFXAA::Render the output is a new frame buffer - not the original. The discard therefore leaves a gap in the new one.

As an optimization, the vulkan backend tells the driver it can safely discard the old contents when doing the image transition as we will be overwriting it anyway. I strongly suspect most image transitions do nothing on NVidia, which means the original contents were probably just the contents from last render (like with the OpenGL backend). AMD, on the other hand, took advantage of the hint and decided not to transition the image, leaving more chaotic pixels behind.

In other words: the rendering glitch is technically there also on NVidia and OpenGL - we just never noticed it as the old pixels were correct enough.