[Mesa-dev] [PATCH 3/6] i965: always run the post-RA scheduler
Ilia Mirkin
imirkin at alum.mit.edu
Sat Oct 3 11:42:35 PDT 2015
On Sat, Oct 3, 2015 at 2:38 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Sat, Oct 3, 2015 at 11:32 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Sat, Oct 3, 2015 at 2:28 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>> On Sat, Oct 3, 2015 at 11:26 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> On Sat, Oct 3, 2015 at 2:13 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>>>> On Fri, Oct 2, 2015 at 2:37 PM, Connor Abbott <cwabbott0 at gmail.com> wrote:
>>>>>> Before, we would only do scheduling after register allocation if we
>>>>>> spilled, despite the fact that the pre-RA scheduler was only supposed to
>>>>>> be for register pressure and set the latencies of every instruction to
>>>>>> 1. This meant that unless we spilled, which we rarely do, then we never
>>>>>> considered instruction latencies at all, and we usually never bothered
>>>>>> to try and hide texture fetch latency. Although a later commit removes
>>>>>> the setting the latency to 1 part, we still want to always run the
>>>>>> post-RA scheduler since it's able to take the false dependencies that
>>>>>> the register allocator creates into account, and it can be more
>>>>>> aggressive than the pre-RA scheduler since it doesn't have to worry
>>>>>> about register pressure at all.
>>>>>>
>>>>>> XXX perf data
>>>>>
>>>>> Test master post-ra-sched diff %diff
>>>>> bench_OglPSBump2 396.730 402.386 5.656 +1.400%
>>>>> bench_OglPSBump8 244.370 247.591 3.221 +1.300%
>>>>> bench_OglPSPhong 241.117 242.002 0.885 +0.300%
>>>>> bench_OglPSPom 59.555 59.725 0.170 +0.200%
>>>>> bench_OglShMapPcf 86.149 102.346 16.197 +18.800%
>>>>> bench_OglVSTangent 388.849 395.489 6.640 +1.700%
>>>>> bench_trex 65.471 65.862 0.390 +0.500%
>>>>> bench_trexoff 69.562 70.150 0.588 +0.800%
>>>>>
>>>>> Unfortunately, neither of the unigin benchmarks (heaven or vally)
>>>>> seemed to render correctly. I just got white on both master and your
>>>>> branch. Not sure if we have a bug or if they just weren't running
>>>>> right. In any case, ministat didn't notice any difference in them.
>>>>
>>>> I believe they're called "features" :) Try with disable_blend_func_extended=true
>>>
>>> I pulled in a more recent drirc and am re-running those two.
>>
>> They're not in the latest drirc... probably should be added back in.
>
> I used the drirc corresponding to the mesa commits I was testing.
> Given that it's actually rendering stuff, I'm going to say it's
> probably ok.
Ah neat. I guess something to fixed then.
More information about the mesa-dev
mailing list