[Mesa-dev] new i965g pipe driver for Intel GEN6 (and later)

[Brian Paul]

On 04/17/2013 02:31 AM, Jose Fonseca wrote:
>
>
> ----- Original Message -----
>> On Wed, Apr 17, 2013 at 8:09 AM, Marek Olšák<maraeo at gmail.com>  wrote:
>>> On Tue, Apr 16, 2013 at 9:58 PM, Chia-I Wu<olvaffe at gmail.com>  wrote:
>>>>
>>>> On Wed, Apr 17, 2013 at 12:58 AM, Matt Turner<mattst88 at gmail.com>  wrote:
>>>>>
>>>>> I think everything Marek said was correct. If you could extend Gallium
>>>>> to consume GLSL IR it might actually be an interesting project.
>>>>
>>>> Yes, it is.  I do want to make pipe drivers be able to express the
>>>> preferred IR and make the mesa state tracker generate it.  I had LLVM IR
>>>> in mind, but GLSL IR could be a much less intrusive choice.  I will check
>>>> that out.
>>>
>>> Actually, there is even a better option. You don't have to fork the
>>> compiler, you can add source files from src/mesa/drivers/dri/i965 to
>>> your gallium driver. We have done this before. r300g did not have its
>>> own compiler for a couple of *years*. The compiler lived in r300c in
>>> src/mesa/drivers/dri/r300/compiler and it was more or less a separate
>>> library (it did not depend on gl_context). If r300g was enabled, the
>>> build system also compiled files in the r300 compiler directory and
>>> the linker included them in the .so file. r300g also used (and still
>>> uses) the register allocator from src/mesa/program, which is also used
>>> by i965.
>> One thing I want to do next in i965g is to make shader compilation and
>> complied shaders opaque for the rest of the driver.  That would make
>> the code cleaner, and make it easy to switch to different compilers.
>> It seems the compiler in i965 makes some use of brw_context, but that
>> is mainly to get hardware capabilities.  It should be possible to make
>> it more library-like or to fork it for i965g.
>>
>> How hard would it be to make GLSL IR an alternative IR for pipe
>> drivers?  On the driver side, it seems I only need to add
>> PIPE_SHADER_IR_GLSL for the preferred IR and change the type of tokens
>> to void *.  On the st/mesa side, could I simply skip GLSL-to-TGSI
>> pass?  Maybe also disable API_OPENGL_COMPAT?
>
> Fully replacing TGSI would also imply providing an alternative to src/gallium/auxiliary/util/u_simple_shaders.h , for clears and blits.  One can easily imagining one day these helpers taking an additional PIPE_SHADER_IR_* parameter. I think this would be the ideal.

Olv, I presume you're not using the 'draw' module.  There's lots of 
TGSI dependencies in there too.


> In the short term, you could workaround that need either by keeping enough TGSI support just for those cases, or maybe by tweaking the mesa state tracker to use the src/mesa/drivers/common/meta.c for clears.

Unfortunately, the meta code has a few dependencies on swrast, which 
isn't used with any gallium configuration.


> Brian can give a better assessment, but my understanding is that meta module doesn't have as tight control over the driver interface as the mesa gallium state tracker has, so bugs due to non-default/tampered state tend to creep up now and then.

Can you keep the TGSI support in place alongside GLSL IR?  That is, 
keep the TGSI support as-is.  Provide GLSL IR where possible.  In 
pipe_shader_state, add (a) new field(s) to carry GLSL IR.  When 
pipe_shader_state has GLSL IR, use it.  Else, fall back to using TGSI.

Ideally, everything would continue to run throughout the process but 
you'd gradually transition everything to GLSL IR.  When you get to 
100% of the later, remove the TGSI support.

But in addition to the GLSL IR code itself, there's other stuff that 
interfaces with it, like constant buffer layout.  I'm really not too 
aware of how that's handled at the moment.

-Brian