Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Marek O. <ma...@gm...>]

On Tue, Mar 23, 2010 at 8:46 PM, Tom Stellard <tst...@gm...> wrote:

> On Tue, Mar 23, 2010 at 12:13:25AM -0700, Corbin Simpson wrote:
> > On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard <tst...@gm...>
> wrote:
> > >
> > > Thanks for the information.
> > >
> > > After spending some time learning about the Gallium driver
> architecture, I
> > > think it might be better to set a goal to implement or improve a
> specific
> > > feature of the Gallium R300 driver rather than trying to get a specific
> > > game or application to work.  Is there a feature that is currently
> missing
> > > from the R300 driver that might make a good project for the summer?
> >
> > Good question. There's a handful of things. Passing piglit might be a
> > good goal. Bumping the GL version further up, or solidifying the GLSL
> > support, might be good too.
> >
>
> I think the GLSL compiler would be an interesting project for me to work
> on.  What is the current status of GLSL on R300 cards?


>From the driver point of view, we don't have to work on the GLSL compiler
itself. The Mesa state tracker compiles GLSL to an assembler-like language
called TGSI which is then translated ([1]) to the R300 compiler ([2]) shader
representation. The more TGSI we handle, the more GLSL support we get.

So now the status. r300g GLSL is missing the following features:

1) Branching and looping

This is the most important one and there are 3 things which need to be done.
* Unrolling loops and converting conditionals to multiplications. This is
crucial for R3xx-R4xx GLSL support. I don't say it will work in all cases
but should be fine for the most common ones. This is kind of a standard in
all proprietary drivers supporting shaders 2.0. It would be nice have it
work with pure TGSI shaders so that drivers like nvfx can reuse it too and I
personally prefer to have this feature first before going on.
* Teaching the R300 compiler loops and conditionals for R500 fragment
shaders. Note that R500 supports the jump instruction so besides adding new
opcodes, the compiler optimization passes should be updated too (I think
they haven't been designed with loops in mind).
* The same but for R500 vertex shaders. The difference is conditionals must
be implemented using predication opcodes and predication writes (stuff gets
masked out). I think this only affects the conversion to machine code at the
end of the pipeline.

2) Derivatives instructions fix

It's implemented but broken. From docs: "If src0 is computed in the previous
instruction, then a NOP needs to be inserted between the two instructions.
Do this by setting the NOP flag in the previous instruction. This is not
required if the previous instruction is a texture lookup." .. and that
should be the fix.

3) Perspective, flat, and centroid varying modifiers, gl_FrontFacing

I think this is specific to the rasterizer (RS) block in hw ([3]).

[1] src/gallium/drivers/r300/r300_tgsi_to_rc.c
[2] src/mesa/drivers/dri/r300/compiler/
[3] src/gallium/drivers/r300/r300_state_derived.c


 Would something
> like passing a subset of the GLSL piglit tests, or being able to correctly
> handle a certain version of GLSL be a good goal for the summer?
>

I guess this question is for Corbin. ;)

-Marek