[Mesa-dev] [RFC] [PATCH 0/3] Make Gallium aware of GL_TEXTURE_RECTANGLE
e0425955 at student.tuwien.ac.at
Thu Aug 12 08:55:55 PDT 2010
On 08/12/2010 04:06 AM, Marek Olšák wrote:
> On Wed, Aug 11, 2010 at 10:07 PM, Luca Barbieri <luca at luca-barbieri.com>wrote:
>>> Because all nvidia hardware seems to have the normalized bit as a
>>> of a resource (PIPE_TEXTURE_RECT or a flag would be okay here), and all
>>> hardware has the normalized bit as part of the texture instruction (it's
>>> shader state, so a driver looks for TGSI_TEXTURE_RECT), I believe it
>>> 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.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev