Re: [Mesa-dev] r600 sb test results
On Fri, 03 May 2013 01:27:27 +0400 Vadim Girlin wrote: > I'm almost sure that the same issue that you have with glxgears affects > your app too, so you might want to wait until we resolve the problem > with gears, possibly this will solve other rendering issues as well. > ... > > By the way, I won't be very surprised if some old gcc release simply > fails at handling bitfields which are used to store both the keys of > shader variants in r600g and bytecode data in r600-sb (the same data > that ends up being broken in your glxgears dump), IIRC there were > bitfields-related bugs. It's not a bug, but undefined behavior AFAIK. I sent a patch that fixes the constant rebuilds (r600g: Correctly initialize the shader key). With these currently pending patches applied, I get no more visual distortion, and the fps improves a bit (28 -> 32). Just in case it'd be useful to you, here's the current sb,vs,ps output: http://bayfiles.net/file/PnH3/9BRcGY/foo_shaders.gz - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600 sb test results
On 05/02/2013 06:34 PM, Lauri Kasanen wrote: On Thu, 02 May 2013 00:45:13 +0400 Vadim Girlin wrote: On 05/01/2013 11:36 PM, Lauri Kasanen wrote: Now that it built, I could test your optimizations in my own apps. These are on current master 8eef6ad, on a RV710 (HD 4350 pci-e). In one of my private apps, using R600_DEBUG=sb caused regressions: FPS went from 28 to 7, the SSAO shader gave visual distortions/flicker, and the cpu was constantly pegged. Here's the output from R600_DEBUG=sb,sbstat in case it helps: http://bayfiles.net/file/Pmkh/PUj0Ru/vadim.gz It seems as if it's constantly handling new shaders? My app certainly issues no new shaders, they are all linked when the app starts. r600g may rebuild shaders at runtime because some GL features are implemented in shader code, so if your app changes some specific GL states (e.g. two-sided rendering mode), then r600g has to build and switch between different shader variants. It mainly uses the stencil buffer, the clear color is changed in various passes, some occlusion queries with color masks, but nothing exotic. New uniforms are of course sent each frame. On the other hand there is caching of shader variants in r600g implemented specially to prevent repetitive rebuilding of shaders, looks like it doesn't work in your case for some reason. Optimizations take more time than rebuilding with default backend, that explains performance regression. Could you provide some test app that reproduces these issues? It's quite time-taking to cut it down, and apitraces of it in full are several gigs (far too much to upload with my connection). I'll see if I can get just the SSAO isolated, with minimal textures, to get a smaller trace. I'm almost sure that the same issue that you have with glxgears affects your app too, so you might want to wait until we resolve the problem with gears, possibly this will solve other rendering issues as well. Please also send me the dump with "R600_DEBUG=sb,ps,vs", maybe I'll be able to spot anything wrong there. http://bayfiles.net/file/PmY5/xgIdlZ/foo.gz Let me know what you need to debug this. - Lauri PS: I'm not sure if this should be public or not, I think you're the only one working on it? Yes, I doubt that anyone else will work on it, on the other hand I think reporting this on the list might help other users who will possibly hit similar issues. Also at least in this case it looks rather like a problem in r600g, so I'm cc'ing mesa-dev, r600-sb just made this issue more noticeable because shader rebuilding with optimization requires more time. Using standard r600g, the cpu usage is less than 25% of one core, so nothing was showing it was constantly rebuilding shaders. Is there some way I could've found it was doing that, and if so, why? You could run the app with R600_DEBUG=ps,vs (without "sb") - it will also print the dump of every built shader. r600-sb doesn't affect the logic of shader rebuilding, it just processes the shaders when asked by r600g, so I think you'll see the same - a lot of built shaders. You could even try this with older mesa (before r600-sb was merged) to be sure. As for the cause of rebuilding, I don't see any changes in the shaders in your dump that might be explained by state changes, it's exactly the same shaders rebuilt more than once, so far I don't know why. You might want to look into r600_shader_select function with debugger to see what's going wrong, it computes the key for required shader variant using r600_shader_selector_key, then looks at the list of variants to find already built shader with the same key, and builds a new one only if it can't find existing shader. Looks like something fails there. By the way, I won't be very surprised if some old gcc release simply fails at handling bitfields which are used to store both the keys of shader variants in r600g and bytecode data in r600-sb (the same data that ends up being broken in your glxgears dump), IIRC there were bitfields-related bugs. Vadim - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600 sb test results
On Thu, 02 May 2013 00:45:13 +0400 Vadim Girlin wrote: > On 05/01/2013 11:36 PM, Lauri Kasanen wrote: > > Now that it built, I could test your optimizations in my own apps. > > These are on current master 8eef6ad, on a RV710 (HD 4350 pci-e). > > > > In one of my private apps, using R600_DEBUG=sb caused regressions: FPS > > went from 28 to 7, the SSAO shader gave visual distortions/flicker, and > > the cpu was constantly pegged. > > > > Here's the output from R600_DEBUG=sb,sbstat in case it helps: > > http://bayfiles.net/file/Pmkh/PUj0Ru/vadim.gz > > > > It seems as if it's constantly handling new shaders? My app certainly > > issues no new shaders, they are all linked when the app starts. > > r600g may rebuild shaders at runtime because some GL features are > implemented in shader code, so if your app changes some specific GL > states (e.g. two-sided rendering mode), then r600g has to build and > switch between different shader variants. It mainly uses the stencil buffer, the clear color is changed in various passes, some occlusion queries with color masks, but nothing exotic. New uniforms are of course sent each frame. > On the other hand there is caching of shader variants in r600g > implemented specially to prevent repetitive rebuilding of shaders, looks > like it doesn't work in your case for some reason. Optimizations take > more time than rebuilding with default backend, that explains > performance regression. > > Could you provide some test app that reproduces these issues? It's quite time-taking to cut it down, and apitraces of it in full are several gigs (far too much to upload with my connection). I'll see if I can get just the SSAO isolated, with minimal textures, to get a smaller trace. > Please also send me the dump with "R600_DEBUG=sb,ps,vs", maybe I'll be > able to spot anything wrong there. http://bayfiles.net/file/PmY5/xgIdlZ/foo.gz > > Let me know what you need to debug this. > > > > - Lauri > > > > PS: I'm not sure if this should be public or not, I think you're the > > only one working on it? > > Yes, I doubt that anyone else will work on it, on the other hand I think > reporting this on the list might help other users who will possibly hit > similar issues. Also at least in this case it looks rather like a > problem in r600g, so I'm cc'ing mesa-dev, r600-sb just made this issue > more noticeable because shader rebuilding with optimization requires > more time. Using standard r600g, the cpu usage is less than 25% of one core, so nothing was showing it was constantly rebuilding shaders. Is there some way I could've found it was doing that, and if so, why? - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600 sb test results
On 05/01/2013 11:36 PM, Lauri Kasanen wrote: Hi Vadim Now that it built, I could test your optimizations in my own apps. These are on current master 8eef6ad, on a RV710 (HD 4350 pci-e). In one of my private apps, using R600_DEBUG=sb caused regressions: FPS went from 28 to 7, the SSAO shader gave visual distortions/flicker, and the cpu was constantly pegged. Here's the output from R600_DEBUG=sb,sbstat in case it helps: http://bayfiles.net/file/Pmkh/PUj0Ru/vadim.gz It seems as if it's constantly handling new shaders? My app certainly issues no new shaders, they are all linked when the app starts. Hi, r600g may rebuild shaders at runtime because some GL features are implemented in shader code, so if your app changes some specific GL states (e.g. two-sided rendering mode), then r600g has to build and switch between different shader variants. On the other hand there is caching of shader variants in r600g implemented specially to prevent repetitive rebuilding of shaders, looks like it doesn't work in your case for some reason. Optimizations take more time than rebuilding with default backend, that explains performance regression. Could you provide some test app that reproduces these issues? Please also send me the dump with "R600_DEBUG=sb,ps,vs", maybe I'll be able to spot anything wrong there. Let me know what you need to debug this. - Lauri PS: I'm not sure if this should be public or not, I think you're the only one working on it? Yes, I doubt that anyone else will work on it, on the other hand I think reporting this on the list might help other users who will possibly hit similar issues. Also at least in this case it looks rather like a problem in r600g, so I'm cc'ing mesa-dev, r600-sb just made this issue more noticeable because shader rebuilding with optimization requires more time. Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
