No announcement yet.

Linux 2.6.36-rc5 Kernel Released; Fixes 14 Year Old Bug

  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by BlackStar View Post
    Older Nvidia drivers would recompile whenever you changed uniforms to/from 0.0 (and some other specific numbers). While this "optimization" presumably led to faster execution, it also introduced untold headaches to developers (change a random parameter, get a 30ms stall waiting for the shader to recompile) so it was disabled at some point.

    Yes, modern GPUs predict branches.
    Thank you!


    • #52
      OK, glad this all worked out while I was sleeping

      "AOT when it goes through the driver" (as opposed to "AOT before the app is distributed") is what I was calling JIT. Most apps prepare their shader programs during startup so that they are JIT-compiled once per invocation of the program.

      Sometimes the driver needs to insert additional shader code in order to simulate hardware functionality. In this case the shader code may be generated based on specific state information, and if so the driver needs to recompile the shader whenever that state information changes rather than just once at startup.

      Inserting driver-specific shader code is not a broadly useful approach because a number of apps and emulators assume (reasonably) that they have access to all of the registers and instruction slots, but if the driver inserts additional shader code (using registers and instruction slots) then Bad Things will happen. In principle the driver could react by disabling whatever hardware feature is being emulated, but that would require something like a GL_ARB_DudeImUsingAllTheResources OpenGL call amd AFAIK there is no such function defined today.


      • #53
        EDIT - there may actually be enough info in the existing API calls to detect when inserting shader code is not possible, need to check.