Running The Xorg State Tracker On R300 Gallium3D

[agd5f]

If this is the future, it is one more focused break point. Currently if there's a mesa bug, you still have 2d, can surf the web, play movies etc. If the 2d driver depended on mesa, your only backup would be the vesa driver == no movies or other 2d-accel use.

Generally 3D driver bugs are specific to a shader or extension in a specific app. The xorg state tracker works more like a conventional ddx; X/render/Xv ops are mapped to static state and shaders and loaded on the 3D engine, just like the ddx does. So it's not really the case that if a some 3D app is broken, you won't get 2D.

As for gallium and state trackers in general, you can't really expect minimally used or tested state trackers to just work without a little effort. The same goes for any complex software stack. Besides bugs on the driver side, there is a also a good chance there are bugs in the state trackers themselves since they have only limited testing in many cases. The gallium architecture however, makes it MUCH easier to add support for new APIs. Sure there will be bugs when the code is new, but it's a lot easier than writing a separate hw driver for each API and then having to maintain and port fixes across all of them.

[pingufunkybeat]

But it's a great article!

We tested the [phoronix link] state tracker we talked about [phoronix link] earlier which brings [phoronix link] xvideo to [phoronix link] amd hardware and which might [phoronix link] run the upcoming [phoronix link] steam games on [phoronix link] wayland soon [phoronix link] although [phoronix link] it is lagging behind on [phoronix link] OpenGL 4.2 compliance compared to [phoronix link] blobs and might suffer from the [phoronix link] linux kernel power regressions. It replaces the [phoronix link] traditional DDX running over [phoronix link] KMS and [phoronix link] DRI2.


...


It doesn't run.

[Link to discussion]

[ad] [banner] [ad]
[phoronix link]
[phoronix link]
[phoronix link]

[DanL]

But it's a great article!...<ungrateful sarcasm>

I found it interesting for a quick read about an experimental feature along with the ensuing discussion from people who actually had insightful things to say. Since you keep coming back to phoronix and like it, be grateful that the ad revenue generated helps sustain the site and improves the open-source world.

[curaga]

Generally 3D driver bugs are specific to a shader or extension in a specific app. The xorg state tracker works more like a conventional ddx; X/render/Xv ops are mapped to static state and shaders and loaded on the 3D engine, just like the ddx does. So it's not really the case that if a some 3D app is broken, you won't get 2D.

As for gallium and state trackers in general, you can't really expect minimally used or tested state trackers to just work without a little effort. The same goes for any complex software stack. Besides bugs on the driver side, there is a also a good chance there are bugs in the state trackers themselves since they have only limited testing in many cases. The gallium architecture however, makes it MUCH easier to add support for new APIs. Sure there will be bugs when the code is new, but it's a lot easier than writing a separate hw driver for each API and then having to maintain and port fixes across all of them.

Consider something little used like mga or r200 (yes, not well applicable to the xorg st. Just for the sake of examples of such hw today). If something in mesa breaks for those (assume breakage that affects both 3d and the xorg st, say, corruption), it's the users who are going to notice, maybe file a bug, and that bug will very likely rot away.

I'm not saying such a bug for the ddx would not rot away likewise; but the likelihood of such bug appearing in a bigger codebase is, well, bigger. All together, one point of failure instead of two like today.

[bridgman]

Not sure I follow the "bug will just rot away" logic. If you're saying that a bug filed against the xorg st ddx rather than the regular ddx won't get noticed, I guess that's a possibility but I think the intent is for the xorg st ddx to become the primary solution if things go well. Since the xorg st needs both gallium3d and kms that pretty much limits it to actively supported hardware with very few exceptions.

I agree that those exceptions could cause confusion but since ddxes will still presumably be chosen based on hw I would not expect the xorg st to be chosen unless (a) the user was experimenting and chose it themselves or (b) the xorg st was the recommended ddx for a specific piece of hardware (or at least close enough that a distro packager thought it made sense) and made a deliberate decision to use the xorg st on specific hw.

[curaga]

No, I meant that having the bug rot on both would be equally possible. Perhaps I should've just skipped trying to come up with an example and left it at "two POF instead of one"

[curaga]

*One instead of two.

Damnit broken edit is getting on my nerves.

[giselher]

Ha, I got the xorg state tracker working on my machine (r600g_drv.so). I also have libvdpau, libva (needs some patching to work with the libva in the arch repos) and libxvmc enabled, but I don't notice any differences. The problems I have is that the mouse pointer image is broken and that firefox doesn't update the display on changing tabs (scrolling on the page helps ).

Here is my PKGBUILD if anyone is interested, but you have to apply the patches for the xorg-r600 suppport first (without libva and r600 only).
https://gist.github.com/1169208.

[Paulie889]

possible workarround

I'm quite sure Xorg state tracker never worked reliably on r300g. There was some workaround like booting first with xf86-video-ati and then restarting X with Xorg state tracker, or something like that. IIRC the problem was that the card (or just some registers) are initialized incorrectly with st/xorg or not at all. I don't know if this is still the case, but if this is another problem it probably can be bisected.

There were even some bugs filled once about st/xorg for r300g, there is more info about that matter:

https://bugs.freedesktop.org/show_bug.cgi?id=30402

https://bugs.freedesktop.org/show_bug.cgi?id=30406

[agd5f]

I'm not saying such a bug for the ddx would not rot away likewise; but the likelihood of such bug appearing in a bigger codebase is, well, bigger. All together, one point of failure instead of two like today.

Well, it really depends what components get the most use. Right now no one uses the xorg st and it's still lacking some features that could be implemented. It's more of a playground for interested parties. If it some point it became the primary ddx for certain hardware, it would get a lot more attention. It also has the advantage of only needing to write and maintain one set of hw acceleration code rather than two.