bikehead wrote:
I have been testing the xorg-X11-drv-ati driver with my T42p with much
success (I don't see the random lockups others have been reporting). I
have used desktop-effects with good success too. However when I try it
with 3d games like bzflag or foobilard it doesn't work.
What is the state of the radeon drivers with respect to 3d? Is it a bug
if I get messages like the following:
[bikehead@porco ~]$ bzflag
libGL warning: 3D driver claims to not support visual 0x4b
*********************************WARN_ONCE*********************************
File r300_render.c function r300Fallback line 422
Software fallback:ctx->Polygon.StippleFlag
***************************************************************************
Try R300_SPAN_DISABLE_LOCKING env var if this hangs.
or is the normal state of affairs?
The unsupported visual warning is completely harmless.
The span locking message is normal, but not actually harmless at all. I
need to patch that out in the future.
It works like this. All access to the framebuffer _must_ be done under
the DRI lock. In the normal path, that's only when you submit commands;
but when you hit a software fallback, that's every time you touch a
pixel. There's an "optimization" for this path that only takes the lock
once per horizontal pixel span, instead of once per pixel (!), but
apparently that's still too slow for the r300 developers.
As a result, if you hit a software fallback while your X server is not
in the foreground, the driver will happily poke directly into
framebuffer memory. Worse, the server no longer actually has exclusive
access to the hardware, so if you poke pixels and trigger DMA at the
same time, boom. Cool, huh?
That said, it should work. If it doesn't, bugs are welcome.
- ajax
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
