3 ms·

> > A lot of our options do change how shaders work though, like forcing a shader to use double precision floats instead of the single it was compiled with. Th

> > A lot of our options do change how shaders work though, like forcing a shader to use double precision floats instead of the single it was compiled with. That will break code sufficienly reliant on the behaviour of sungle precision, though.

david-gpu 2y ago
Obviously, which is the reason you don't do something like that without appropriate amounts of testing.
- chrisjj 2y ago
  Testing on platforms that perverts the precision is outside appropriate, I would say.
Dylan16807 2y ago
Code depending on specific low precision is very likely to be so fragile it won't make it anywhere near release.
- chrisjj 2y ago
  Consider an RNG.
  - Dylan16807 2y ago
    I consider a floating point RNG in a shader that is seeded for reproducibility to be a bad idea.
    - chrisjj 2y ago
      Why, pray?
      - Dylan16807 2y ago
        GPUs often have weird sizes for optimal behavior and you have to depend on math-based optimizations never being applied to your code. In my opinion, floating point shaders should be treated as a land of approximations. You asked in another comment why /width*width isn't optimized out by the compiler. But it's changes just like that that will break an RNG!
        chrisjj 2y ago
        > In my opinion, floating point shaders should be treated as a land of approximations. Fine, but that leaves you responsible for the breakage the shader of an author that holds the opposite opinion, as he is entitled to do. Precision =/= accuracy.
        Dylan16807 2y ago
        But do you want /width*width to be optimized? Or associative and commutative operations in general? Then you have to reject the opposite opinion.
        chrisjj 2y ago
        > But do you want /width*width to be optimized? I do. But I don't see such optimisation as anything to with your changing float type.
        Dylan16807 2y ago
        Changes like that will break just as much code as adding extra precision will. Because it will change how things round, and not much else, just like adding extra precision. They're both slightly disruptive, and they tend to disrupt the same kind of thing, unlike removing precision which is very disruptive all over.
- account42 2y ago
  "Fragile shader code won't make it anywhwere near release" is a pretty bold claim. If it happens to work with the Nvidia driver it's getting shipped.
  - Dylan16807 2y ago
    But since the premise is that any difference breaks the code, will it work the exact same way across different devices? That's what I'm skeptical of. Unless every dev and tester that touches this shader is using the same hardware, which seems like an obvious mistake to avoid...
    - Cieric 2y ago
      I will note, half of the customer facing bugs I get are "works on nvidia." Only to find out that it is a problem with the game and not the driver. Nvidia allows you to ignore a lot of the spec and it causes game devs to miss a lot of obvious bugs. A few examples: 1) Nvidia allows you to write to read only textures, game devs will forget to transition them to writable and will appear as corruption on other cards. 2) Nvidia automatically work with diverging texture reads, so devs will forget to mark them as a nonuniform resource index, which shows up as corruption on other cards. 3) Floating point calculations aren't IEEE compliant, one bug I fixed was x/width*width != x, On Nvidia this ends up a little higher and on our cards a little lower. The game this happened on ended up flooring that value and doing a texture read, which as you can guess, showed up as corruption on our cards. 1 and 2 are specifically required by the microsoft directx 12 spec, but most game devs aren't reading that and bugs creep in. 3 is a difference in how the ALU is designed, our cards being a little closer to IEEE compliant. A lot of these issue are related to how the hardware works, so stays pretty consistent between the different gpus of a manufacturer. Side note: I don't blame the devs for #3, the corruption was super minor and the full calculation was spread across multiple functions (assumed by reading the dxil). The only reason it sticks out in my brain though is because the game devs were legally unable to ever update the game again, so I had to fix it driver side. That game was also Nvidia sponsored, so it's likely our cards weren't tested till very late into the development. (I got the ticket a week before the game was to release.) That is all I'm willing to say on that, I don't want to get myself in trouble.
Cieric 2y ago
In the case that does happen, then we don't apply that setting. Most of the changes applied are extensively tested and toggles like that are more often used for already broken shaders.
- chrisjj 2y ago
  > In the case that does happen You meant "in the case we find where that does happen"? Little consolation for the cases you don't find because e.g. you cannot afford to play a game to the end.
  - Cieric 2y ago
    Fair enough, I can't say anything I've done has ever caused an issue like that (A new ticket would have been made and sent to me.) But I also can't say that it has never happened, so I'm not really in a position to disagree. We do have a good QA team though and we have an "open" beta program that also catches a lot of issues before they become more widely public.
    - chrisjj 2y ago
      I for one would be most unhappy to find my game failing on card X due to drivers perverting my float type.

david-gpu 2y ago

Obviously, which is the reason you don't do something like that without appropriate amounts of testing.

chrisjj 2y ago
Testing on platforms that perverts the precision is outside appropriate, I would say.

Dylan16807 2y ago

Code depending on specific low precision is very likely to be so fragile it won't make it anywhere near release.

chrisjj 2y ago
Consider an RNG.
- Dylan16807 2y ago
  I consider a floating point RNG in a shader that is seeded for reproducibility to be a bad idea.
  - chrisjj 2y ago
    Why, pray?
    - Dylan16807 2y ago
      GPUs often have weird sizes for optimal behavior and you have to depend on math-based optimizations never being applied to your code. In my opinion, floating point shaders should be treated as a land of approximations. You asked in another comment why /width*width isn't optimized out by the compiler. But it's changes just like that that will break an RNG!
      - chrisjj 2y ago
        > In my opinion, floating point shaders should be treated as a land of approximations. Fine, but that leaves you responsible for the breakage the shader of an author that holds the opposite opinion, as he is entitled to do. Precision =/= accuracy.
        Dylan16807 2y ago
        But do you want /width*width to be optimized? Or associative and commutative operations in general? Then you have to reject the opposite opinion.
        chrisjj 2y ago
        > But do you want /width*width to be optimized? I do. But I don't see such optimisation as anything to with your changing float type.
        Dylan16807 2y ago
        Changes like that will break just as much code as adding extra precision will. Because it will change how things round, and not much else, just like adding extra precision. They're both slightly disruptive, and they tend to disrupt the same kind of thing, unlike removing precision which is very disruptive all over.
account42 2y ago
"Fragile shader code won't make it anywhwere near release" is a pretty bold claim. If it happens to work with the Nvidia driver it's getting shipped.
- Dylan16807 2y ago
  But since the premise is that any difference breaks the code, will it work the exact same way across different devices? That's what I'm skeptical of. Unless every dev and tester that touches this shader is using the same hardware, which seems like an obvious mistake to avoid...
  - Cieric 2y ago
    I will note, half of the customer facing bugs I get are "works on nvidia." Only to find out that it is a problem with the game and not the driver. Nvidia allows you to ignore a lot of the spec and it causes game devs to miss a lot of obvious bugs. A few examples: 1) Nvidia allows you to write to read only textures, game devs will forget to transition them to writable and will appear as corruption on other cards. 2) Nvidia automatically work with diverging texture reads, so devs will forget to mark them as a nonuniform resource index, which shows up as corruption on other cards. 3) Floating point calculations aren't IEEE compliant, one bug I fixed was x/width*width != x, On Nvidia this ends up a little higher and on our cards a little lower. The game this happened on ended up flooring that value and doing a texture read, which as you can guess, showed up as corruption on our cards. 1 and 2 are specifically required by the microsoft directx 12 spec, but most game devs aren't reading that and bugs creep in. 3 is a difference in how the ALU is designed, our cards being a little closer to IEEE compliant. A lot of these issue are related to how the hardware works, so stays pretty consistent between the different gpus of a manufacturer. Side note: I don't blame the devs for #3, the corruption was super minor and the full calculation was spread across multiple functions (assumed by reading the dxil). The only reason it sticks out in my brain though is because the game devs were legally unable to ever update the game again, so I had to fix it driver side. That game was also Nvidia sponsored, so it's likely our cards weren't tested till very late into the development. (I got the ticket a week before the game was to release.) That is all I'm willing to say on that, I don't want to get myself in trouble.

Cieric 2y ago

In the case that does happen, then we don't apply that setting. Most of the changes applied are extensively tested and toggles like that are more often used for already broken shaders.

chrisjj 2y ago
> In the case that does happen You meant "in the case we find where that does happen"? Little consolation for the cases you don't find because e.g. you cannot afford to play a game to the end.
- Cieric 2y ago
  Fair enough, I can't say anything I've done has ever caused an issue like that (A new ticket would have been made and sent to me.) But I also can't say that it has never happened, so I'm not really in a position to disagree. We do have a good QA team though and we have an "open" beta program that also catches a lot of issues before they become more widely public.
  - chrisjj 2y ago
    I for one would be most unhappy to find my game failing on card X due to drivers perverting my float type.