Comme=
nt # 12
on bug 10862=
5
from Alex Deucher
(In reply to Carsten Haitzler from comment #10)
> so wouldn't that make it a necessity then if its=
even glamor needing it? i
> guess i can turn off glamor accel but realistically gl is a necessity =
so the
> problem needs to be addressed sooner or later.
>
If you were starting a bare x server, you usually don't hit the glamor paths
too extensively compared to a full desktop environment.
> the ring gfx timeout smells to me of "not a=
mesa bug" in that an ioctl going
> to the drm driver never returns qhen doing a simple query. it hangs, t=
hus
> something lower down that is having a bad day, if something as simple =
as
> querying a fence causes a hang... :)
>=20
> what is this ring gfx thing exactly (seems to be some command queue) a=
nd why
> would it be timing out? all the way back at seq 10/11 ... like right a=
t the
> start of its use? it's almost like some interrupt or in memory semapho=
re
> thing mapped from the card is messing up? i'm looking for something to=
look
> into more specifically.
Each engine on the GPU (gfx, compute, video decode, encode, dma, etc.) has a
ring buffer used to feed it. The work sent to the engines is managed by a =
sw
scheduler in the kernel. The kernel driver tests the rings as part of the
driver init sequence. The driver won't come up if the ring tests fail so t=
hey
are working at least until you start X. Presumably X submits (via glamor) =
some
work to the GPU which causes the GPU to hang. The fence never signals beca=
use
the GPU never finished processing the job due to the hang.
Another simplier test would be to boot up to a console (no X) and then try
running some of the libdrm amdgpu tests. They are really simple (copying d=
ata
and round and verifying it using different engines, allocating freeing memo=
ry,
etc.).
https:/=
/cgit.freedesktop.org/mesa/drm/tree/tests/amdgpu
See if some of the simple copy or write tests work.