Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view
On 25.02.2010 18:39, michal wrote: Roland Scheidegger wrote on 2010-02-24 15:18: On 24.02.2010 12:48, Christoph Bumiller wrote: This wasn't a problem before because textures and samplers were linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, this coordinate normalization bit becomes a problem. NV50 hardware has that bit in the RESOURCE binding, and not the SAMPLER binding, and you can imagine that this will lead to us having to jump through a few annoying looking hoops to accomodate. As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have sampler states that are decoupled from the texture, and which contain a normalized coordinates bit, so it's worth considering not having it there in gallium either. For OpenGL, unnormalized coordinates are only used for RECT textures, and in this case it makes sense to make it a property of the texture. I agree this is not sampler state, but I don't quite agree this should be texture state. This changes how texture coordinates get interpreted in the interpolator - in that sense it is similar to the cylindrical texture coord wrap which we moved away from sampler state recently. This one got moved to shader declaration. I wonder if the normalization bit should be treated the same. Though OTOH you're quite right that in OpenGL this really is texture property (it is a different texture target after all), and afaik d3d doesn't support non-normalized coords (?). Hmm... Isn't it the case that for RECT targets we clear the bit, and for others we always set it? In mesa st I see: if (texobj-Target != GL_TEXTURE_RECTANGLE_ARB) sampler-normalized_coords = 1; By definition, RECT texture with normalised coordinates is just an NPOT. If we removed this apparently redundant flag, would that make nouveau developers life easier? But we don't have rect targets in gallium hence we need the flag. I think conceptually this makes sense since for texture layouts etc. drivers won't care one bit if this is 2d npot or rect texture. Though I guess introducing rect targets instead would be another option. Roland And, finally, I've seen you reverted the changes for independent image and sampler index in the texture opcodes. What's up with that ? Is the code not nice enough, or has the idea been discarded and by problem disappears ? Please consider this branch dead. It will be easier for me to introduce new, optional sampler and fetch opcodes a'la GL 3.0. There's just too much code to fix and test and we still want the older hardware not to stand on its head to try and translate back to old model. Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view
Roland Scheidegger wrote: On 25.02.2010 18:39, michal wrote: Roland Scheidegger wrote on 2010-02-24 15:18: On 24.02.2010 12:48, Christoph Bumiller wrote: This wasn't a problem before because textures and samplers were linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, this coordinate normalization bit becomes a problem. NV50 hardware has that bit in the RESOURCE binding, and not the SAMPLER binding, and you can imagine that this will lead to us having to jump through a few annoying looking hoops to accomodate. As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have sampler states that are decoupled from the texture, and which contain a normalized coordinates bit, so it's worth considering not having it there in gallium either. For OpenGL, unnormalized coordinates are only used for RECT textures, and in this case it makes sense to make it a property of the texture. I agree this is not sampler state, but I don't quite agree this should be texture state. This changes how texture coordinates get interpreted in the interpolator - in that sense it is similar to the cylindrical texture coord wrap which we moved away from sampler state recently. This one got moved to shader declaration. I wonder if the normalization bit should be treated the same. Though OTOH you're quite right that in OpenGL this really is texture property (it is a different texture target after all), and afaik d3d doesn't support non-normalized coords (?). Hmm... Isn't it the case that for RECT targets we clear the bit, and for others we always set it? In mesa st I see: if (texobj-Target != GL_TEXTURE_RECTANGLE_ARB) sampler-normalized_coords = 1; By definition, RECT texture with normalised coordinates is just an NPOT. If we removed this apparently redundant flag, would that make nouveau developers life easier? But we don't have rect targets in gallium hence we need the flag. I think conceptually this makes sense since for texture layouts etc. drivers won't care one bit if this is 2d npot or rect texture. Though I guess introducing rect targets instead would be another option. We should also be thinking about texture array targets. With a 2D texture array, the S and T coords would be normalized, but not R. I think we either need new texture targets for RECT, 1D_ARRAY, 2D_ARRAY, etc. or per-dimension normalization flags. I'm thinking the former may be better (simpler) since textures are created as a particular type and not changed afterward. We also know the texture type/target when we execute TEX shader instructions. If it's part of sampler state it gives the impression that it's variable state, but it really isn't. -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view
Roland Scheidegger wrote on 2010-02-24 15:18: On 24.02.2010 12:48, Christoph Bumiller wrote: This wasn't a problem before because textures and samplers were linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, this coordinate normalization bit becomes a problem. NV50 hardware has that bit in the RESOURCE binding, and not the SAMPLER binding, and you can imagine that this will lead to us having to jump through a few annoying looking hoops to accomodate. As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have sampler states that are decoupled from the texture, and which contain a normalized coordinates bit, so it's worth considering not having it there in gallium either. For OpenGL, unnormalized coordinates are only used for RECT textures, and in this case it makes sense to make it a property of the texture. I agree this is not sampler state, but I don't quite agree this should be texture state. This changes how texture coordinates get interpreted in the interpolator - in that sense it is similar to the cylindrical texture coord wrap which we moved away from sampler state recently. This one got moved to shader declaration. I wonder if the normalization bit should be treated the same. Though OTOH you're quite right that in OpenGL this really is texture property (it is a different texture target after all), and afaik d3d doesn't support non-normalized coords (?). Hmm... Isn't it the case that for RECT targets we clear the bit, and for others we always set it? In mesa st I see: if (texobj-Target != GL_TEXTURE_RECTANGLE_ARB) sampler-normalized_coords = 1; By definition, RECT texture with normalised coordinates is just an NPOT. If we removed this apparently redundant flag, would that make nouveau developers life easier? And, finally, I've seen you reverted the changes for independent image and sampler index in the texture opcodes. What's up with that ? Is the code not nice enough, or has the idea been discarded and by problem disappears ? Please consider this branch dead. It will be easier for me to introduce new, optional sampler and fetch opcodes a'la GL 3.0. There's just too much code to fix and test and we still want the older hardware not to stand on its head to try and translate back to old model. Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view
Christoph Bumiller wrote on 2010-02-25 19:39: On 25.02.2010 19:00, Brian Paul wrote: Roland Scheidegger wrote: On 25.02.2010 18:39, michal wrote: Roland Scheidegger wrote on 2010-02-24 15:18: On 24.02.2010 12:48, Christoph Bumiller wrote: This wasn't a problem before because textures and samplers were linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, this coordinate normalization bit becomes a problem. NV50 hardware has that bit in the RESOURCE binding, and not the SAMPLER binding, and you can imagine that this will lead to us having to jump through a few annoying looking hoops to accomodate. As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have sampler states that are decoupled from the texture, and which contain a normalized coordinates bit, so it's worth considering not having it there in gallium either. For OpenGL, unnormalized coordinates are only used for RECT textures, and in this case it makes sense to make it a property of the texture. I agree this is not sampler state, but I don't quite agree this should be texture state. This changes how texture coordinates get interpreted in the interpolator - in that sense it is similar to the cylindrical texture coord wrap which we moved away from sampler state recently. This one got moved to shader declaration. I wonder if the normalization bit should be treated the same. Though OTOH you're quite right that in OpenGL this really is texture property (it is a different texture target after all), and afaik d3d doesn't support non-normalized coords (?). Hmm... Isn't it the case that for RECT targets we clear the bit, and for others we always set it? In mesa st I see: if (texobj-Target != GL_TEXTURE_RECTANGLE_ARB) sampler-normalized_coords = 1; By definition, RECT texture with normalised coordinates is just an NPOT. If we removed this apparently redundant flag, would that make nouveau developers life easier? But we don't have rect targets in gallium hence we need the flag. I think conceptually this makes sense since for texture layouts etc. drivers won't care one bit if this is 2d npot or rect texture. Though I guess introducing rect targets instead would be another option. We should also be thinking about texture array targets. With a 2D texture array, the S and T coords would be normalized, but not R. I think we either need new texture targets for RECT, 1D_ARRAY, 2D_ARRAY, etc. or per-dimension normalization flags. I'm thinking the former may be better (simpler) since textures are created as a particular type and not changed afterward. We also know the texture type/target when we execute TEX shader instructions. If it's part of sampler state it gives the impression that it's variable state, but it really isn't. We'd also need a BUFFER target then, they also have scaled coordinates. The problem is I think that this drivers gallium a little towards catering towards specific APIs (OpenGL). OpenCL for instance does have a per sampler normalization bit iirc, but it seems there's no hardware that reflects this property. Then again, TGSI does have a RECT target already, so we might as well add corresponding PIPE targets. I want to remind again that the normalization bit only becomes problematic once samplers and textures can be independently combined, and that it seems older hardware can't nicely do this anyway, except if they take it upon them to recompile their shaders (although I hear some need to do that already ...) I admit I'm actually being a bit selfish here, trying to get the interface more adapted to nv50, but, if other hardware doesn't have conflicting views, why not ? Maybe I should accept nv50 is getting old. Why do you say that? NV50 is a DX10-level card -- it deserves better treatment. Your request is valid and we should go and ask gallium gatekeepers to get this change pushed. Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view
On 25.02.2010 19:00, Brian Paul wrote: Roland Scheidegger wrote: On 25.02.2010 18:39, michal wrote: Roland Scheidegger wrote on 2010-02-24 15:18: On 24.02.2010 12:48, Christoph Bumiller wrote: This wasn't a problem before because textures and samplers were linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, this coordinate normalization bit becomes a problem. NV50 hardware has that bit in the RESOURCE binding, and not the SAMPLER binding, and you can imagine that this will lead to us having to jump through a few annoying looking hoops to accomodate. As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have sampler states that are decoupled from the texture, and which contain a normalized coordinates bit, so it's worth considering not having it there in gallium either. For OpenGL, unnormalized coordinates are only used for RECT textures, and in this case it makes sense to make it a property of the texture. I agree this is not sampler state, but I don't quite agree this should be texture state. This changes how texture coordinates get interpreted in the interpolator - in that sense it is similar to the cylindrical texture coord wrap which we moved away from sampler state recently. This one got moved to shader declaration. I wonder if the normalization bit should be treated the same. Though OTOH you're quite right that in OpenGL this really is texture property (it is a different texture target after all), and afaik d3d doesn't support non-normalized coords (?). Hmm... Isn't it the case that for RECT targets we clear the bit, and for others we always set it? In mesa st I see: if (texobj-Target != GL_TEXTURE_RECTANGLE_ARB) sampler-normalized_coords = 1; By definition, RECT texture with normalised coordinates is just an NPOT. If we removed this apparently redundant flag, would that make nouveau developers life easier? But we don't have rect targets in gallium hence we need the flag. I think conceptually this makes sense since for texture layouts etc. drivers won't care one bit if this is 2d npot or rect texture. Though I guess introducing rect targets instead would be another option. We should also be thinking about texture array targets. With a 2D texture array, the S and T coords would be normalized, but not R. I think we either need new texture targets for RECT, 1D_ARRAY, 2D_ARRAY, etc. or per-dimension normalization flags. I'm thinking the former may be better (simpler) since textures are created as a particular type and not changed afterward. We also know the texture type/target when we execute TEX shader instructions. If it's part of sampler state it gives the impression that it's variable state, but it really isn't. We'd also need a BUFFER target then, they also have scaled coordinates. The problem is I think that this drivers gallium a little towards catering towards specific APIs (OpenGL). OpenCL for instance does have a per sampler normalization bit iirc, but it seems there's no hardware that reflects this property. Then again, TGSI does have a RECT target already, so we might as well add corresponding PIPE targets. I want to remind again that the normalization bit only becomes problematic once samplers and textures can be independently combined, and that it seems older hardware can't nicely do this anyway, except if they take it upon them to recompile their shaders (although I hear some need to do that already ...) I admit I'm actually being a bit selfish here, trying to get the interface more adapted to nv50, but, if other hardware doesn't have conflicting views, why not ? Maybe I should accept nv50 is getting old. What about future hardware ? Well, we don't know how Fermi works in this respect yet, and I don't think $MANUFACTURER will tell us .. Christoph -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view
On Thu, Feb 25, 2010 at 12:39 PM, michal mic...@vmware.com wrote: Roland Scheidegger wrote on 2010-02-24 15:18: On 24.02.2010 12:48, Christoph Bumiller wrote: This wasn't a problem before because textures and samplers were linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, this coordinate normalization bit becomes a problem. NV50 hardware has that bit in the RESOURCE binding, and not the SAMPLER binding, and you can imagine that this will lead to us having to jump through a few annoying looking hoops to accomodate. As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have sampler states that are decoupled from the texture, and which contain a normalized coordinates bit, so it's worth considering not having it there in gallium either. For OpenGL, unnormalized coordinates are only used for RECT textures, and in this case it makes sense to make it a property of the texture. I agree this is not sampler state, but I don't quite agree this should be texture state. This changes how texture coordinates get interpreted in the interpolator - in that sense it is similar to the cylindrical texture coord wrap which we moved away from sampler state recently. This one got moved to shader declaration. I wonder if the normalization bit should be treated the same. Though OTOH you're quite right that in OpenGL this really is texture property (it is a different texture target after all), and afaik d3d doesn't support non-normalized coords (?). Hmm... Isn't it the case that for RECT targets we clear the bit, and for others we always set it? In mesa st I see: if (texobj-Target != GL_TEXTURE_RECTANGLE_ARB) sampler-normalized_coords = 1; By definition, RECT texture with normalised coordinates is just an NPOT. If we removed this apparently redundant flag, would that make nouveau developers life easier? FWIW, r3xx-r5xx always requires normalized coords, the normalization is currently done in the shader. On r6xx+, you can specify normalized or non-normalized coords in the tex instructions. Alex And, finally, I've seen you reverted the changes for independent image and sampler index in the texture opcodes. What's up with that ? Is the code not nice enough, or has the idea been discarded and by problem disappears ? Please consider this branch dead. It will be easier for me to introduce new, optional sampler and fetch opcodes a'la GL 3.0. There's just too much code to fix and test and we still want the older hardware not to stand on its head to try and translate back to old model. Thanks. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view
On Thu, Feb 25, 2010 at 11:00:28AM -0700, Brian Paul wrote: We should also be thinking about texture array targets. With a 2D texture array, the S and T coords would be normalized, but not R. I think we either need new texture targets for RECT, 1D_ARRAY, 2D_ARRAY, etc. or per-dimension normalization flags. I'm thinking the former may be better (simpler) since textures are created as a particular type and not changed afterward. We also know the texture type/target when we execute TEX shader instructions. If it's part of sampler state it gives the impression that it's variable state, but it really isn't. The latter is probably unworkable because : - filtering is done only on the selected texture and not between elements of the array - mipmaps are per-selected texture, giving a very different layout than the dim+1 texture type Intel has different hardware types for say 2D_ARRAY vs. 3D, probably for these reasons. OG. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view
On 24.02.2010 12:48, Christoph Bumiller wrote: This wasn't a problem before because textures and samplers were linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch, this coordinate normalization bit becomes a problem. NV50 hardware has that bit in the RESOURCE binding, and not the SAMPLER binding, and you can imagine that this will lead to us having to jump through a few annoying looking hoops to accomodate. As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have sampler states that are decoupled from the texture, and which contain a normalized coordinates bit, so it's worth considering not having it there in gallium either. For OpenGL, unnormalized coordinates are only used for RECT textures, and in this case it makes sense to make it a property of the texture. I agree this is not sampler state, but I don't quite agree this should be texture state. This changes how texture coordinates get interpreted in the interpolator - in that sense it is similar to the cylindrical texture coord wrap which we moved away from sampler state recently. This one got moved to shader declaration. I wonder if the normalization bit should be treated the same. Though OTOH you're quite right that in OpenGL this really is texture property (it is a different texture target after all), and afaik d3d doesn't support non-normalized coords (?). Hmm... Roland And, finally, I've seen you reverted the changes for independent image and sampler index in the texture opcodes. What's up with that ? Is the code not nice enough, or has the idea been discarded and by problem disappears ? Best regards, Christoph -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
