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 <i...@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 <kenn...@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@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
>
> _______________________________________________
> 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
