On 04/17/2013 02:31 AM, Jose Fonseca wrote:
----- Original Message -----
On Wed, Apr 17, 2013 at 8:09 AM, Marek Olšák<mar...@gmail.com> wrote:
On Tue, Apr 16, 2013 at 9:58 PM, Chia-I Wu<olva...@gmail.com> wrote:
On Wed, Apr 17, 2013 at 12:58 AM, Matt Turner<matts...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
