AMD Finally Publishes New Gallium3D Driver (RadeonSI)

[phoronix]

Phoronix: AMD Finally Publishes New Gallium3D Driver (RadeonSI)

AMD has finally made public its new Gallium3D driver, which is called "RadeonSI" and provides the user-space acceleration support for their latest-generation AMD Radeon HD 7000 "Southern Islands" graphics cards under Linux...

http://www.phoronix.com/vr.php?view=MTA4MzM

[darkbasic]

Nice to hear there will be no more DDX.

[ChrisXY]

It's nice they want to use the radeon state tracker, but it really needs work. Really.

HD 6550 mobile here.
The mouse pointer still has a garbled square around it. xrandr is still not properly supported (multiple screens work, but rotating does not work).
Switching from X to a tty and back is slow. Recently with xf86-video-ati-git and linux 3.4 it really got as fast as it should be.

At the moment OpenGL is completely broken it seems. Even glxgears:

[  308.506845] radeon 0000:02:00.0: evergreen_surface_check_1d:240 depth height 300 invalid must be aligned with 8
[  308.506856] radeon 0000:02:00.0: evergreen_cs_track_validate_depth:653 depth invalid (0x00000027 0x000005db 0x00002022)
[  308.506863] radeon 0000:02:00.0: evergreen_packet3_check:2055 invalid cmd stream 468

Kwin OpenGL compositing just garbles the screen, xrender compositing works.

[bridgman]

I don't think Alex said "radeon state tracker" or implied any specific implementation, just that we were going to try to use Gallium3D accel code if possible. Normally we end up with different accel code in ddx because the ddx gets implemented first -- this time we're implementing the Gallium3D support first so we at least have the option of re-using it in ddx without having to throw away existing work.

[drag]

I don't think Alex said "radeon state tracker" or implied any specific implementation, just that we were going to try to use Gallium3D accel code if possible.

When you are using "Gallium3D accel code" you do it by implementing a 'state tracker' for your API.

Normally we end up with different accel code in ddx because the ddx gets implemented first -- this time we're implementing the Gallium3D support first so we at least have the option of re-using it in ddx without having to throw away existing work.

Ultimately they would want to get rid of hardware specific DDX for once and for all. Either through a Wayland DDX or a Gallium DDX or something like that.

[bridgman]

When you are using "Gallium3D accel code" you do it by implementing a 'state tracker' for your API.

I understand that we call anything using Gallium3D a state tracker, just saying that it isn't necessarily an *existing* state tracker.

I'm not trying to be cagey here, just saying that (a) AFAIK it hasn't been decided yet, (b) the discussion & decision is something that should happen out in the community after the initial Gallium3D push.

[ChrisXY]

I don't think Alex said "radeon state tracker" or implied any specific implementation, just that we were going to try to use Gallium3D accel code if possible.

Oh well, ok then. I just thought, that because there is already one you might as well develop on top of it.

But "There is no ddx for SI right now. The plan is to support X acceleration via gallium." means something like the r600g state tracker, right?

[bridgman]

Yeah, I think xorg and xa are the current ddx-related state tracker projects. AFAIK r600g is a pipe driver rather than a state tracker.

The only definitive statement at this point is that we are going to try re-use the Gallium3D driver code for ddx acceleration rather than implementing something different. That's not because we have a secret plan and we don't want to tell you, it's because we're trying to get the Gallium3D code out first

[uid313]

Nice to hear there will be no more DDX.

The BSD and Solaris guys disagrees.

[bridgman]

Linux guys too

For clarity, nobody is saying that there won't be a DDX. All we're talking about here is re-using the Gallium3D hardware layer code in the DDX for EXA acceleration etc... rather than writing different accel code from scratch.

This should have little to no impact on BSD, Solaris or other OS ports.