Just wow! It would be crime not to merge this branch, with the sole reason "LLVM is the future". Fantastic work Vadim.
On Fri, Feb 15, 2013 at 1:00 PM, Vadim Girlin <vadimgir...@gmail.com> wrote: > On 02/14/2013 02:42 PM, Christian König wrote: > >> Hi Vadim, >> >> nice work, I think you've made quite a progress here, but on the other >> hand it should be clear that the LLVM backend is the future and we >> should concentrate on that. >> > > "LLVM backend is the future" is a pretty abstract argument. I prefer to > operate with real facts. After a year of LLVM backend development what are > the real benefits for the users? What are the real use cases where the > users might prefer LLVM backend? To me this situation looks like the use of > LLVM requires a lot more time and development efforts than the custom > solution, despite the initial expectations. Maybe you are right and the > LLVM backend will become the best alternative for users sometime in the > future, but I only have some today's results: > > Heaven 3.0, all settings high/enabled, 1280x720, HD5750: > default backend : 20.0 fps > llvm backend : 18.8 fps > r600-sb : 38.0 fps > > When I'm looking at these results, the benefits of LLVM-based solution are > not very clear to me. > > I'm not trying to persuade anyone, just wanted to explain why I decided to > switch back to work on the non-LLVM solution. > > Anyway, it's absolutely not a problem for me if this branch will never > make it to mesa, I was ready to this before I started. One of the goals of > this branch was just to show that the use of LLVM is possibly not the the > best way of the GL shaders compilation for r600g. And another goal, of > course, is to get better performance with r600g *today*, not in the future. > > Vadim > > >> To sum it up I'm not sure what we should do with this branch :) >> >> As Dragomir already wrote even if the code won't be used much the >> know-how you gained while coding it will stay, believe me that this is >> or far more value than the code itself. >> >> Christian. >> >> Am 14.02.2013 11:10, schrieb Dragomir Ivanov: >> >>> Greetings, >>> I hope that, even if you work will be short-lived, e.g. until LLVM >>> bytecode compiler takes off, the know-how is still very useful. >>> >>> >>> On Thu, Feb 14, 2013 at 4:04 AM, Vadim Girlin <vadimgir...@gmail.com >>> <mailto:vadimgir...@gmail.com>**> wrote: >>> >>> Hi, >>> >>> Last month I finally found the time to work on the rewrite of my >>> previous shader optimization branch, now it's mostly done in terms >>> of the correctness of produced code and feature support (at least >>> on evergreen), though it's still a work in progress in terms of >>> the efficiency of generated shader code and the efficiency of the >>> backend itself. >>> >>> I spent some time last year studying the LLVM infrastructure and >>> R600 LLVM backend and trying to improve it, but after all I came >>> to the conclusion that for me it might be easier to implement all >>> that I wanted in the custom backend. This allows for more simple >>> and efficient implementation - e.g. I don't have to deal with CFGs >>> because in fact we have structured code, so it's possible to use >>> more simple and efficient algorithms. >>> >>> Currently the branch has no regressions with piglit's >>> quick-driver.tests on evergreen (it doesn't rely on the fallback >>> to unoptimized code for the shaders with relative addressing and >>> other cases unlike the previous branch), and so far I don't see >>> any rendering issues with the apps that I used for testing - >>> Lightsmark 2008, Unigine Heaven 3.0 and some others.. There are >>> also some performance improvements with the gpu-bound apps. >>> >>> I tried to keep in mind the differences between chip classes, so I >>> hope it should only require minor fixes to make it work on >>> non-evergreen chips, but I doubt that it will work out of the box >>> - support for some non-evergreen hw-specific features is still >>> missing, e.g. I'm sure that indirect addressing currently won't >>> work on R6xx, though basic tests might work in theory. Fixing this >>> shouldn't require a lot of work though. >>> >>> The branch can be found in my freedesktop repo: >>> >>> >>> http://cgit.freedesktop.org/~**vadimg/mesa/log/?h=r600-sb<http://cgit.freedesktop.org/~vadimg/mesa/log/?h=r600-sb> >>> >>> <http://cgit.freedesktop.org/%**7Evadimg/mesa/log/?h=r600-sb<http://cgit.freedesktop.org/%7Evadimg/mesa/log/?h=r600-sb> >>> > >>> >>> >>> Regarding the differences from the previous branch - there are >>> some additional optimizations, e.g. global value numbering with >>> some basic support for constant folding (not all instructions are >>> currently handled, but it's easy to extend), global code motion >>> that can hoist invariant code out of the loops etc. Some >>> optimizations that were implemented in the previous branch are not >>> implemented in the new branch (yet), e.g. propagation of modifiers >>> (I'm not even sure if it has any noticeable effect on performance). >>> >>> Unlike the previous branch, there is support for indirect >>> addressing on registers - currently it uses my previously posted >>> patch (that was not very welcome) for obtaining the information >>> about addressable register ranges, but it's not required and can >>> be dropped, I just used that patch for testing. Without that >>> information opportunities for optimization are limited though, and >>> perhaps it makes sense to not try to optimize the shaders with >>> indirect gpr addressing at all and rely on the old backend until >>> we'll have the proper solution to pass that information to the >>> drivers. >>> >>> There is also initial support for ALU predication, but it's not >>> complete and currently unused, I'm not sure if predication support >>> will have significant effect on performance that will justify more >>> complex and expensive algorithms for register allocator and >>> scheduler, probably I'll look into it later, I consider this as a >>> low priority. In the case of predicated source code (from LLVM >>> backend) the predication is eliminated using speculative execution >>> and conditional moves, same as with the simple if-conversion pass >>> that is also implemented. >>> >>> The branch currently uses as source the bytecode built by the old >>> backend (that may also come from LLVM backend) and some additional >>> information (about inputs etc), final bytecode is built by the new >>> builder in the branch. Building two versions of the bytecode >>> doesn't look very efficient, but currently it simplifies >>> debugging. I'm planning to implement translation from TGSI >>> directly to my representation, it should simplify the translator >>> and allow to get rid of unnecessary intermediate passes. >>> >>> Some old and new environment variables can be used to control the >>> behavior of this backend: >>> >>> R600_SB - 0 - disable new backend completely, 1 - enable (default) >>> R600_SB_USE_NEW_BYTECODE - 0 - disable use of the produced >>> bytecode (useful if you only want to look at the dump of the >>> optimized shader without passing it to hw), 1 - enable (default) >>> R600_DUMP_SHADERS - will also dump the dissasemble of the >>> optimized shader after original bytecode (if backend is not >>> disabled with R600_SB=0). >>> >>> Produced shader code is not ideal - e.g. you may notice not very >>> necessary MOVs inserted before DOT4 instructions, it's a known >>> issue and I'm going to look into it - this may require rework of >>> the regalloc/scheduler. I had to sacrifice some features to make >>> it work correctly with Heaven first, so that now I can try to >>> improve it while being able to test for regressions. >>> >>> Also probably there are some issues with the cleanness of the code >>> - I had to rework some parts a few times while fixing all >>> problems, so there is possibly unused code and other remnants of >>> the previous versions. Anyway, I still consider it as a work in >>> progress and some things are going to be reworked. >>> >>> I'm not sure what will be the destiny of this branch, taking into >>> account that we also have actively developed LLVM backend that is >>> required for OpenCL anyway. Your opinions are welcome. >>> >>> Vadim >>> ______________________________**_________________ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> <mailto:mesa-dev@lists.**freedesktop.org<mesa-dev@lists.freedesktop.org> >>> > >>> >>> >>> http://lists.freedesktop.org/**mailman/listinfo/mesa-dev<http://lists.freedesktop.org/mailman/listinfo/mesa-dev> >>> >>> >>> >>> >>> ______________________________**_________________ >>> mesa-dev mailing list >>> mesa-dev@lists.freedesktop.org >>> http://lists.freedesktop.org/**mailman/listinfo/mesa-dev<http://lists.freedesktop.org/mailman/listinfo/mesa-dev> >>> >> >> >> > > > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
