Page 2 of 11 FirstFirst 1234 ... LastLast
Results 11 to 20 of 101

Thread: Open-Source ATI R600/700 3D Driver Almost Working

  1. #11
    Join Date
    Jul 2008
    Posts
    776

    Default

    I thought the 3d part would be more ready.

    I planed to buy a hd4870 1gb next week, but as i see i will not have 3d with the open driver till the dx11 ati cards come out (October), fglrx is no option for me. So i have no compiz for several months, I really consider my planed buying now.

    Right now i have an x800xl, maybe i look for an used X1950xtx or something like that, is the 3d part for r500 fast enough to play lets say quake wars on 1920x1200 with high settings? (without AA)

  2. #12
    Join Date
    Dec 2008
    Posts
    57

    Default

    I'd be happy if i could use Google Earth at least... the open source driver is really nice, but as times passes i realize how often i would appreciate a 3D driver. I won't go back to fglrx, because i can't watch videos there (tearing alarm) and the sleep modes won't work. So i realize that i've wasted some money for my notebook with a good 3d card in it, because i can't use it...
    The news that 3d could come by the end of summer saddens me even more...

  3. #13
    Join Date
    Mar 2008
    Posts
    573

    Default

    Quote Originally Posted by blackiwid View Post
    I thought the 3d part would be more ready.

    I planed to buy a hd4870 1gb next week, but as i see i will not have 3d with the open driver till the dx11 ati cards come out (October), fglrx is no option for me. So i have no compiz for several months, I really consider my planed buying now.

    Right now i have an x800xl, maybe i look for an used X1950xtx or something like that, is the 3d part for r500 fast enough to play lets say quake wars on 1920x1200 with high settings? (without AA)
    Don't expect a working/stable/efficient ATI 3d driver before 2011. Considering the world ends in 2012 I suggest to avoid buying AMD. Buy an NVIDIA, at least you "finish" with a working gpu (but you might go to hell since their blob driver is unmoral. It's the only real driver really working good on Linux as of today but it's unmoral, so you decide: heaven without candy or hell with candy) :P
    Last edited by bulletxt; 07-03-2009 at 11:22 AM.

  4. #14
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,123

    Default

    Quote Originally Posted by blackiwid View Post
    I thought the 3d part would be more ready.

    I planed to buy a hd4870 1gb next week, but as i see i will not have 3d with the open driver till the dx11 ati cards come out (October), fglrx is no option for me. So i have no compiz for several months, I really consider my planed buying now.

    Right now i have an x800xl, maybe i look for an used X1950xtx or something like that, is the 3d part for r500 fast enough to play lets say quake wars on 1920x1200 with high settings? (without AA)
    Why is fglrx no option for you? If it's because it's closed source, then why do you want to buy a high-end card that couldn't be properly accelerated by the opensource driver anyway?

  5. #15
    Join Date
    Aug 2007
    Posts
    6,613

    Default

    Maybe because you have to switch between drivers to get a tearfree xv?

  6. #16
    Join Date
    Jul 2008
    Posts
    776

    Default

    because i use then another os (windows) to play games. all other than games dont need soo much acceleration.

    But i want get at least in near future compiz working with it, and enemy territory. maybe with 1920x1200 then i am happy for other games i have to use windows anyway, ok a few of em will work after several time with mesa, but thats no good alternative.

  7. #17
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,432

    Default

    In case this helps anyone understand the timing and status better, by early April Richard and Cooper had most of the driver code written and running including glxgears, texture operations, and arb_fp/arb_vp support with a working shader assembler. Like most fresh-from-the-developer code, it only really worked on the developers own systems and it had a bunch of obvious bugs, but all the core bits were in place and ready for integration testing.

    Unfortunately, by that time it had also become obvious that we would have to move onto the new bufmgr/cs code (from radeon-rewrite) before the driver could be broadly useful, since radeon-rewrite was going to merge into mesa master shortly. In case it's not obvious, that was *not* part of the original plan.

    Alex wrote an initial implementation of the new CS ioctls in mesa/drm (that's why the drm code is in ~agd5f/drm), and in early April we started moving the driver across to the new code base. That work is now pretty much finished, although there is at least one open problem with buffer allocation which shows up as a glxgears segfault, and the texture code still needs to be merged with bufmgr/cs and made to work.

    If you put your thumb over the April-to-now time period (mostly porting to radeon-rewrite and vacations) you'll probably get a better sense of the rate of progress.
    Last edited by bridgman; 07-03-2009 at 12:56 PM.

  8. #18
    Join Date
    Apr 2009
    Posts
    529

    Default

    Quote Originally Posted by bridgman View Post
    In case this helps anyone understand the timing and status better[
    I does indeed!. So, how are things looking from now on considering the change in plans. Could you please give a bit of a flavor of the next milestones and circa when they are being shot for. Of course I understand you might prefer not to, given that some ... ahem ... systematically negative people could hang on to it in the future to complain if something gets delayed.

    I really think it would be nice to have parties in some bigger cities (in whatever country people are) to celebrate THE milestone I don;t know how many people would be interested, but I think it will be a historic moment for open/free software (unimaginable just 10 years ago).

    Thank you all who are making this happen!

  9. #19
    Join Date
    Aug 2008
    Posts
    116

    Default

    Quote Originally Posted by bridgman View Post
    In case this helps anyone understand the timing and status better, by early April Richard and Cooper had most of the driver code written and running including glxgears, texture operations, and arb_fp/arb_vp support with a working shader assembler. Like most fresh-from-the-developer code, it only really worked on the developers own systems and it had a bunch of obvious bugs, but all the core bits were in place and ready for integration testing.

    Unfortunately, by that time it had also become obvious that we would have to move onto the new bufmgr/cs code (from radeon-rewrite) before the driver could be broadly useful, since radeon-rewrite was going to merge into mesa master shortly. In case it's not obvious, that was *not* part of the original plan.

    Alex wrote an initial implementation of the new CS ioctls in mesa/drm (that's why the drm code is in ~agd5f/drm), and in early April we started moving the driver across to the new code base. That work is now pretty much finished, although there is at least one open problem with buffer allocation which shows up as a glxgears segfault, and the texture code still needs to be merged with bufmgr/cs and made to work.

    If you put your thumb over the April-to-now time period (mostly porting to radeon-rewrite and vacations) you'll probably get a better sense of the rate of progress.
    Thank you for the explanation. It answered some of the the questions I had concerning the R600/R700 code (mostly about timing).

  10. #20
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,432

    Default

    The tasks and milestones are pretty easy but putting dates on them right now is tricky. The big unknown is whether our in-depth understanding of current Mesa internals is solid or not, and we'll only find that out by testing.

    The sequence of events for the short term is pretty simple though -- fix whatever is causing the glxgears segfault, finish hooking up texture code to the new buffer management logic, then test, fix, repeat. Most of the code is already written and has at least passed basic smoke tests, so the driver could come up really fast or it could drag on for a while. It all depends on whether we find any fundamental defects in the design. I don't think we will, but you never know.
    Last edited by bridgman; 07-03-2009 at 02:41 PM.

Posting Permissions

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