Etnaviv issues on i.MX8M-Mini

Mon Feb 24 10:53:20 UTC 2020

Hi Lucas,

On 24.02.20 11:37, Lucas Stach wrote:
> Hi Frieder,
> 
> On Mo, 2020-02-24 at 10:28 +0000, Schrempf Frieder wrote:
>> On 20.02.20 19:58, Chris Healy wrote:
>>> For the jerkey transitions, can you determine if this is a symptom of
>>> a low framerate or dropped frames or something else?
>>>
>>> Perhaps you can start your app with
>>> "GALLIUM_HUD=fps,cpu,draw-calls,frametime".  This may give some clues.
>>
>> The framerate seems ok. I get something between 50 and 70 FPS.
>>
>> I have a Qt demo app with a menu and an animated 'ball' that moves
>> across the screen. When the menu is visible, the ball movement is really
>> jerky (ball seems to 'jump back and forth' instead of moving linearly).
>>
>> As soon as I hide the menu and show the animation fullscreen, the
>> movements are perfectly smooth.
>>
>> Running the same app with software rendering, everything looks good, too.
>>
>> No idea what that means, though. I probably need to look at the code of
>> the app and do some more experiments to get a better idea of what might
>> cause the distortion.
>>
>> Unless some of the graphics experts here already have an idea of what
>> can cause and/or how to debug such an issue!?
> 
> Which driver is used for the display side? It seems like the display
> side doesn't properly handle the dma fences used to synchronize scanout
> and rendering.

I ported/picked the drivers for the LCDIF and DSI controllers from 
development branch of the 5.4-based vendor kernel [1] to our own 
v5.4-based kernel [2]. So it is quite probable, that something could be 
wrong here.

> 
>> Is it even correct, that the GPUs are detected as GC520 and GC600? Is it
>> known if they need some changes in the HWDB?
> 
> We probably need some addition to the HWDB. It is highly likely that
> the GPU is some variant of the GC600 (all this NanoUltra stuff is just
> marketing fluff), but it seems the feature registers on those newer
> cores aren't fully correct anymore, as the vendor driver handles most
> of this via the HWDB these days.

Ok, good to know. I don't know how this usually works, but if I can be 
of any help with the actual hardware at hand, let me know.

Thanks,
Frieder

[1] 
https://source.codeaurora.org/external/imx/linux-imx/log/?h=imx_5.4.0_8dxlphantom_er
[2] https://git.kontron-electronics.de/linux/linux/commits/v5.4-ktn

> 
> Regards,
> Lucas
> 
>> Thanks for your support!
>>
>>> On Thu, Feb 20, 2020 at 10:25 AM Schrempf Frieder
>>> <frieder.schrempf at kontron.de> wrote:
>>>> Hi Chris,
>>>>
>>>> On 20.02.20 18:19, Chris Healy wrote:
>>>>> Hi Frieder,
>>>>>
>>>>> For your #1, can you provide more detail on your configuration?  What
>>>>> is your display resolution?  Are you running Qt with egl_fs or are you
>>>>> running on top of a compositor?  If you are running on top of a
>>>>> compositor, is the 3D GPU being used for compositing?
>>>>
>>>> Sure. The display resolution I'm testing with is 1024x600 and I'm using
>>>> the eglfs/KMS backend without compositor.
>>>>
>>>> I'm passing this simple config to Qt via QT_QPA_EGLFS_KMS_CONFIG:
>>>>
>>>> {
>>>>        "device": "/dev/dri/card1"
>>>> }
>>>>
>>>>> For your #2, at least in the case of the GC2000, the GPU cannot deal
>>>>> with shaders that have more than 512 instructions.  The terrain demo
>>>>> has a shader that is typically larger than 512 instructions.  I've
>>>>> always seen the terrain demo fail on the GC2000.  With the GC3000 and
>>>>> GC7000L, this 512 instruction limit does not exist and the terrain
>>>>> demo has always worked.  Likely the GC600 has this 512 instruction
>>>>> limit.
>>>>
>>>> Ok, that's likely the reason for this. Thanks for explaining.
>>>>
>>>> Best regards,
>>>> Frieder
>>>>
>>>>> Regards,
>>>>>
>>>>> Chris
>>>>>
>>>>> On Thu, Feb 20, 2020 at 8:56 AM Schrempf Frieder
>>>>> <frieder.schrempf at kontron.de> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> according to the documents, the i.MX8M-Mini features a GC320 and a
>>>>>> GCNanoUltra. I tried to run the etnaviv drivers and the following GPUs
>>>>>> are detected:
>>>>>>
>>>>>>            etnaviv-gpu 38000000.gpu: model: GC600, revision: 4653
>>>>>>            etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
>>>>>>
>>>>>> Running some demos and tests with mesa 19.1.6 most things seem to work.
>>>>>> Still I currently have two issues, while the first one is kind of a
>>>>>> show-stopper and the second one is not really important as it seems to
>>>>>> affect shaders only.
>>>>>>
>>>>>> 1. When running any QtQuick applications, all transformations like
>>>>>> moving elements are really jerky and not smooth at all as it should be.
>>>>>> Any ideas what the reason could be, or how to get more information about
>>>>>> this problem?
>>>>>>
>>>>>> 2. With some demos (e.g. with 'glmark2-es2-drm -b terrain') I get:
>>>>>>
>>>>>>            error: compile failed!
>>>>>>            etna_draw_vbo:222: compiled shaders are not okay
>>>>>>
>>>>>> Can this be fixed somehow, or is this due to the limitations of the GPU?
>>>>>>
>>>>>> Thanks,
>>>>>> Frieder
>>>>>> _______________________________________________
>>>>>> etnaviv mailing list
>>>>>> etnaviv at lists.freedesktop.org
>>>>>> https://lists.freedesktop.org/mailman/listinfo/etnaviv
>> _______________________________________________
>> etnaviv mailing list
>> etnaviv at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/etnaviv
> 