[Mesa-dev] Performance regression on Tegra/GK20A since commit 363b53f00069

Alexandre Courbot acourbot at nvidia.com
Tue Nov 25 00:04:36 PST 2014

Hi Pekka,

On 11/20/2014 08:41 PM, Pekka Paalanen wrote:
> On Thu, 20 Nov 2014 18:24:34 +0900
> Alexandre Courbot <acourbot at nvidia.com> wrote:
>> Hi Pekka,
>> On 11/19/2014 04:34 PM, Pekka Paalanen wrote:
>>> On Wed, 19 Nov 2014 15:32:38 +0900
>>> Alexandre Courbot <acourbot at nvidia.com> wrote:
>>>> Some more information: CPU usage of the EGL app (glmark2 here) is much
>>>> higher when this patch is applied, which I presume is what triggers the
>>>> frame skips.
>>>> On 11/19/2014 03:05 PM, Alexandre Courbot wrote:
>>>>> Hi guys,
>>>>> I am seeing a severe performance regression (lots frame drops when
>>>>> running EGL apps in Weston) on Tegra/GK20A since the following commit:
>>>>> commit 363b53f00069af718f64cf047f19ad5681a8bf6d
>>>>> Author: Marek Olšák <marek.olsak at amd.com>
>>>>> Date:   Sat Nov 1 14:31:09 2014 +0100
>>>>>        egl: remove egl_gallium from the loader
>>>>> Reverting said commit on top of master brings the expected performance
>>>>> back. I am not knowledgeable enough about Mesa to speculate about the
>>>>> reason, but could we try to investigate why this happens and how we
>>>>> could fix this?
>>> Hi,
>>> that sounds like you used to get egl_gallium as the EGL driver, and
>>> after that patch you get egl_dri2. These two have separate Wayland
>>> platform implementations (and probably all other platforms as well?). I
>>> think that might be a lead for investigation. EGL debug environment
>>> variable (EGL_LOG_LEVEL=debug) should confirm which EGL driver gets
>>> loaded. You can force the EGL driver with e.g. EGL_DRIVER=egl_dri2.
>> You are spot on, EGL_LOG_LEVEL revealed that I was using the egl_gallium
>> driver while this patch makes Wayland applications use egl_dri2. If I
>> set EGL_DRIVER=egl_gallium things go back to the expected behavior.
>>> Note, that there are two different EGL platforms in play: DRM/GBM for
>>> Weston, and Wayland for the app. Have you confirmed the problem is in
>>> the app side? That is, does Weston itself run smoothly?
>> Weston seems to be fine, and since setting EGL_DRIVER=egl_gallium after
>> starting it brings things back to the previous behavior I believe we can
>> consider it is not part of this problem.
> Agreed.
>>> You say "frame drops", how do you see that? Only on screen, or also in
>>> the app performance profile? How's the average framerate for the app?
>> Looking at it again this is actually quite interesting. The misbehaving
>> app is glmark2, and what happens is that despite working nicely
>> otherwise, a given frame sometimes remain displayed for up to half a
>> second. Now looking at the framerates reported by glmark2, I noticed
>> that while they are capped at 60fps when using the gallium driver, the
>> numbers are much higher when using dri2 (which is nice!). Excepted when
>> these "stuck frames" happen, then the reported framerate drops
>> dramatically, indicating that the app itself is also blocked by this.
> I have a hunch (wl_buffer.release not delivered in time, and client
> side EGL running out of available buffers), but confirming that would
> require a Wayland protocol dump up to such hickup. You could try to get
> one by setting the enviroment variable WAYLAND_DEBUG=client for
> glmark2. It will be a flood, especially if glmark2 succeeds in running
> at uncapped framerates. The trace will come to stderr, so you want to
> redirect that to file. You need to find out where in the trace the
> hickup happened. The timestamps are in milliseconds. I could then take
> a look (will need the whole trace).
> At this point, I think it would be best to open a bug report against
> Mesa, and continue there. Such freezes obviously should not happen on
> either EGL driver. Please add me to CC on the bug.

Thanks, I have opened a bug against Mesa and added you to the CC list:


I will try to attach the WAYLAND_DEBUG trace you suggested to it.


More information about the mesa-dev mailing list