Re: [Mesa-dev] [PATCH 00/17] Rework Mesa/ST shader compilation logic (Part 1)
On Wed, Oct 7, 2015 at 9:54 PM, Brian Paul wrote: > On 10/07/2015 12:34 PM, Brian Paul wrote: >> >> On 10/05/2015 07:26 PM, Marek Olšák wrote: >>> >>> Hi, >>> >>> This is a start of reworking how st/mesa translates and creates >>> shaders. The result of this patch series is this: >>> >>> In LinkShader or ProgramStringNotify, the shader is translated to TGSI >>> as-is. There are no shader code modifications for shader variants. The >>> glsl-to-tgsi visitor is released. >>> >>> We can't release the GLSL IR at this point yet, because core Mesa >>> needs it for program resource queries at least. >>> >>> That's the only place st/mesa interacts with Mesa IR and GLSL IR. >>> After that, it only works with the TGSI representation. >>> >>> When we get to a draw call, tgsi_transform_shader is used to modify >>> shaders to produce shader variants. It does: >>> - feature emulation (color clamping, per-sample shading, edgeflags) >>> - adding glDrawPixels shader code >>> - adding glBitmap shader code >>> >>> All the shader transformations are rewritten completely. There is no >>> patching with Mesa IR or glsl-to-tgsi anymore. >>> >>> It shouldn't be so difficult to add support for some new IR or phase >>> out Mesa IR and GLSL IR support at some point. >>> >>> The main motivations for this series are: >>> - translate to TGSI as soon as possible >>> - possibility to create gallium shaders after that if drivers don't >>> need many variants >>> - if variants are needed, the path to get them is much simpler >>> >>> There will be part 2 when it's ready. >>> >>> Please review. Thanks. >> >> >> I did a quick review and it looks good. Some nice clean-ups for sure. >> >> Unfortunately, it looks like the conform drawpix.c test is now failing >> with this series. It uses glPixelMap so maybe that's it. I'll see if I >> can learn more. > > > Actually, it seems to be glDrawPixels(GL_STENCIL_INDEX) that's failing. > > Piglit's ext_packed_depth_stencil-readdrawpixels is failing also. Can you > check that out? That test passes with radeonsi, softpipe, but doesn't with llvmpipe. I'll take a look. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/17] Rework Mesa/ST shader compilation logic (Part 1)
On 10/07/2015 12:34 PM, Brian Paul wrote: On 10/05/2015 07:26 PM, Marek Olšák wrote: Hi, This is a start of reworking how st/mesa translates and creates shaders. The result of this patch series is this: In LinkShader or ProgramStringNotify, the shader is translated to TGSI as-is. There are no shader code modifications for shader variants. The glsl-to-tgsi visitor is released. We can't release the GLSL IR at this point yet, because core Mesa needs it for program resource queries at least. That's the only place st/mesa interacts with Mesa IR and GLSL IR. After that, it only works with the TGSI representation. When we get to a draw call, tgsi_transform_shader is used to modify shaders to produce shader variants. It does: - feature emulation (color clamping, per-sample shading, edgeflags) - adding glDrawPixels shader code - adding glBitmap shader code All the shader transformations are rewritten completely. There is no patching with Mesa IR or glsl-to-tgsi anymore. It shouldn't be so difficult to add support for some new IR or phase out Mesa IR and GLSL IR support at some point. The main motivations for this series are: - translate to TGSI as soon as possible - possibility to create gallium shaders after that if drivers don't need many variants - if variants are needed, the path to get them is much simpler There will be part 2 when it's ready. Please review. Thanks. I did a quick review and it looks good. Some nice clean-ups for sure. Unfortunately, it looks like the conform drawpix.c test is now failing with this series. It uses glPixelMap so maybe that's it. I'll see if I can learn more. Actually, it seems to be glDrawPixels(GL_STENCIL_INDEX) that's failing. Piglit's ext_packed_depth_stencil-readdrawpixels is failing also. Can you check that out? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/17] Rework Mesa/ST shader compilation logic (Part 1)
On 10/05/2015 07:26 PM, Marek Olšák wrote: Hi, This is a start of reworking how st/mesa translates and creates shaders. The result of this patch series is this: In LinkShader or ProgramStringNotify, the shader is translated to TGSI as-is. There are no shader code modifications for shader variants. The glsl-to-tgsi visitor is released. We can't release the GLSL IR at this point yet, because core Mesa needs it for program resource queries at least. That's the only place st/mesa interacts with Mesa IR and GLSL IR. After that, it only works with the TGSI representation. When we get to a draw call, tgsi_transform_shader is used to modify shaders to produce shader variants. It does: - feature emulation (color clamping, per-sample shading, edgeflags) - adding glDrawPixels shader code - adding glBitmap shader code All the shader transformations are rewritten completely. There is no patching with Mesa IR or glsl-to-tgsi anymore. It shouldn't be so difficult to add support for some new IR or phase out Mesa IR and GLSL IR support at some point. The main motivations for this series are: - translate to TGSI as soon as possible - possibility to create gallium shaders after that if drivers don't need many variants - if variants are needed, the path to get them is much simpler There will be part 2 when it's ready. Please review. Thanks. I did a quick review and it looks good. Some nice clean-ups for sure. Unfortunately, it looks like the conform drawpix.c test is now failing with this series. It uses glPixelMap so maybe that's it. I'll see if I can learn more. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/17] Rework Mesa/ST shader compilation logic (Part 1)
On 6 October 2015 at 11:26, Marek Olšák wrote: > Hi, > > This is a start of reworking how st/mesa translates and creates shaders. The > result of this patch series is this: > > In LinkShader or ProgramStringNotify, the shader is translated to TGSI as-is. > There are no shader code modifications for shader variants. The glsl-to-tgsi > visitor is released. > > We can't release the GLSL IR at this point yet, because core Mesa needs it > for program resource queries at least. > > That's the only place st/mesa interacts with Mesa IR and GLSL IR. After that, > it only works with the TGSI representation. > > When we get to a draw call, tgsi_transform_shader is used to modify shaders > to produce shader variants. It does: > - feature emulation (color clamping, per-sample shading, edgeflags) > - adding glDrawPixels shader code > - adding glBitmap shader code > > All the shader transformations are rewritten completely. There is no patching > with Mesa IR or glsl-to-tgsi anymore. > > It shouldn't be so difficult to add support for some new IR or phase out Mesa > IR and GLSL IR support at some point. > > The main motivations for this series are: > - translate to TGSI as soon as possible > - possibility to create gallium shaders after that if drivers don't need many > variants > - if variants are needed, the path to get them is much simpler > I'm happy where this stuff is going, I've looked over it for anything really obviously wrong, but it seems sane enough for me to at least be willing to debug in the future :-) Reviewed-by: Dave Airlie for the series. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
