Nvidia - unsigned integer issues

-

Yesterday I experienced another bunch of fun while using my laptop. My normal working environment is a desktop with an AMD graphics card, while choosing a laptop it was important for me to get some Nvidia GPU so I could test code on both machines. This was a smart decision as there are so many differences between them. This time I encounter another one.

History

Like always a little bit of the background: while doing tooling you need to think about nice interactive objects selections. The beginning was rough as I decided to use a physics ray-trace system to execute picking. This was a simple system where I was sanding a ray thru the world and tried to pick objects that collide with it. 

The issue was:

  • every object needed to have a collision body 
  • it did not work very well with objects that had an alpha mask 
  • did not support geometry that was deformed in shaders.
I did not like any of these limitations so I decided one day to change the whole thing. I took this time a different approach. I added a GBuffer of type uint where I storing ID of the object.

With a little bit of struggle with retrieving data from GPU, I finally had a working system. It resolved all the problems that I had with the old one and added a few new ones. This was:

  • filling this new GBuffer in the shader, 
  • retrieving data on CPU, 
  • the issue with selecting objects that are behind the selected objects (I just do not do this).
In the end, nothing is really critical but as you can see nothing is only cupcakes and rainbows. 

Thanks to this system I also could do a rendering of selection. I just sacrificed one bit of ID and used it as info if the object is selected or not. This way I can highlight it nicely using this shader code:


uvec4 pix = texelFetch(texMrt1, ivec2(gl_FragCoord.xy), 0);
if (pix & (1<<31) == 0)
    discard;
return vec4(1.0, 1.0, 0.0 ,0.5);

and that worked nice: 


Sadly it is pretty visually obstructive, so I decided to improve it and add an outline. This worked well and it was super easy. I just compare if neighbor values are the same as the ones we testing and if they are not rendered more intense color.



Problem

This is the place where the real story starts. The above screenshot is taken from AMD Radeon R9 390 where everything looks great. On other hand my laptop with Nvidia GTX 1660 Ti gave me a super weird result:


Because it is always easier to investigate stuff on a smaller scale I decided to do scanning only by testing one direction. 



uvec4 pix = texelFetch(texMrt1, ivec2(gl_FragCoord.xy), 0);
if (pix & (1<<31) == 0)
    discard;

uvec4 pixLeft = texelFetch(texMrt1, ivec2(gl_FragCoord.xy)-ivec2(1,0), 0);
if (pix.x != pixLeft.x)
    return vec4(1.0, 1.0, 0.0 ,0.5);

return vec4(1.0, 1.0, 0.0 ,0.2);

This still resulted in the same effect:  


Now the weird part is that if I replace   

if (pix.x != pixLeft.x)

with 

if (pix.x < pixLeft.x)

we get: 


Which is stable, but then when I replace it with :

if (pix.x > pixLeft.x)

instead, we get:  
 

No matter what I do I cannot overcome this issue :/ On AMD this whole system works perfectly fine where on Nvidia it feels that there is some issue with the way how they handle uint operations.

If you are curious how did I fix it? I did not. I went with a really ugly solution that uses dFdx/dFdy and gives crappy result but at least it works on both architectures:


I'm not really happy about it but this is a visual thing to which I can return back to when I will have some spare time, which right now I do not have.

Comments

Post a Comment

Popular posts from this blog

Query commands execution

-
So like always start with problem description: I have some pool of command represented as enumerator. Each of command can have unique data that size can be different. I wanted to create system that allow me in easy way iterate over them and execute.  After some time I created this implementation: template<ECommands::enum cmd> bool execCommandTemp(ECommands::ENUM a_cmd, void* a_data) { if (a_cmd == cmd) { SCommand<cmd>::execute((SCommand ::SData*)a_data); return false; } return execCommandTemp<(ECommands::ENUM)(cmd+1)>(a_cmd, a_data); } template<> bool execCommandTemp<ECommands::WRAP>(ECommands::ENUM a_cmd, void* a_data) { return true; } bool execCommand( ECommands::ENUM a_cmd, void* a_data ) { return execCommandTemp<(ECommands::ENUM)0>(a_cmd, a_data); } where SCommand look in example such a way: template <> st...
Read More »

W.U. 0x20

-
Image
And as I said last time new preview is available: As you can see a lot has changed. Right now I mostly focus on gameplay so I do test of AI (some of them you can see on end of movie), changes in fight, items managing, fix some problem with physics and many other things. To say truth I don't remember them all :P So I'm going back to work and till next week.
Read More »

Few words about remake

-
Image
Time is something funny we don't notice when but it pass by so quickly. Few months ago I announced release of this pre-alpha build. Then it was so far away right now only a little bit more then month left. You probably wondering what changed in this time. So below you will find some summary of biggest changes (from my point of view): Component base architecture  Decision on big changes in engine architecture aren't easy. I think that transition from class base approach which looked like that : class CGameObject class CModelObject : public CGameObject class CPuppetObject : public CModelObject class CChcaracterObject: public CPuppetObject  to component base ( like in Unity 3D ) was one of the biggest and most problematic changes that I done in White Rabbit Engine in last years. I needed to change a lot of code, don't break the game that I have and in the same time change my approach to resolving problems.  Level Editor : New com...
Read More »