From: Brian P. <br...@tu...> - 2002-09-30 16:11:07
|
Ian Romanick wrote: > On Mon, Sep 30, 2002 at 09:22:00AM -0600, Brian Paul wrote: > >>Ian Romanick wrote: >> >>>Hello all. >>> >>>I noticed that NV_texture_rectangle appeared in the R100 driver string after >>>then recent R200 merge. I did some looking around, and found that it is >>>explicitly enabled in the R200 driver and has code to support rectangular >>>textures. It seems that it is enabled by default in Mesa. Is this correct? >> >>It's enabled for the R200 driver and software rendering only. > > > That may be the desired result, but extras/Mesa/src/extensions.c, line 113 > tells me differently: > > { ON, "GL_NV_texture_rectangle", F(NV_texture_rectangle) }, > > It shows up in the extension string from glxinfo on the R100 driver. Oops, that's an accident. I'll fix it. >>>I didn't dig deep enough in Mesa to see if it would somehow automatically >>>convert a rectangle to a power-of-two, so this might be okay. >> >>It does not do that. The texture targets GL_TEXTURE_2D and >>GL_TEXTURE_RECTANGLE_NV are distinct. > > > Okay. That's what I figured. Thanks for saving my dig time. :) > > [snip] > > >>Simulating NPOT textures with conventional targets could be pretty tricky. >>Note that NPOT texture coordinates range from [0,Width]x[0,Height], not >>[0,1]x[0,1] as normal textures do. Some clamp/repeat modes aren't supported >>either. > > > Right. Mipmap (and ansio?) filter modes are also forbidden. I gave this a > bit more thought after my last message. I don't think this is something > that Mesa could automatically do. It would have to be done on a per-driver > basis. You'd have to change the texture upload routines (easy) and the emit > routines (hard). If NV_texture_rectangle still used [0,1]x[0,1], it would > be pretty easy. I suppose we could multiply the S and T coords by the texture size, but that might upset the LOD calculation which is needed to choose between the mini- fication and magnification filter (even though we don't have mipmaps). -Brian |