On 26/04/2019 20:40, Marek Olšák wrote:
On Fri, Apr 26, 2019 at 12:56 PM Axel Davy <davyax...@gmail.com
<mailto:davyax...@gmail.com>> wrote:
On 26/04/2019 10:08, Michel Dänzer wrote:
> On 2019-04-26 4:06 a.m., Marek Olšák wrote:
>> From: Marek Olšák <marek.ol...@amd.com
<mailto:marek.ol...@amd.com>>
>>
>> It's done by:
>> - decrease the number of frames in flight by 1
>> - flush before throttling in SwapBuffers
>> (instead of wait-then-flush, do flush-then-wait)
>>
>> The improvement is apparent with Unigine Heaven.
>>
>> Previously:
>> draw frame 2
>> wait frame 0
>> flush frame 2
>> present frame 2
>>
>> The input lag is 2 frames.
>>
>> Now:
>> draw frame 2
>> flush frame 2
>> wait frame 1
>> present frame 2
>>
>> The input lag is 1 frame. Flushing is done before waiting,
because
>> otherwise the device would be idle after waiting.
> Nice idea. Not sure offhand about all ramifications, but
certainly worth
> a go.
>
>
>> Nine is affected because it also uses the pipe cap.
>> ---
>> src/gallium/auxiliary/util/u_screen.c | 2 +-
>> src/gallium/state_trackers/dri/dri_drawable.c | 20
+++++++++----------
>> 2 files changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_screen.c
b/src/gallium/auxiliary/util/u_screen.c
>> index 27f51e0898e..410f17421e6 100644
>> --- a/src/gallium/auxiliary/util/u_screen.c
>> +++ b/src/gallium/auxiliary/util/u_screen.c
>> @@ -349,21 +349,21 @@ u_pipe_screen_get_param_defaults(struct
pipe_screen *pscreen,
>> case PIPE_CAP_MAX_VARYINGS:
>> return 8;
>>
>> case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:
>> return 0;
>>
>> case PIPE_CAP_COMPUTE_SHADER_DERIVATIVES:
>> return 0;
>>
>> case PIPE_CAP_MAX_FRAMES_IN_FLIGHT:
>> - return 2;
>> + return 1;
> This might be slightly misleading, as there can still be two
frames in
> flight (on the GPU) at the same time. Might be better to leave
this at 2
> (so Nine isn't affected) and adjust its treatment in
> src/gallium/state_trackers/dri/dri_drawable.c .
>
>
Checking what gallium nine does currently, it seems we already do
flush
then wait,
however we call swap_fences_pop_front and swap_fences_push_back in
the
reverse order compared to your patch.
We compensate by taking PIPE_CAP_MAX_FRAMES_IN_FLIGHT + 1
In conclusion, with the proposed patch, gl and nine should have
the same
behaviour (and thus if gl benefits from a value of 1, nine should
as well).
I haven't have noticed input lag, I guess I have to test on heaven if
you see a difference.
How can I slow down my gpu to test that ? I use to use the
/sys/kernel/debug/dri/0/ vars to force low dpm, but it doesn't
seem to
be possible anymore as the related files are gone (rx480) ?
I set maximum settings, windowed, resolution: custom, and I type in
the 4K resolution (I don't have a 4K monitor). When it's running, I
enable wireframe. It should be pretty slow.
Marek
I couldn't notice any performance difference (card at low or high dpm -
somehow the vars were still there, I was looking at the wrong place),
with and without the change and gallium nine. I couldn't notice a change
in lag either (slowest I had was around 20 fps, which may not be the
best to see that).
I'm fine with this change affecting nine.
Axel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
