[Mesa-dev] [RFC] [PATCH 0/2] Allow mesa/st to inform driver of GL_TEXTURE_RECTANGLE

Marek Olšák maraeo at gmail.com
Thu Apr 15 10:54:22 PDT 2010


Honestly I'd like to have one way to recognize that a texture is addressed
by non-normalized coordinates.

Right now we have two:
1) in TGSI via TGSI_TEXTURE_RECT (like OpenGL)
2) in pipe_sampler_state via normalized_coord (like OpenCL)

And Luca's proposal completes the OpenGL way.

I think the first two don't get along well with each other. What if I get
the RECT sampler target and normalized_coord == 1?

r300 likes the first way because the "normalized" bit is part of the TEX
instruction, though recompiling shaders is not a big deal from the
implementation point of view since we already do this for shadow samplers
and newly for the repeat and mirrored wrap modes of NPOT textures, thanks to
the flexibility of our compiler, but it's a burden and pollutes the command
stream with fragment shader instructions and constants, and probably impacts
performance too.

nv50 seems to use the second way but it could also go well with Luca's one.
I'd vote for the "normalized" bit to be an immutable property of
pipe_texture, possibly introducing a PIPE_TEXTURE_RECT target as that would
make life of D3D9-level hw drivers easier.

-Marek

On Thu, Apr 15, 2010 at 6:34 PM, Roland Scheidegger <sroland at vmware.com>wrote:

> On 15.04.2010 09:36, Luca Barbieri wrote:
> > See also the RFC-gallium-unnormalized-coords-hint branch.
> >
> > Currently the Gallium driver has no way of telling that a texture was
> created
> > with GL_TEXTURE_RECTANGLE as opposed to GL_TEXTURE_2D.
> >
> > Unfortunately, some hardware like nv30 has two texture layouts, and the
> > first only works with unnormalized coordinates (and has no mipmap
> support),
> > and the second only works with normalized coordinates (and requires POT
> sizes).
> >
> > Thus, it is beneficial to know which kind of coordinates are going to be
> used at
> > texture creation time.
> >
> > Fortunately, with OpenGL, whether normalized or unnormalized coordinates
> can
> > be used is decided at creation time, but we don't currently pass this to
> > the driver.
> >
> > This branch adds a new resource flag that is used by the state trackers
> to
> > tell the driver whether it is going to typically use sampler states with
> > normalized_coords = 0.
> >
> > In practice, the OpenGL state tracker sets it if and only if
> GL_TEXTURE_RECTANGLE
> > is being used as the texture target.
> >
> > Note that this patch series does *not* make this a mandatory flag, but
> rather an
> > hint: the driver is theoretically supposed to either change the texture
> layout
> > or alter the fragment shader if a normalization mismatch happens.
> >
> > The general idea is that the weird pre-DirectX 10 restrictions for
> texture sizes
> > should be hidden by the driver, and not exposed to the state tracker.
> >
> > Currently the NPOT cap exposes them a bit, but r300g just lifted all
> restrictions
> > and hopefully nv30 will too (nv40 also has the minor restriction of not
> supporting
> > unnormalized coordinates with mipmaps).
> >
> > However, this flag is still likely to be useful to avoid unnecessary
> overhead.
> >
> > Right now, it's required to correctly support ARB_texture_rectangle on
> nv30.
> >
> > The impact on Gallium is quite minimal.
>
> So, since one layout requires pot sizes, I guess the problem you have is
> if a texture rectangle just happens to be POT you don't know that in the
> driver upon texture creation time?
> It's quite common for hw to have different layouts for pot and npot,
> though normally they don't tie normalized vs non-normalized coordinates
> to it... Seems like an odd choice, so if you do render to texture (to a
> npot size) then you need to adjust the fragment shader for the
> non-normalized texture coords?
> Your solution looks acceptable to me, since drivers are free to ignore
> that flag, though maybe someone else has objections.
>
> Roland
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100415/9e335f46/attachment.htm>


More information about the mesa-dev mailing list