Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 37

Thread: AMD's Open-Source Radeon Driver After Four Years

  1. #11
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by Sidicas View Post
    I hope they do bring MSAA to the Gallium3D R300 drivers eventually..
    just ask super marek ;-)

    he do have time traveling machine he code it yesterday in the past for you and deliver it to you right now...

  2. #12
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,146

    Default

    Quote Originally Posted by Sidicas View Post
    Yea, I'm still reading up on MLAA, but from what I've read, MLAA is far more taxing on graphics hardware than MSAA is.. So even if they did implement it on older hardware, I wonder if it would even be usable for anything.

    MLAA is visually far superior than MSAA, but there's a lot more processing involved in it. All I really want is just 2XMSAA with some decent framerates.. MLAA will give amazing graphics but will have bad framerates on older hardware, no doubt.
    Not necessarily and not necessarily: MLAA is a post-processing effect that doesn't have access to subpixel information, which leads to worse image quality on thin lines. On the other hand, it filters the whole scene, not just polygon edges, which can lead to better quality on scenes with very detailed textures.

    Regarding performance, GPUs have dedicated hardware for MSAA which can be quite fast, indeed. However, this hardware has two drawbacks: (a) it's very limited and doesn't cooperate well with modern 3d engines; (b) performance is dependent on the number of polygons in the scene (the more polygons the lower the performance).

    MLAA, on the other hand, can be used in every scene and has constant overhead that depends only on the resolution used. Most Xbox360 and PS3 games use variants of MLAA, so we know for a fact that this filter can run on modest hardware at 720p. Intel has also published papers that show the effect running on the CPU in real-time (i.e. render the scene on the GPU, download to the CPU for filtering and re-upload for display).

    Without looking at the code or any benchmarks, my guess is that MLAA should be usable on most mid/high-range SM3.0 card and maybe a few high-end SM2.0b cards, provided enough memory bandwidth.

  3. #13
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,185

    Default

    Jimenez' MLAA is actually very good. It's ~12x faster than MSAA 8x (upstream measurement w/ DX; may not be equivalent to the Mesa implementation), better quality than Sony's PS3 one, and better quality & faster than AMD's.

    I don't know how it compares in speed with MSAA 2x though.


    The minimum hw is r500 / gf6, and it runs quite well on my E-350.

  4. #14
    Join Date
    Sep 2006
    Posts
    714

    Default

    Quote Originally Posted by pingufunkybeat View Post
    Of course AMD is not going to abandon their Windows drivers.
    I didn't say they should stop developing Windows driver. I said they should drop development for the proprietary Linux driver.

    Catalyst for Linux = 95% cross-platform code shared with the Windows driver + 5% of Linux-specific glue code.
    I think if you pay close attention to what you written it may make it a bit more obvious why this approach may be very suboptimal from a Linux standpoint.

    Anyways the evidence speaks for itself. The catalyst driver is much older, has a much higher budget and workforce behind it and yet it is still one of the worst graphics drivers available for Linux.

    If it wasn't for the OSS driver I wouldn't touch it with a ten foot pole and modern Linux desktops would be horribly broken by default for anybody wanting to use ATI's hardware for any purpose (including professional workstations)

    It's not like that have 500 Linux hackers working on the Linux blob. It's mostly guys doing cross-platform code, which ends up in the Windows driver.
    Don't care. Doesn't matter.

    I don't think that there would be any big difference if they dropped Catalyst development, other than losing 90% of their workstation customers who need OpenGL 3 and blob-only features.
    yeah right. How competitive do you think their proprietary driver is against Nvidia's?

    (hint: They are not doing OSS driver support just to make Linux nerds happy.)

  5. #15
    Join Date
    Oct 2008
    Posts
    3,173

    Default

    Quote Originally Posted by Sidicas View Post
    Yea, I'm still reading up on MLAA, but from what I've read, MLAA is far more taxing on graphics hardware than MSAA is.. So even if they did implement it on older hardware, I wonder if it would even be usable for anything.

    MLAA is visually far superior than MSAA, but there's a lot more processing involved in it. All I really want is just 2XMSAA with some decent framerates.. MLAA will give amazing graphics but will have bad framerates on older hardware, no doubt.

    I hope they do bring MSAA to the Gallium3D R300 drivers eventually..
    MLAA does require at least r500 hardware, so MSAA would be nice to have for r300/r400.

    Once it's integrated into Mesa and the hardware drivers are working, I hope Phoronix can do some benchmarks of MLAA. It's not entirely clear to me right now exactly how taxing it is.

  6. #16
    Join Date
    Oct 2008
    Posts
    3,173

    Default

    Quote Originally Posted by drag View Post
    I think if you pay close attention to what you written it may make it a bit more obvious why this approach may be very suboptimal from a Linux standpoint.

    Anyways the evidence speaks for itself. The catalyst driver is much older, has a much higher budget and workforce behind it and yet it is still one of the worst graphics drivers available for Linux.
    It's my impression that AMD dropping linux fglrx support would likely lead to LESS linux support of the OSS driver - likely a complete abandonment of all Linux support - rather than more. But we'll never know for sure, because it's not going to happen.

  7. #17
    Join Date
    Jun 2011
    Posts
    316

    Default

    Quote Originally Posted by smitty3268 View Post
    It's my impression that AMD dropping linux fglrx support would likely lead to LESS linux support of the OSS driver - likely a complete abandonment of all Linux support - rather than more. But we'll never know for sure, because it's not going to happen.
    Unless the reason for dropping the fglrx support is that the open source drivers are better in every way than the Catalyst drivers... Unfortunately AMD/ATI has shown that they'll drop fglrx support on hardware long before the open source drivers are mature... They've done it in the past and I wouldn't put it by them to do it again...

  8. #18
    Join Date
    Jun 2009
    Posts
    2,932

    Default

    Quote Originally Posted by drag View Post
    yeah right. How competitive do you think their proprietary driver is against Nvidia's?
    According to Bridgman, they have many professional customers with lots of workstations. Which is why they are doing the Catalyst drivers, not to make Linux nerds happy. And these customers don't care much for desktop effects, XVideo tearing and other problems Catalyst has, and run stable distro where Catalyst is tested.

    (hint: They are not doing OSS driver support just to make Linux nerds happy.)
    Actually, they are doing it for the embedded market, as far as I know, because the big customers there asked for it. I'm sure Bridgman will correct me if I'm wrong.

    Personally, I've never even tried Catalyst, that's how much I care about it. OSS driver is the only thing that I'm interested in, and the more devs working on it, the better. But it's a pipe dream that AMD will give up on 20 years of optimisations and know-how in their Catalyst driver just so they can lose their entire workstation market, and move three guys over to the OSS team.

  9. #19
    Join Date
    Jan 2009
    Posts
    1,435

    Default

    Quote Originally Posted by BlackStar View Post
    The open-source drivers recently gained support for MLAA, an antialiasing post-processing filter. This is similar to techniques utilised in modern games which do not support MSAA (for various technical reasons that go beyond this discussion).

    In short, the open-source drivers have now reached feature parity with 9.3, are more stable, offer faster 2d, slightly slower but more featureful 3d (closer to GL 3.0 vs GL 2.1 in fglrx 9.3). Work is also underway for video acceleration. Soon, there'll be little reason to not use the open-source stack on older hardware.
    I'd never heard of MLAA before yesterday and so I did a little research about it. WOW! I had no idea it was such a cutting edge feature. The technique was only proposed in, IIRC, 2007 by this guy working at intel. Another article I read was by a developer for GoW3 and had what was apparently the first feasible (fairly fast and quality) implementation of MLAA.
    I'm very (pleasantly) surprised this is coming to Linux so quickly.I also like the idea of MLAA. A nice, simple post-processing idea that can be applied to any scene (though, unlike BlackStar I don't think it is variable only across resolution since it seems very much edge/color contrast dependent).
    Last edited by liam; 08-17-2011 at 05:31 PM.

  10. #20
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by liam View Post
    I'd never heard of MLAA before yesterday and so I did a little research about it. WOW! I had no idea it was such a cutting edge feature. The technique was only proposed in, IIRC, 2007 by this guy working at intel. Another article I read was by a developer for GoW3 and had what was apparently the first feasible (fairly fast and quality) implementation of MLAA.
    I'm very (pleasantly) surprised this is coming to Linux so quickly.
    "cutting edge feature"

    LOL ??? not really its a poor man feature real man get this: Rotated Sample-Super-Sample-AA RS-SSAAx8

    but this killer cutting edge feature kill all hardware thats why they do MLAA the poor mans AA..

Posting Permissions

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