Announcement
Collapse
No announcement yet.
AMD Finally Publishes New Gallium3D Driver (RadeonSI)
Collapse
X
-
Just to be clear I get it right: This time you try to use the 3d "engine" (mesa) to accelerate 2d (usually ddx)? Like the intel guys with glamor?
-
Sounds very interesting to not have to have extra DDX stuff for the driver.
Since some of it needs to be in some places in the kernel.
A driver should be able to be a self contained software package.
Looking forward to the result! It's going to be very interesting.
Hopefully the open source R300 and R600 drivers can follow in it's footsteps in the future.
Leave a comment:
-
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
Leave a comment:
-
Originally posted by bridgman View PostI 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.
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?
Leave a comment:
-
Originally posted by drag View PostWhen you are using "Gallium3D accel code" you do it by implementing a 'state tracker' for your API.
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.
Leave a comment:
-
Originally posted by bridgman View PostI 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.
Leave a comment:
-
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.
Leave a comment:
-
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:Code:[ 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
Leave a comment:
-
AMD Finally Publishes New Gallium3D Driver (RadeonSI)
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...
Tags: None
Leave a comment: