[Mesa-dev] GSoC : OpenCL over Gallium3D

[Denis Steckelmacher]

> 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.