[Mesa-dev] Organisation of the OpenCL state tracker
Hello, I'm very happy to have been accepted as a Google Summer of Code student ! Thanks to all who voted for my proposal, and thanks to Google. It's now the time to discuss the details of the implementation before beginning to code. I have already a fairly good idea of how I will implement things, but my question for today is Where do I place my code ?. Before I start explaining my question, I would say that I launched a Wordpress-based blog to share my progress and thoughts with everyone interested. It can be reached at http://steckdenis.wordpress.com. I'll try to keep it up to date with what I do. Its first post is about the object of this mail : do I work directly on Clover or do I copy it in the Mesa source tree, under src/gallium/state-trackers ? Currently, Clover already contains some code, but it’s mainly a build-system architecture and some files with function skeletons. The “useful” code seems to be less than 1000 lines long. If I work directly on Clover, I’ll make a library independant of Mesa for the software path, and relying on Gallium for the accelerated path. The problem is that I would have to reinvent the wheel at some places, for exemple where Gallium util functions exist. Another problem is that the Gallium3D interfaces are private, so it will be difficult to build Clover without the Mesa source code. If I create a state tracker in the gallium/ directory of Mesa, I will be able to use all the Gallium infrastructure and utils, and my work will be easily buildable by every person wanting to test it. This solution isn’t perfect though, as I will have to copy/paste and adapt the already-existing code of Clover in a new location, refactoring it from C++ to C. The blog post ends with a paragraph over the Gallium infrastructure used by the state trackers, that is to say the state tracker managers and the state trackers APIs (using Mapi). The problem is that OpenCL is only one API. The OpenCL context is created by OpenCL itself, not by EGL, WGL or GLX. So, do I have to break the Gallium3D model by not using the state trackers APIs, or do I have to create a state tracker API (that I will base on the OpenVG state tracker, very simple and that I understand very good) and a pass-through state tracker manager for OpenCL ? Finally, if I create a directory in the Mesa source tree, how do you want me to name it ? Clover, Coal (these two names appear in the current Clover code) or the already-suggested Chloride ? Best regards, Denis Steckelmacher. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GSoC : OpenCL over Gallium3D
Denis, This is a great proposal. I have a few comments and suggestions, though. I think the OpenCL state tracker should not be implemented using fragment shaders, framebuffers, and generally the 3D engine as is exposed via pipe_context. It might be useful for some initial experiments, but it's kinda non-natural, because there is hardware which can do OpenCL and/or CUDA more or less natively. So I think we should come up with a separate set of pipe_context functions for running compute kernels. This will be an advantage for you, because you will be able to design you own Gallium driver functions, assuming you commit to working on the OpenCL state tracker, of course. Besides reading the OpenCL spec, you might need to take a look at these interfaces when designing the Gallium interface for compute kernels: - DirectCompute and compute shaders (part of DirectX 11) - CUDA Especially you will need to make sure that the compute subset of DirectX 11 will be implementable (at least in theory). I only have experience with CUDA, so here are some ideas on new driver entrypoints that could be added to pipe_context, from the top of my head: void *create_compute_shader(...); // like shaders void bind_compute_shader(...); void delete_compute_shader(...); // set_constant_buffer can be reused void set_compute_shader_sampler_states(ctx, num, states); void set_compute_shader_sampler_views(ctx, num, views); void set_compute_shader_readwrite_resources(ctx, num, resources); // like samplers, but for read-write resources void run_compute_shader(ctx, info); // anything not specific to draw_vbo can be reused too, like transfers, resource_copy_region, etc. Don't take the list literally, I haven't given it much thought. Also, I wouldn't bother with TGSI at the beginning. Let's stick to the LLVM IR for simplicity and using llvmpipe to execute the compute kernels on a CPU, even that is a lot of work for GSoC. Once it works, we can resolve any remaining issues like what IR will be used etc. The complete OpenCL implementation will take more than a few months, so let's concentrate on making something work first. BTW I haven't taken a look at the clover codebase, so some of my comments might be a little off. Marek Hello, Using llvmpipe directly is a great idea especially considering that I will have to work two weeks on a small laptop without a properly supported graphics card. The plan would be to : * Implement a small Gallium interface to pass LLVM IR directly to llvmpipe, if an existing interface doesn't exist yet. * Implement the OpenCL state tracker using an abstraction layer between the compiler and the running software/hardware. Implementing proper accelerated support will be as simple as adding a new implementation of an interface, plus the work needed in Gallium. I have to send my official proposal today or tomorrow because I'm going on a school trip on 31th march. I will be back on 7th april, just one day before the application deadline. I really like your idea, it will give the chance to many users to use OpenCL and to develop with it without being required to use proprietary drivers on supported graphics card. Even users of Intel hardware (that lack a Gallium3D pipe driver) will be able to enjoy OpenCL ! Best regards, Denis Steckelmacher. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GSoC : OpenCL over Gallium3D
Hello, After some messages on this list, I reconsidered my GSoC proposal and decided to give a try at an OpenCL state tracker. I will base my work on the Clover branch of Mesa. I read its code, which is very well-done and clean, but I saw one big difficulty : I don't know how to translate LLVM IR to TGSI. The big problem is that TGSI is made mostly with OpenGL in mind. We can use it to decode video frames using vertex and fragment shader stages, but using it to run on the GPU the complex output given by LLVM, and without using any part of the OpenGL pipeline (OpenCL can be used to do mathematics, and that doesn't draw anything on the screen), is tricky. The problem is how OpenCL can upload data on the GPU and then download the computed results. One solution may be to create one or more textures containing the input data (maybe one texture by input data type), and then use a fragment shader to compute the resulting values and to put them in a render buffer that will never be drawn on screen but instead downloaded from the GPU and sent back to the application. I don't know if it would be possible to do things like that, especially considering that precise results across all graphics cards may be difficult to get with OpenGL. An other problem of this LLVM to TGSI conversion is that the TGSI instruction set is not completely implemented on all the pipe drivers, and that unimplemented instructions may be needed by a specific LLVM IR instruction. I'm open to any suggestion regarding this OpenCL state tracker. If you say it will be very difficult to do that during the summer, I think I will apply to work on the OpenGL 3+ support in Mesa (without doing a new state tracker) and the GLSL compiler. Best regards, Denis Steckelmacher. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] News about my GSoC proposal
Am 21.03.2011 11:43, schrieb Denis Steckelmacher: […] I'm open to any suggestion. I now understand the majority of the Mesa code (I read most of it past week), and I also read some parts of the OpenVG state tracker (a state tracker not too far from OpenGL, but way simpler, and built directly on top of Gallium, so close to what I want to experiment the following weeks). Have you considered working on Clover, the OpenCL state tracker? It seems like it would fit your criteria of wanting to work on a state tracker not burdened by all the legacy stuff as much as the current GL implementation. Philipp Hello, It would also be an interesting project, especially considering that I'm fairly interested by GPGPU. The Clover codebase seems not too big and well- done, so I will read it to see what I can do. Thanks, Denis Steckelmacher. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] News about my GSoC proposal
Hello, I can consider working on a hardware driver, but I'm not very familiar with these pieces of software. I will also need to work two weeks without my main computer, on a Packard Bell laptop with an RS690m graphics card (r300g driver). The r300g driver is already mature, exept one memory corruption bug on my RS690 (reported on the bugzilla as bug nr 35457). I planned to use llvmpipe to work on Mesa or my state tracker. Nevertheless, I have an ATI Radeon 4800 or so somewhere at home, so I can put it in my computer (instead of the integrated RS690, yes, another RS690, they chase me) and try to work on the r600g driver, but I don't know if I will be able to do something interesting. I'm open to any suggestion. I now understand the majority of the Mesa code (I read most of it past week), and I also read some parts of the OpenVG state tracker (a state tracker not too far from OpenGL, but way simpler, and built directly on top of Gallium, so close to what I want to experiment the following weeks). Best regards, Denis Steckelmacher. Hi Denis, I think the work to replace Mesa IR with GLSL IR is being done by Intel (it was mentioned on #dri-devel, feel free to drop by), but I don't think they will want to touch the st_mesa_to_tgsi part. Have you considered working on a hardware driver? Sometimes, stable and fast drivers are all that users need. :) Marek On Sun, Mar 20, 2011 at 6:52 PM, Denis Steckelmacher steckde...@yahoo.frwrote: Hello, One week has passed since my last mail, talking about an OpenGL 4.1 Core state tracker. There has been great interest and many remarks, so thanks to you all. I write this mail to give some more information about my future proposal, and to say that I have not disappeared and that I'm already working. I'm currently browsing the whole Mesa code, not only Gallium, and even EGL and GLX code. The project of replacing Mesa IR with GLSL IR seems to be really interesting, and it seems I will apply to do that (plus some other things if I have time to do so, but I doubt it, as Mesa IR is really heavily used in Mesa and the Mesa state tracker). I'm also reading the code to have a more precise idea about the amount of work needed to make a simple OpenGL 3+ Core state tracker, as an experiment during the following months, before the Summer of Code. This way, I will be able to see if it's possible and interresting. So, thanks a lot for your replies to my previous mails, I now know what you want and I find that interesting. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org 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
[Mesa-dev] News about my GSoC proposal
Hello, One week has passed since my last mail, talking about an OpenGL 4.1 Core state tracker. There has been great interest and many remarks, so thanks to you all. I write this mail to give some more information about my future proposal, and to say that I have not disappeared and that I'm already working. I'm currently browsing the whole Mesa code, not only Gallium, and even EGL and GLX code. The project of replacing Mesa IR with GLSL IR seems to be really interesting, and it seems I will apply to do that (plus some other things if I have time to do so, but I doubt it, as Mesa IR is really heavily used in Mesa and the Mesa state tracker). I'm also reading the code to have a more precise idea about the amount of work needed to make a simple OpenGL 3+ Core state tracker, as an experiment during the following months, before the Summer of Code. This way, I will be able to see if it's possible and interresting. So, thanks a lot for your replies to my previous mails, I now know what you want and I find that interesting. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GSoC : Thoughts about an OpenGL 4.1 state tracker
anymore by the majority of applications. The questions = The first one is : are you interested by this ? Do you think it is possible to start this state tracker and to have it in a testable shape in three months (by testable I mean that we can run some example programs that use only a subset of the OpenGL Core profile, for example KWin, compatible with OpenGL ES 2, OpenGL 3 Core and which can use EGL). I've also a question regarding the GLSL compiler and TGSI : I will not implement an ir_to_mesa converter, but instead an ir_to_tgsi if needed. I don't know what is going on in the work of replacing TGSI with GLSL IR or even with LLVM IR. Fortunately, i think that converting the GLSL compiler's output to what can be used in the pipe driver will not be the more difficult part of the state tracker. Lastly, I have still to completely understand mapi and all the code handling the creation of a context given an API and extensions. Maybe this code is only needed for indirect GLX. Thanks for reading. I understand that this task is very big, but I hope that I will be able to make interesting things during this summer and that it will help Mesa to catch up on OpenGL. I will now continue to read the Gallium interfaces code and the OpenGL spec. I'm open to any question or remark. Best regards, Denis Steckelmacher. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GSoC : Thoughts about an OpenGL 4.1 state tracker
anymore by the majority of applications. The questions = The first one is : are you interested by this ? Do you think it is possible to start this state tracker and to have it in a testable shape in three months (by testable I mean that we can run some example programs that use only a subset of the OpenGL Core profile, for example KWin, compatible with OpenGL ES 2, OpenGL 3 Core and which can use EGL). I've also a question regarding the GLSL compiler and TGSI : I will not implement an ir_to_mesa converter, but instead an ir_to_tgsi if needed. I don't know what is going on in the work of replacing TGSI with GLSL IR or even with LLVM IR. Fortunately, i think that converting the GLSL compiler's output to what can be used in the pipe driver will not be the more difficult part of the state tracker. Lastly, I have still to completely understand mapi and all the code handling the creation of a context given an API and extensions. Maybe this code is only needed for indirect GLX. Thanks for reading. I understand that this task is very big, but I hope that I will be able to make interesting things during this summer and that it will help Mesa to catch up on OpenGL. I will now continue to read the Gallium interfaces code and the OpenGL spec. I'm open to any question or remark. Best regards, Denis Steckelmacher. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
