Page 1 of 3 123 LastLast
Results 1 to 10 of 21

Thread: AMD Finally Publishes New Gallium3D Driver (RadeonSI)

  1. #1
    Join Date
    Jan 2007
    Posts
    13,411

    Default 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...

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

  2. #2
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    872

    Default

    Nice to hear there will be no more DDX.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

  3. #3
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    965

    Default

    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
    Kwin OpenGL compositing just garbles the screen, xrender compositing works.

  4. #4
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    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.

  5. #5
    Join Date
    Sep 2006
    Posts
    714

    Default

    Quote Originally Posted by bridgman View Post
    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.

  6. #6
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    Quote Originally Posted by drag View Post
    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.

  7. #7
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    965

    Default

    Quote Originally Posted by bridgman View Post
    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?

  8. #8
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,281

    Default

    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

  9. #9
    Join Date
    Sep 2010
    Posts
    419

    Default

    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.

  10. #10
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    89

    Default

    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •