Stipple (aka Dither) Shader

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Stipple (aka Dither) Shader

Re: Stipple (aka Dither) Shader

by drfrag » Tue Oct 09, 2018 2:29 pm

Probably but then they could disable it. On my GT 710 i get the same performance with it enabled. I find curious that the difference is noticeable on my CRT.
Any clues on why the texture version doesn't work? Thanks.

Re: Stipple (aka Dither) Shader

by Rachael » Tue Oct 09, 2018 2:26 pm

It's a bad idea to do the static array version. Intel processors do not handle that gracefully, anyone activating it will suffer a massive FPS drop. It's better to not have it at all, than to have a half-finished version.

Re: Stipple (aka Dither) Shader

by drfrag » Tue Oct 09, 2018 2:22 pm

Sorry for the bump but finally i've ported this to LZDoom, the static array not the texture version. It could go into the vintage build as well.
The texture version doesn't work, i guess that one requires hw_postprocess. In any case i don't know how to specify the layout for the DitherTexture outside of the shader.
I've found a minor problem: the texunit parameter for BindDitherTexture is not used.

It's here:
https://github.com/drfrag666/gzdoom/com ... 007e7a3285
https://github.com/drfrag666/gzdoom/commits/dither2

Re: Stipple (aka Dither) Shader

by Graf Zahl » Sun Aug 12, 2018 2:35 am

I'm wondering if using a uniform buffer for the dither table may be better than a texture. That should be the most straightforward way to provide raw data.

Re: Stipple (aka Dither) Shader

by Marisa the Magician » Wed Aug 08, 2018 4:54 am

I get the same FPS with dither and without dither on my 1060. :S

Re: Stipple (aka Dither) Shader

by dpJudas » Wed Aug 08, 2018 3:37 am

Yeah, it will get a switch - no worries.

About the performance, I could actually measure a minor speed improvement even on my NV 980, so apparently all GPU's are teh suck when it comes to static arrays. Bit surprised about that, but hey, learn something every day. :)

About the texture format and Vulkan, the present shader is highly related to the postprocess system and the general swap chain. Postprocess already creates textures of various exotic formats and its texture management for Vulkan should be able to handle this texture as well. I don't utilize the general abstraction I created there yet mostly because I need to see exactly how our interaction with the swap chain ends up. Basically I don't think we will have to special handle the dither texture in the long run - whatever code we end up managing postprocess stuff should be able to handle it.

Re: Stipple (aka Dither) Shader

by Graf Zahl » Wed Aug 08, 2018 1:44 am

It's called "unfinished business" and definitely needs a switch.
To be honest, when it got merged to master by accident that should have been reverted ASAP.

Re: Stipple (aka Dither) Shader

by _mental_ » Wed Aug 08, 2018 1:24 am

So, this feature may have some performance issues (implementation dependent but still), and it's enabled by default and cannot be disabled, and it improves the picture in so subtle way that it's quite hard to notice the effect, right? Sorry if I'm missing something, but why?
It's OK to have an optional feature that unusable with particular hardware for some reason. In my opinion, however, this one is not that kind of feature and moreover it's not optional.

Re: Stipple (aka Dither) Shader

by Graf Zahl » Wed Aug 08, 2018 12:28 am

Regarding the texture...

Great, that's another useless complication for Vulkan, considering how messy texture creation on Vulkan is, and this one not quite being that compatible to the standard formats of the texture manager. Is this only a problem on older Intels or on all of them? The mentioned HD 4600 is not quite the latest model.

Re: Stipple (aka Dither) Shader

by Graf Zahl » Wed Aug 08, 2018 12:08 am

Pixel Eater wrote:which came built in to a late 2013 iMac.

In that case the fault probably lies with Apple. Their GL implementation predates any sane standard for calculation intensive features.

Re: Stipple (aka Dither) Shader

by Pixel Eater » Tue Aug 07, 2018 6:07 pm

In my case it's an Nvidia GeForce GT 755m 1024mb, which came built in to a late 2013 iMac.

Re: Stipple (aka Dither) Shader

by dpJudas » Tue Aug 07, 2018 4:27 pm

Okay so the conclusion here is that Intel can only do texture sampling fast. Why am I not surprised. Their hardware has always been shit and seems it is going to stay that way, too.

Re: Stipple (aka Dither) Shader

by Pixel Eater » Tue Aug 07, 2018 4:18 pm

Texture lookup was a lot faster when I ported the software fuzz into RetroSpectre. It went from ~50ms lag to ~2ms.
Looking forward to trying this shader out!

Re: Stipple (aka Dither) Shader

by Rachael » Tue Aug 07, 2018 3:06 pm

I changed it to a #define, and pushed it, but still no speed difference. It's shit on the Intel.

Re: Stipple (aka Dither) Shader

by dpJudas » Tue Aug 07, 2018 2:40 pm

I did not rule out the possibility texture sampling could be competitive to the array lookup mostly because texture sampling is so common that GPUs have special silicon and instructions dedicated for precisely this purpose. Especially very old GPUs were terrible at anything with integers in it. There a texture sampling could very well beat the array version as it could be done entirely with floating point instructions.

It is sort of like when you compare the performance between clamp(x, 0.0, 1.0) and max(x, 0.0). The clamp version is faster, especially on older hardware, because there's a dedicated saturate instruction. Same kind of thing can apply for texture stuff. But nowadays, with compute shaders and CUDA, I don't think a texture sampling can beat the static array unless the array is very large (won't fit into local workgroup memory). Even if it does still beat it, the speed difference would most likely be insignificant. The static array version is much easier to maintain and thus wins per default if all other things are in the same ballpark.

About the static array initialization, make sure you don't use that second static variable as input into the first one (change it to a define). I wouldn't put it past the dumbest compilers to then conclude it isn't a constant expression and have it initialize the table on each invocation.

Top