Page 2 of 7 FirstFirst 1234 ... LastLast
Results 11 to 20 of 69

Thread: Performance Work Coming Up For Mesa 7.11

  1. #11
    Join Date
    Oct 2009
    Posts
    353

    Default

    Quote Originally Posted by smitty3268 View Post
    The last comparison i saw had it between 50-60%. With the recent optimizations Marek has committed I'd guess we might be over 60% now.
    The newer catalyst driver is _way_ faster then Gallium, like here:
    http://www.phoronix.com/scan.php?pag...ver_q111&num=4
    or even worse, like here:
    http://www.phoronix.com/scan.php?pag...ver_q111&num=8

    Is it the whole code or just a few parts in Gallium that make it lag behind that much? Is it like "all we need is rewrite GLSL" to match Catalyst or is it like "we need to rewrite pretty much anything"? Just wondering..

  2. #12
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

    I think he meant r300g, not r600g. r300g can only be compared against older Catalyst drivers (newer ones don't support old GPUs.)

  3. #13
    Join Date
    Dec 2007
    Posts
    2,335

    Default

    Quote Originally Posted by cl333r View Post
    Is it the whole code or just a few parts in Gallium that make it lag behind that much? Is it like "all we need is rewrite GLSL" to match Catalyst or is it like "we need to rewrite pretty much anything"? Just wondering..
    If we knew exactly what needed to be fixed we'd do it. It comes down to lots of profiling. The closed driver is build on a stack specifically tuned to AMD hardware that was honed over the last 10-15 years by 10-20x the developers of the open source driver. Mesa is aimed at making it easy to support various graphics APIs on a wide range of hardware.

  4. #14
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,788

    Default

    Quote Originally Posted by agd5f View Post
    If we knew exactly what needed to be fixed we'd do it. It comes down to lots of profiling. The closed driver is build on a stack specifically tuned to AMD hardware that was honed over the last 10-15 years by 10-20x the developers of the open source driver. Mesa is aimed at making it easy to support various graphics APIs on a wide range of hardware.
    Tell that to the "blobs must die, only open source drivers should be allowed in Linux" bozos.

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

    Default

    Quote Originally Posted by cl333r View Post
    The newer catalyst driver is _way_ faster then Gallium, like here:
    http://www.phoronix.com/scan.php?pag...ver_q111&num=4
    or even worse, like here:
    http://www.phoronix.com/scan.php?pag...ver_q111&num=8

    Is it the whole code or just a few parts in Gallium that make it lag behind that much? Is it like "all we need is rewrite GLSL" to match Catalyst or is it like "we need to rewrite pretty much anything"? Just wondering..
    Yeah, we were talking about r300g, not the r600 and newer cards. To be fair, if AMD had continued supporting those older cards they would probably be faster now than they were in the old Cat 9.3 drivers, but there's no way to test that. r300g is much more stable and works better than the old Catalyst driver ever did, so it's not like anyone is going to switch back, but i still think it would be interesting to see the comparison to get an idea of how the current driver compares to what used to be considered acceptable speed for that hardware.

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

    Default

    Quote Originally Posted by RealNC View Post
    Tell that to the "blobs must die, only open source drivers should be allowed in Linux" bozos.
    Someone has to counter the "open source drivers suck, everyone should just use Intel/NVidia with linux" bozos, right?

  7. #17
    Join Date
    Jan 2009
    Posts
    619

    Default

    Quote Originally Posted by r1348 View Post
    Yeah, if only r300g was any usable on my laptop with an Xpress 200m, instead of displaying fuzzy random horizontal lines...
    Feel free to file a new bug at: https://bugs.freedesktop.org/

  8. #18
    Join Date
    Oct 2010
    Posts
    138

    Default

    The big thanks goes to Marek Olsak and Corbin Simpson, who resurrected the r300-r500 hardware with their outstanding efforts and without the support of a giant company behind them. The other big thanks goes to Intel for their quality glsl compiler.

    THANKS

  9. #19
    Join Date
    Mar 2010
    Posts
    158

    Default

    Quote Originally Posted by cl333r View Post
    The newer catalyst driver is _way_ faster then Gallium, like here:
    http://www.phoronix.com/scan.php?pag...ver_q111&num=4
    or even worse, like here:
    http://www.phoronix.com/scan.php?pag...ver_q111&num=8

    Is it the whole code or just a few parts in Gallium that make it lag behind that much? Is it like "all we need is rewrite GLSL" to match Catalyst or is it like "we need to rewrite pretty much anything"? Just wondering..
    Gallium drivers are a work in progress. The comparisons that you linked to do not include any of the performance improvements that are the subject of this thread, nor do they include Page Flipping which will not be available until Linux kernel 2.6.38 is released.

    http://www.phoronix.com/scan.php?pag...item&px=ODcyMA

    Apparently Page Flipping support alone will bring considerable improvement in performance, and coupled with improvements (announced in this thread) to "command submission and resource space checking" and "ensuring the same user-buffer is not uploaded multiple times to the GPU", in "optimize the shaders used for the iDCT and MC code", and aslo in "removing the temporary register usage from most instructions, special constants, TEX and VTX joning, reworked swizzle code, fully implemented barrier handling, reworked literal handling, and implement register remapping", the cumulative improvements in each of these optimizations will probably see a huge aggregte improvement over and above the comparisons you linked to.

    The Gallium3D drivers are still raw, and are still mostly just trying to implement all features. Optimization work has almost been non-existant so far. There is a lot of low-hanging fruit, from what I can tell, which will quickly improve performance once these initial optimisations are implemented.

  10. #20
    Join Date
    Nov 2010
    Location
    Stockholm, Sweden
    Posts
    399

    Default

    Quote Originally Posted by Hephasteus View Post
    Well you guys tried really hard and did a wonderful job. It's just too late. The military beat up people, sociopath lie constantly model doesn't work at these population levels. They'll kill a bunch of people this year and those people will simply drop out of the collective conciousness by not returning to source. Kind of like the 60's drop out but with teeth.
    Linux will likely get swallowed by apple in a couple years who will use python to spy on everybody.
    Hahahaha what? Gimme that tinfoil hat! Give it to me!

Tags for this Thread

Posting Permissions

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