On Wed, Apr 17, 2013 at 10:26 PM, Brian Paul <bri...@vmware.com> wrote: > On 04/17/2013 02:31 AM, Jose Fonseca wrote: [snipped] >>> 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. No, I don't need the module. >> 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. Yes, that should be a better plan. At first, I will try to figure out where in the state tracker depends on TGSI and try to move the code together to some new files. Then we know clearly what needs to be replaced to support an alternative IR, and we can have both IRs live together for a while.
> 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 -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev