[Mesa-dev] [PATCH 2/2] i965: Bump BRW_MAX_TEX_UNIT to 32.

Chris Forbes chrisf at ijw.co.nz
Fri Jan 17 13:57:09 PST 2014


Ken,

Assuming the caches don't completely derail things, you ought to be
able to make this work with pretty minimal impact:

- Keep the low four bits of the sampler index where they are
- If the 5th bit is set:
    - Force message header on
    - Add 16*sizeof(sampler_state) to the copy of r0.3 in the header.

We already mangle the copy of r0.2 in various ways for offsetting /
channel select so this isn't a huge change.

With 4.0/ARB_gpu_shader5 you need to emit conditional code in some
cases since you don't always know the sampler index at compile time,
but it's still pretty manageable.

-- Chris



On Sat, Jan 18, 2014 at 10:22 AM, Ian Romanick <idr at freedesktop.org> wrote:
> On 01/17/2014 01:08 PM, Marek Olšák wrote:
>> The test seems to work correctly with 32 textures per stage. It tests
>> that all textures return the correct color, but the sampler state is
>> always the same.
>
> Which is the problem.  The method we're using to access samplers works
> fine for up to 16, but fails after that... by dropping the high-order
> index bits.  If all the samplers are the same, the test won't notice
> that Ken's implementation is garbage. :(
>
>> Marek
>>
>> On Thu, Jan 16, 2014 at 1:28 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
>>> On 01/15/2014 12:56 PM, Chris Forbes wrote:
>>>> Does this actually work for >16?
>>>>
>>>> Sampler messages' descriptor only has 4 bits for the sampler index, so
>>>> it seems you'd silently lose the top bit and get the wrong sampler
>>>> parameters.
>>>
>>> Oh, wow.  No...no, it can't possibly work then.  (Apparently that Piglit
>>> test isn't sufficient...I just glanced at it...)
>>>
>>> It looks like the Intel Windows driver has bumped this to 32 on Haswell
>>> (but not earlier).  I'm guessing that they use the "Sampler State
>>> Pointer" field in the message /header/, instead of the "Sampler Index"
>>> field in the message /descriptor/.  On Haswell, that changed to be
>>> relative to Dynamic State Base Address instead of General State Base
>>> Address.  Which probably helps.
>>>
>>> Still, that's probably going to be kind of miserable.  I'll have to look
>>> into what they're doing.
>>>
>>> NAK on patch 2.
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list