> Looking at it we have two users of unnormalized coords GL texture rect and > OpenCL. From what I can tell it would require a lot more then just a > normalization hint to support OpenCL properly. And as was stated even r600 > hardware will have some problem supporting unnormalized with different edge > cases. The r600 problem was that normalization is in a shader instruction bit, and so they would need a shader recompile for sampler changes. Was there any other r600 issue raised?
> So just creating a new RECT target that matches what GL wants and > then add a cap bit for advanced OpenCL sampling later on, when we know > exactly what OpenCL wants, might be the best solution. It seems to me that adding flag instead of a new texture target would result in less lines of code changed, and a simpler codebase. For example, drivers for DX10 hardware (who don't care about all this) need no modification if we just add flags, but otherwise would need: - target == PIPE_TEXTURE_2D + ((target == PIPE_TEXTURE_2D) || (target == PIPE_TEXTURE_RECT)) applied everywhere. > PS: I know that DX9 requires cards to support a rectangular, last_level 1 > texture with normalized coordinates. But the drivers for DX9 level hw in > Gallium have no user that cares about that case so can it can be ignored. If D3DPTEXTURECAPS_POW2 and D3DPTEXTURECAPS_NONPOW2CONDITIONAL are both set, this is somewhat the case. The DirectX 9 docs however say this, quoted: "This means that a texture with dimensions that are not powers of two cannot be addressed or sampled using texture coordinates computed within the shader". This makes me think that such hardware doesn't actually have support for normalized coordinates, but they are instead adding a multiply to the vertex shader, or using the fixed function texture matrix functionality nv30 has. It seems to me that adding such a mechanism to Gallium is much more trouble than supporting unnormalized coordinates internally. Any DirectX 9 state tracker can either do that itself, or just set D3DPTEXTURECAPS_NONPOW2CONDITIONAL to false. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
