<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">hi,<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">One user is reporting on irc huge
slowdowns with d3d8 games (using the d3d8to9 wrapper) when using
vsync. Reverting fixes the issues.<br>
</div>
<p>I don't know exactly why vsync would have issues.</p>
<p>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.<br>
All in all, this needs more testing with gallium nine.<br>
</p>
<p>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.</p>
<p><br>
</p>
<p>Might be worth trying to see if gl could be affected.<br>
</p>
<div class="moz-cite-prefix">Yours,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Axel<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 02/05/2019 03:19, Marek Olšák wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAxE2A5uw1c7+MkA8fOUEf39Jf3Z=ftL3dzXO4EvCfk8mqS4BA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>If there is no other feedback, I'll push this tomorrow.</div>
<div><br>
</div>
<div>Marek<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 6:12
PM Marek Olšák <<a href="mailto:maraeo@gmail.com"
moz-do-not-send="true">maraeo@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>This patch might improve performance, because less
submitted unfinished work means less used memory by the
unfinished work.<br>
</div>
<div><br>
</div>
<div>Marek<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at
11:07 AM Michel Dänzer <<a
href="mailto:michel@daenzer.net" target="_blank"
moz-do-not-send="true">michel@daenzer.net</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On 2019-04-27 6:13
p.m., Rob Clark wrote:<br>
> On Thu, Apr 25, 2019 at 7:06 PM Marek Olšák <<a
href="mailto:maraeo@gmail.com" target="_blank"
moz-do-not-send="true">maraeo@gmail.com</a>> wrote:<br>
>><br>
>> From: Marek Olšák <<a
href="mailto:marek.olsak@amd.com" target="_blank"
moz-do-not-send="true">marek.olsak@amd.com</a>><br>
>><br>
>> It's done by:<br>
>> - decrease the number of frames in flight by 1<br>
>> - flush before throttling in SwapBuffers<br>
>> (instead of wait-then-flush, do
flush-then-wait)<br>
>><br>
>> The improvement is apparent with Unigine Heaven.<br>
>><br>
>> Previously:<br>
>> draw frame 2<br>
>> wait frame 0<br>
>> flush frame 2<br>
>> present frame 2<br>
>><br>
>> The input lag is 2 frames.<br>
>><br>
>> Now:<br>
>> draw frame 2<br>
>> flush frame 2<br>
>> wait frame 1<br>
>> present frame 2<br>
>><br>
>> The input lag is 1 frame. Flushing is done
before waiting, because<br>
>> otherwise the device would be idle after
waiting.<br>
>><br>
>> Nine is affected because it also uses the pipe
cap.<br>
>> ---<br>
>> src/gallium/auxiliary/util/u_screen.c |
2 +-<br>
>> src/gallium/state_trackers/dri/dri_drawable.c |
20 +++++++++----------<br>
>> 2 files changed, 11 insertions(+), 11
deletions(-)<br>
>><br>
>> diff --git
a/src/gallium/auxiliary/util/u_screen.c
b/src/gallium/auxiliary/util/u_screen.c<br>
>> index 27f51e0898e..410f17421e6 100644<br>
>> --- a/src/gallium/auxiliary/util/u_screen.c<br>
>> +++ b/src/gallium/auxiliary/util/u_screen.c<br>
>> @@ -349,21 +349,21 @@
u_pipe_screen_get_param_defaults(struct pipe_screen
*pscreen,<br>
>> case PIPE_CAP_MAX_VARYINGS:<br>
>> return 8;<br>
>><br>
>> case PIPE_CAP_COMPUTE_GRID_INFO_LAST_BLOCK:<br>
>> return 0;<br>
>><br>
>> case PIPE_CAP_COMPUTE_SHADER_DERIVATIVES:<br>
>> return 0;<br>
>><br>
>> case PIPE_CAP_MAX_FRAMES_IN_FLIGHT:<br>
>> - return 2;<br>
>> + return 1;<br>
> <br>
> would it be safer to leave the current default and
let drivers opt-in<br>
> to the lower # individually? I guess triple
buffering would still be<br>
> better for some of the smaller gpu's?<br>
<br>
This patch doesn't prevent triple buffering. The
application can still<br>
prepare up to one frame worth of GPU commands before the
GPU has<br>
finished processing the commands of the previous frame
(while the<br>
pre-previous frame is being displayed).<br>
<br>
I just think the term "in flight" should maybe be defined
a bit better,<br>
but it's not a blocker and could be done in a follow-up
patch.<br>
<br>
<br>
-- <br>
Earthling Michel Dänzer | <a
href="https://www.amd.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://www.amd.com</a><br>
Libre software enthusiast | Mesa
and X developer<br>
</blockquote>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
mesa-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a></pre>
</blockquote>
<p><br>
</p>
</body>
</html>