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

[Christoph Bumiller]

On 04/15/2010 07:54 PM, Marek Olšák wrote:
> 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.
nv50 only has 1 way of laying out textures as far as I've seen, and
oddly, the blob even uses height 4 tiles for 1D textures (except for
buffer textures which are linear, thankfully).
It can dynamically change coordinate normalization in the texture image
description memory block (which's entries can be bound independently of
the sampler configuration entries). This is again odd because there
seems to be an extra RECT target in the texture image configuration,
possibly I can have RECT textures with mipmaps and normalized coords.

That said, having coordinates a fixed property of the texture is
easiest, because then we won't have to examine any other state.

> 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.
> 
I concur.
And let's make OpenCL conform to that, too. Always keep in mind that one
day you will have separate texture and sampler objects in TGSI that can
be dynamically combined.
Meh, for your anitquated cards you can actually ignore that.

Determining normalization from shader's sampler type and being able to
bind textures of type A to sampler of type B is doable as well, we'd
just have to update some memory blocks and flush the texture config
entries cache, and everyone likes doing some extra work in order to
facilitate the life of non-existent state trackers ...

Christoph

> -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
>>
> 
> 
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev