hi,
I haven't done enough testing to have a full understanding of the issue,
but it seems there could be a regression with gallium nine.
One user is reporting on irc huge slowdowns with d3d8 games (using the
d3d8to9 wrapper) when using vsync. Reverting fixes the issues.
I don't know exactly why vsync would have issues.
Another thing though is that many d3d9 games do their own throttling,
and if our throttling is stricter, maybe the game multithreading could
be perturbed.
All in all, this needs more testing with gallium nine.
To prevent possible regression for next release, I'll force
PIPE_CAP_MAX_FRAMES_IN_FLIGHT to be clamped to 2 at least for gallium nine.
Might be worth trying to see if gl could be affected.
Yours,
Axel
On 02/05/2019 03:19, Marek Olšák wrote:
If there is no other feedback, I'll push this tomorrow.
Marek
On Mon, Apr 29, 2019 at 6:12 PM Marek Olšák <mar...@gmail.com
<mailto:mar...@gmail.com>> wrote:
This patch might improve performance, because less submitted
unfinished work means less used memory by the unfinished work.
Marek
On Mon, Apr 29, 2019 at 11:07 AM Michel Dänzer <mic...@daenzer.net
<mailto:mic...@daenzer.net>> wrote:
On 2019-04-27 6:13 p.m., Rob Clark wrote:
> On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák
<mar...@gmail.com <mailto:mar...@gmail.com>> 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.
>>
>> 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;
>
> would it be safer to leave the current default and let
drivers opt-in
> to the lower # individually? I guess triple buffering would
still be
> better for some of the smaller gpu's?
This patch doesn't prevent triple buffering. The application
can still
prepare up to one frame worth of GPU commands before the GPU has
finished processing the commands of the previous frame (while the
pre-previous frame is being displayed).
I just think the term "in flight" should maybe be defined a
bit better,
but it's not a blocker and could be done in a follow-up patch.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X
developer
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
