On 08/12/2010 04:06 AM, Marek Olšák wrote: > On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri <l...@luca-barbieri.com>wrote: > >>> Because all nvidia hardware seems to have the normalized bit as a >> property >>> of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all >> ATI >>> hardware has the normalized bit as part of the texture instruction (it's >> a >>> shader state, so a driver looks for TGSI_TEXTURE_RECT), I believe it >> would >>> really be best for everyone to have this RECT texture target type and >>> removing normalized_coords from pipe_sampler_state. Luca, you've already >>> done some work for this change. If you don't have time to finish >>> PIPE_TEXTURE_RECT, I'll do that. >> >> So no hardware at all supports specifying the normalization as part of >> the sampler state? >> >> One has to keep in mind OpenCL though, which has the following API: >> cl_sampler clCreateSampler (cl_context context, >> cl_bool normalized_coords, >> cl_addressing_mode addressing_mode, >> cl_filter_mode filter_mode, cl_int *errcode_ret) >> >> If you put the bit in the resource itself, then it becomes impossible >> to change the normalization without copying the whole resource, which >> would seem to be a major problem for implementing OpenCL. >> >> A possible solution could be removing the bit from the sampler state >> and adding the bit to both TEX instructions and sampler views. >> This would seem to suit nv50, which has it in the hardware sampler >> view, and r300-r700 which has it in the hardware shader instruction >> (according to you). >> I'm not sure if it is good enough for OpenCL (i.e. whether the OpenCL >> state tracker can statically determine the sampler<->texture mapping), >> but I suppose it is, since it matches the hardware and the proprietary >> drivers manage to support OpenCL. >> >> A flag would need to be passed on resource creation anyway though, >> since nv30 needs to use different memory layouts. >> >> Also in this option, adding the resource hint and moving the bit out >> from the sampler state would be independent. >> > > ACK for your patch series from me. Getting rid of that normalized_coords bit > in pipe_sampler_state would make implementing OpenCL really hard. I'll try
Not harder than implementing the same thing (which is rewriting the shaders or generating suboptimal ones in the first place) in a pipe driver. There are lots of other things that make OpenCL really hard to implement, like the lack of MEMORY or a calling convention (all subroutines exclusively use global variables) in TGSI. > to come up with a sane way to rewrite shaders for all ATI hardware. Masking > out PIPE_RESOURCE_FLAG_UNNORMALIZED_COORDS_HINT in r600_texture_create > should be enough to keep r600g in a working state. > > -Marek > > > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
