[Mesa-dev] GSoC : OpenCL over Gallium3D

[Marek Olšák]

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


On Sat, Mar 26, 2011 at 9:52 PM, Denis Steckelmacher <steckdenis at yahoo.fr>wrote:

> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110329/859dbeb5/attachment.html>