[Mesa-dev] [PATCH 00/41] Welcome back Matt!
Connor Abbott
cwabbott0 at gmail.com
Tue Sep 23 15:04:13 PDT 2014
On Tue, Sep 23, 2014 at 2:43 PM, Matt Turner <mattst88 at gmail.com> wrote:
> On Sat, Sep 20, 2014 at 10:22 AM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> This series does a bunch of refactoring of the i965 fs backend IR to add
>> concepts of register width and instruction execution size. There's more to
>> be done yet, but this gets us most of the way there. It also removes the
>> assumption that scalar values are always 1 register in SIMD8 and 2
>> registers in SIMD16. In particular, we get the following:
>>
>> 1) No more assumption about everything being 1 register. This allows us
>> to allocate odd numbers of registers in SIMD16 which is needed for some
>> payloads. Also, it should make implementing fp64 much easier because
>> we can now sanely registers of size 2 in SIMD8 and size 4 in SIMD16.
>> There's a little more work to be don there, but this should take care
>> of a lot of it.
>>
>> 2) We can now do other instruction widths with relative ease. The
>> compiler now detects, based on register widths, the execution size of
>> the instruction and passes it down to the generator. One example of
>> this is the patches in this series for UNTYPED_ATOMIC and
>> UNTYPED_SURFACE_READ where part of setting up the payload is to do an
>> 8-wide move to fill a register with 0 and then a 1-wide move to set one
>> particular component. We can now simply do this at the fs level and it
>> will be get translated down to the correct assembly and properly
>> handled by the compiler optimizations. There is more work to be done
>> here at the generator level, but this series is already long enough
>>
>> 3) Thanks to the above mentioned things, we can easily do send from GRF
>> for FB writes. One of the major blockers here before was that the
>> beginning of the FB write message was anywhere between 0 and 4
>> registers regardless of whether you are in SIMD8 or SIMD16. Due to the
>> implicit register doubling in SIMD16, it would have been a real pain to
>> implement this properly. Now, it's trivial.
>>
>> I could go on about other changes, but those are the major ones.
>
> This all sounds great, Jason. I'm really happy with how you split the
> patches out. It made reviewing this amazingly easy.
>
> I'm made a relatively quick review, and it looks good to me. (I'm
> operating under the assumption that what you said below about piglit
> passing is indicative of there not being bugs :) I've sent a bunch of
> smallish comments. Nothing major. I guess patch 41 is in flux though
> based on Connor's review.
Don't worry about that - it's just one minor thing that should be
pretty easy to change, and then some rambling by me :)
>
> I suppose the next steps are to sort out the preliminary 12 patch
> series (which I think you said you were going to revise?). I think the
> ball's in your court there.
>
> So, you can apply my R-b to the first 40 patches with comments
> addressed. When this series goes in, I think we should preserve the
> commit info of the squash patches (i.e., actually squash instead of
> fixup), like in commit 79d77b38.
>
>> The requisite Shader DB results:
>>
>> total instructions in shared programs: 4999994 -> 4971746 (-0.56%)
>> instructions in affected programs: 959392 -> 931144 (-2.94%)
>> GAINED: 138
>> LOST: 71
>
> Any ideas about the lost programs?
> _______________________________________________
> 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