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 <div class="gmail_quote">On Sat, Mar 26, 2011 at 9:52 PM, Denis Steckelmacher <<a href="mailto:steckdenis@yahoo.fr" target="_blank">steckdenis@yahoo.fr</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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 <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </blockquote></div>