Luca Barbieri wrote: > On Wed, Jan 27, 2010 at 5:49 PM, Brian Paul <bri...@vmware.com> wrote: >> Luca Barbieri wrote: >>> Changes in v3: >>> - Use positive caps instead of negative ones >>> >>> Changes in v2: >>> - Updated formatting >>> >>> The state tracker will use the TGSI convention properties if the hardware >>> exposes the appropriate capability, and otherwise adjust WPOS itself. >>> >>> This will also fix some drivers that were previously broken due to their >>> incorrect, inadvertent, use of conventions other than >>> upper_left+half_integer. >> Minor comments below. >> >> >>> --- >>> src/mesa/state_tracker/st_extensions.c | 1 + >>> src/mesa/state_tracker/st_mesa_to_tgsi.c | 74 >>> ++++++++++++++++++++++++++++- >>> 2 files changed, 72 insertions(+), 3 deletions(-) >>> >>> diff --git a/src/mesa/state_tracker/st_extensions.c >>> b/src/mesa/state_tracker/st_extensions.c >>> index 60732f3..982a1fb 100644 >>> --- a/src/mesa/state_tracker/st_extensions.c >>> +++ b/src/mesa/state_tracker/st_extensions.c >>> @@ -147,6 +147,7 @@ void st_init_extensions(struct st_context *st) >>> * Extensions that are supported by all Gallium drivers: >>> */ >>> ctx->Extensions.ARB_copy_buffer = GL_TRUE; >>> + ctx->Extensions.ARB_fragment_coord_conventions = GL_TRUE; >> We can't really expose this extension until we've updated GLSL to understand >> layout qualifiers. And, unfortunately, that builds on GLSL 1.40 which we >> don't support yet. > I think we shoud do this by keeping the quoted line, but changing Mesa > so that ctx->Extensions.ARB_fragment_coord_conventions does not > actually cause the extension string to be returned by the user until > the GLSL part is implemented.
Hmmm, I'd really rather not special-case the extension code for this one thing. > Otherwise, if we remove that line, the ARBfp parser will refuse to > recognize the new keywords. > > BTW, I think the layout keyword can be added to the current GLSL, as > the extension spec says: > << > RESOLVED: Yes. This has been recast to use layout qualifiers > originally introduced in GLSL 1.40 and extended in GLSL 1.50. > However note that it is the intent of this extension to stand > separately from the GLSL 1.40/1.50 and it is desinged to be > implementable against GLSL 1.10 or 1.20. OK, I missed that part. I guess we could just expose the extension and keep in mind that lack of GLSL support is a known issue. I could try to implement it in GLSL as soon as I find some spare time... -Brian ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
