Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 25

Thread: Gaming With The Open-Source R500 Driver

  1. #11
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,572

    Default

    Quote Originally Posted by yoshi314 View Post
    is ati planning to devote some extra paid developers to work on gallium/mesa once ttm/gem and gallium api dust settles?
    No "extra" paid developers but the ones we have will shift from "Classic Mesa" to Gallium. Most of the knowledge gained by working on the current Mesa will carry right over to Gallium.

    TTM/GEM implementation will be a pre-requisite for Gallium (and lots of other things) so that will be the first task.
    Last edited by bridgman; 05-28-2008 at 06:00 PM.

  2. #12
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    Gallium is really a new standard for implementing the hardware acceleration parts of Mesa. As far as I know the resulting code will still be called Mesa, just "the new, improved, post-Gallium Mesa"

    I'm probably missing a key benefit or two (sorry guys) but the main benefits seem to be :

    - the code which used to be required for a Mesa driver is being split into three parts (state tracker, driver, winsys) and only one of those parts will need to change from one GPU to the next

    - the driver structure is designed for modern shader-based GPUs, while the current Mesa structure is designed around the GPUs of the time, which implemented a full fixed-function OpenGL pipeline

    - the new structure will make support of OpenGL 2.x and higher easier since it won't be tied as strongly to the fixed-function pipeline

    - it's new and cool and everyone wants to work on it

    Gallium itself does not really move any code into the kernel.
    I really love the Linux spirit. If it isn't broken, open it, and fix it

    Thanks for explaining Gallium to me. I had it mixed up with kernel-based mode-setting

    ... Which is guess is a separate project to move some of the Gallium code in to the kernel...?

  3. #13
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,572

    Default

    Quote Originally Posted by Louise View Post
    I really love the Linux spirit. If it isn't broken, open it, and fix it
    It's sort of become broken over the years; the GPUs changed completely but the driver model did not keep up. Gallium seems to fix that nicely.

    Quote Originally Posted by Louise View Post
    Thanks for explaining Gallium to me. I had it mixed up with kernel-based mode-setting

    ... Which is guess is a separate project to move some of the Gallium code in to the kernel...?
    Kernel based modesetting moves modesetting (display-related) code from the X driver to the kernel (aka drm)

    TTM/GEM moves memory management from the X driver to the kernel (drm) and makes it mo' better

    DRI2 moves everything around a little bit between X driver, drm and mesa but the general direction seems to be kernel-ward again.

  4. #14
    Join Date
    May 2008
    Posts
    598

    Default

    Quote Originally Posted by bridgman View Post
    Kernel based modesetting moves modesetting (display-related) code from the X driver to the kernel (aka drm)

    TTM/GEM moves memory management from the X driver to the kernel (drm) and makes it mo' better

    DRI2 moves everything around a little bit between X driver, drm and mesa but the general direction seems to be kernel-ward again.
    It's very impressive! Who keeps track of what and when to do it?

    Does AMD have a roadmap/"prioritized list" of what they would like to see done and when?

  5. #15

    Default

    I am wondering...

    Is is possible to play movies with these drivers at this state? If, what output device in MPlayer would be the recommended?

    In regards to power consumption. Nouveau is planning on adding "Power Saving". Will that be possible in the OSS ATi 3D drivers? If, how many procent are we talking about? Approx of course

    /HyggeMonster/

  6. #16
    Join Date
    Oct 2007
    Posts
    124

    Default I would like game tests in FPS versus Windows

    I'm a gamer, it is the only reason I still use Windows.
    I have planned to use in my next computer Ubuntu with KVM for windows games instead of a native windows installation, and play opengl games under Linux when its FPS would be similar, at least 90% of performance.

    I would like to read this kind of comparations.
    Vista, XP, Mac, Vista, XP with KVM - and Xen-, Linux, and Mac, for opengl.
    And XP Vista with KVM, Xen, and Paralelis for directx games.

  7. #17
    Join Date
    Jul 2007
    Posts
    405

    Default

    Movies are definitely playable with this driver. Just use the Xv output, and you get nice, smoothly scaled textured video. Most of the stability issues have been resolved (I'm still having problems, but that's probably because my motherboard's dying.)

  8. #18
    Join Date
    Oct 2007
    Posts
    370

    Default

    so... which card should i get to best use this stuff?

  9. #19
    Join Date
    Jan 2007
    Posts
    33

    Default

    Quote Originally Posted by Kano View Post
    Not bad for the first try. Did not expect it yet, but nice to see. I do not own R500 (nor R600) to try this, but for some basic uses fglrx will be soon obsolete like compiz. I would compare it against Intel G33/G35 however when you start benchmarking after the rendering problems got fixed. One huge problem with Intel onboard is the missing GLSL support (somebody mentioned that it could work with 965G but can not verify this).
    IMO, fglrx is already obsolete. Can I ask what you mean about compiz becoming obsolete? is there something better coming?

  10. #20
    Join Date
    Jun 2007
    Posts
    145

    Default

    hi,

    speaking of ttm/gem, is there already a favourite? as far as i know, gem seems to be a kinde of a "fork" of ttm made by intel?! both inside the kernel don't make sense for me... nouveau & radeonhd are going to use ttm nevertheless, aren't they?!

Posting Permissions

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