[Fixed] [GZDoom 4.0.0] Glitchy rendering with FXAA on

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

[GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby Cacodemon345 » Tue Apr 09, 2019 11:58 pm

Turning on FXAA will cause the rendering to be glitched like this:
Image
Tested with a AMD Radeon RX 460.
Cacodemon345
 
Joined: 22 Dec 2017
Discord: Cacodemon345#9151
Github ID: Cacodemon345
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby dpJudas » Wed Apr 10, 2019 8:11 am

Are you seeing this only with FXAA or does other postprocessing effects cause similar effects?
dpJudas
 
 
 
Joined: 28 May 2016

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby Cacodemon345 » Wed Apr 10, 2019 8:11 am

dpJudas wrote:Are you seeing this only with FXAA or does other postprocessing effects cause similar effects?
Only FXAA, so far.
Cacodemon345
 
Joined: 22 Dec 2017
Discord: Cacodemon345#9151
Github ID: Cacodemon345
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby dpJudas » Wed Apr 17, 2019 2:58 pm

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
 
 
 
Joined: 28 May 2016

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby Cacodemon345 » Thu Apr 18, 2019 4:23 am

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.
Cacodemon345
 
Joined: 22 Dec 2017
Discord: Cacodemon345#9151
Github ID: Cacodemon345
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby MasterBeavis » Sat May 18, 2019 2:00 am

Postprocessing is causing allot of issues for me
User avatar
MasterBeavis
 
Joined: 13 May 2019
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby Batandy » Mon Jun 03, 2019 2:01 pm

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

GPU: RX 580, CPU: AMD FX 8320

If you want me to test anything i'm here.
User avatar
Batandy
"If it's not fun, why bother?"
 
Joined: 19 Jul 2011

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby dpJudas » Mon Jun 03, 2019 2:26 pm

@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?
dpJudas
 
 
 
Joined: 28 May 2016

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby MasterBeavis » Mon Jun 03, 2019 7:01 pm

Im getting exactly what Batandy is getting and if you turn on anything else in PP it gets worse. no halos though
User avatar
MasterBeavis
 
Joined: 13 May 2019
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby _mental_ » Tue Jun 04, 2019 3:36 am

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_
 
 
 
Joined: 07 Aug 2011

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby Graf Zahl » Tue Jun 04, 2019 3:40 am

_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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby dpJudas » Tue Jun 04, 2019 8:13 am

_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. :)
dpJudas
 
 
 
Joined: 28 May 2016

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby Graf Zahl » Tue Jun 04, 2019 8:29 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby _mental_ » Tue Jun 04, 2019 9:03 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [GZDoom 4.0.0] Glitchy rendering with FXAA on

Postby dpJudas » Tue Jun 04, 2019 10:14 am

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.
dpJudas
 
 
 
Joined: 28 May 2016

Next

Return to Closed Bugs

Who is online

Users browsing this forum: Bing [Bot], MSN [Bot], Semrush [Bot] and 1 guest