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 <div class="gmail_quote">On Thu, Apr 15, 2010 at 6:34 PM, Roland Scheidegger <<a href="mailto:sroland@vmware.com" target="_blank">sroland@vmware.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div>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. </div></div>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 <div><div></div><div>_______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </div></div></blockquote></div>