[Mesa-dev] EXT_texture_snorm - is it possible in GL2?

Marek Olšák maraeo at gmail.com
Tue Mar 15 08:49:25 PDT 2011

Yeah, it's the worst spec I have ever read.

I am using the GL3.1 spec instead. There is also a trivial interaction with
ARB_color_buffer_float. If I read the 3.1 spec correctly, there is no way to
store _unclamped_ values to a signed normalized texture when rendering to it
without a call to glClampColorARB to disable fragment color clamping.

BTW I am almost done with EXT_texture_snorm and am doing final testing. I
will send patches soon along with ARB_color_buffer_float.


On Tue, Mar 15, 2011 at 4:23 PM, Ian Romanick <idr at freedesktop.org> wrote:

> Hash: SHA1
> On 03/10/2011 02:46 PM, Marek Olšák wrote:
> > The specification of GL_EXT_texture_snorm says:
> >
> >     OpenGL 3.0 is required.
> >
> >     This extension is written against the OpenGL 3.0 specification.
> And then all of the chapter headings in the spec say "Additions to
> Chapter # of the OpenGL 2.0 Specification".  lol
> > which simply means we cannot advertise the extension on GL2.1. Would
> > anyone be against violating the requirement?
> >
> > The thing is even some of GL2 hardware can do it, and GL3 likely won't
> > be supported anytime soon due to unresolved patent issues.
> My recollection is that AMD (where all of the spec authors live) only
> wanted to advertise it with OpenGL 3.x, and they didn't want to specify
> the interactions.  It looks like the only interactions are with
> GL_ARB_texture_rg.  I think it's safe to advertise this on 2.x hardware
> as long as GL_ARB_texture_rg is also supported.  This makes sense given
> that the most common usage is for normal maps.
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> iEYEARECAAYFAk1/hFcACgkQX1gOwKyEAw+HzwCeLzt30HuvdcGrdxKazUkardHo
> 8LAAn3H8cSVuewCG3vCuqcVhHKLAvIxW
> =iVP5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110315/82081936/attachment.htm>

More information about the mesa-dev mailing list