Page 4 of 6 FirstFirst ... 23456 LastLast
Results 31 to 40 of 54

Thread: The Major Open-Source ATI Improvements Over Two Years

  1. #31
    Join Date
    Jan 2009
    Posts
    631

    Default

    Old crappy extensions won't be added. Only the extensions which applications need and use will.

    You should see all those MISSING lines on proprietary drivers, you'd be hell of surprised.

    It's possible that some unused and unadvertised extensions will be removed from Mesa. Like who the hell needs GL_NV_fragment_program?

  2. #32
    Join Date
    Sep 2008
    Posts
    989

    Default

    Quote Originally Posted by BlackStar View Post
    There's a good reason why many of those functions are missing. For instance, moern hardware no longer supports color tables - should drivers implement a slow software fallback for that case? What about hardware- and vendor-specific extensions?

    What the goal should be is to make everything in OpenGL core available first, work on the compatibility profile second and, if there's nothing better left to do, add oddball extensions last. OpenGL 4.1 core is probably missing fewer than 100 entry points at this point (most of which are overloads of each other).

    Edit: for comparison, OpenGL 4.1 compatibility has ~1000 entry points or ~2200 incl. extensions.
    Problem being, vendors just keep on introducing new extensions, and application authors just keep on using them. If either (a) vendors would stop thinking they need a special extension just for them, or (b) app writers would stick to the required core + ARB extensions and write all their code in terms of that, there'd be a lot fewer app crashes out there. ESPECIALLY with commercial games (not necessarily run through Wine, either; a lot of native Linux games use extensions that aren't available in Mesa).

    Most game developers (with the exception of the vdrift author, I guess, since that game runs especially well on Mesa) are loathe to QA their software against any form of Mesa during the development process, and they're also unwilling to support or fix their software to be compatible with Mesa. So if the vendor extensions are out there, and apps are relying upon them, you can either support them, or you can just provide one more reason for people to resent the open source graphics stack.

    Linus Torvalds explains what I'm trying to say in more gruff, but more poignant and accurate words. He's referring to the glibc maintainers, but it could just as easily be applied to people hacking on Mesa who think that not implementing vendor extensions is a bad idea or lowest priority:

    https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129

    Who cares if you have to implement workarounds in software? Make the user call out hex into their microphone if you have to. But for the love of god, don't crash. If someone's GL app crashes, or refuses to start, or hangs their system, this is a problem in Mesa. I don't say this only because you can't fix proprietary programs to use 100% pure, standards compliant GL; I say this also because of the simple fact that, even if the user had the source code sitting on their hard drive, they wouldn't know how to fix it. You have to be a graphics developer (or at least a really crafty software engineer) to fix a problem like this; Joe User can't expect all open source programs to work 100% with Mesa just because they're open source. That's a pipe dream.

    Sure, open source programs are probabilistically more likely to run on Mesa because a developer might try the program with mesa, notice a problem, and fix it in the app rather than the driver, perhaps by writing the code to use a different extension. But who's to prevent an open source developer from writing a GL program that uses loads of vendor extensions not available in Mesa, and then getting that program checked in as binaries to Ubuntu, Fedora and OpenSUSE? It would likely get picked right up, especially if it's popular.

    At that point you're in the same situation regardless of whether the user is running a proprietary or open source app. It doesn't work. It might be the app's fault in principle, but in practice, it's the driver's fault -- especially if the same app binary works on other drivers.

    So why'd I write all this? Because right now I'm trying to add support for GL_ATI_draw_buffers to gallium, which is an extension that (very) closely resembles GL_ARB_draw_buffers, an extension already implemented. Hell, even glDrawBuffersARB is exposed as a public API in libGL. But it isn't advertised, and the shader compiler doesn't recognize it as an OPTION. Trine would run fine if someone would have bothered to write the 10 or 20 lines of code peppered here and there to support it. But now I'm left doing it, and I'm not even a graphics developer. I'm just following patterns I notice in the code, using my knowledge of C and intuition.

  3. #33
    Join Date
    Aug 2009
    Location
    south east
    Posts
    344

    Default

    Quote Originally Posted by allquixotic View Post
    Problem being, vendors just keep on
    Linus Torvalds explains what I'm trying to say in more gruff, but more poignant and accurate words. He's referring to the glibc maintainers, but it could just as easily be applied to people hacking on Mesa who think that not implementing vendor extensions is a bad idea or lowest priority:
    Good link.

  4. #34
    Join Date
    Jan 2009
    Posts
    631

    Default

    allquixotic,

    No matter what you are trying to point out, all I can say is: Patches welcome.

    Though I find it surprising that there is such a bullshit chat under an article that actually shows Catalyst is worse: 3 graphs show r300g is faster, other 3 graphs show Catalyst is faster, and the other two graphs show Catalyst can't run Nexuiz.

    (BTW, the Hyper-Z optimizations are disabled by default on r300g, so we still might be able to beat Catalyst in openarena and others if we enable them, who knows).

    Thanks to Michael for the article, it keeps us posted about the current state of drivers in a bigger picture.

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

    Default

    Quote Originally Posted by marek View Post
    Though I find it surprising that there is such a bullshit chat under an article that actually shows Catalyst is worse: 3 graphs show r300g is faster, other 3 graphs show Catalyst is faster, and the other two graphs show Catalyst can't run Nexuiz.
    LOL thats GOLD yes thats the real point.

    i personally use the radeon driver right now because: all stuff i need the catalyst for do not run for exampel wine+oblivion=crash/error and on the radeon side all stuff i do with my pc without stuff like wine+oblivion runs well on radeon!!

    means i can watch videos,chat,read on phoronix,surfing and i also play games like warzone 2100 an old but gold game for that stuff i do not need catalyst...

    last time i check for the catalyst for my hd4650/AGP system the system does not start black screen then i purge catalyst and radeon runs again...

    for the hole 2011 everytime i try something with the catalyst i fail.

    yes maybe i do it wrong and maybe i'm bad but how cares about my worst person? on radeon it runs...

  6. #36
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,153

    Default

    Quote Originally Posted by marek View Post
    Old crappy extensions won't be added. Only the extensions which applications need and use will.
    ARB_imaging is 'old and crappy' but is also used by a few applications.

    It's possible that some unused and unadvertised extensions will be removed from Mesa. Like who the hell needs GL_NV_fragment_program?
    Cg, mainly, as well as a few Nvidia demos. I wouldn't be surprised if a few games also utilized it, but GL_ARB_fragment_program should be more than sufficient.

    Quote Originally Posted by allquixotic
    Problem being, vendors just keep on introducing new extensions, and application authors just keep on using them.
    Yes, this is called progress. Word it differently and you'll how ridiculous this sounds:

    "Problem being, the Gnome Foundation just keeps on introducing new versions, and application authors just keep on using them."

    "Problem being, Intel just keeps on introducing new processors, and application authors just keep on using them."

    Who the hell needs a quad core SB when you already have a Pentium 200MHz (non-MMX)? (But, but... SB is more capable! Yes, so are those new extensions).

    Quote Originally Posted by marek
    Though I find it surprising that there is such a bullshit chat under an article that actually shows Catalyst is worse: 3 graphs show r300g is faster, other 3 graphs show Catalyst is faster, and the other two graphs show Catalyst can't run Nexuiz.

    (BTW, the Hyper-Z optimizations are disabled by default on r300g, so we still might be able to beat Catalyst in openarena and others if we enable them, who knows).

    Thanks to Michael for the article, it keeps us posted about the current state of drivers in a bigger picture.
    Quoted for truth!

    The rest is bullshit from the haters and naysayers who don't miss a chance to bash the open-source drivers.

  7. #37
    Join Date
    Jun 2009
    Posts
    2,937

    Default

    Quote Originally Posted by marek View Post
    Though I find it surprising that there is such a bullshit chat under an article that actually shows Catalyst is worse: 3 graphs show r300g is faster, other 3 graphs show Catalyst is faster, and the other two graphs show Catalyst can't run Nexuiz.
    Marek, you (and the other devs) have killed most of the anti-OSS "arguments" people like to spout around here.

    They are getting desperate, which is just beautiful to see

  8. #38
    Join Date
    Jan 2008
    Location
    Have a good day.
    Posts
    678

    Default

    Quote Originally Posted by marek View Post
    (BTW, the Hyper-Z optimizations are disabled by default on r300g, so we still might be able to beat Catalyst in openarena and others if we enable them, who knows).
    Is this something users can enable somehow?

  9. #39
    Join Date
    Jan 2009
    Posts
    631

    Default

    Set this environment variable:

    RADEON_HYPERZ=1

    It's worth mentioning it really speeds up openarena. You can also set this to get info whether it's actually used:

    RADEON_DEBUG=info

    The latter is available only in 7.11-devel IIRC and it prints something like this:

    r300: AA compression: NO, Z compression: YES, HiZ: YES

    The text in bold is the Hyper-Z status. We don't enable it by default because of some bugs, but most apps should work fine. If you find a bug, please report it at https://bugs.freedesktop.org/

  10. #40
    Join Date
    Jan 2009
    Posts
    515

    Default

    Quote Originally Posted by marek View Post
    Set this environment variable:

    RADEON_HYPERZ=1

    It's worth mentioning it really speeds up openarena. You can also set this to get info whether it's actually used:

    RADEON_DEBUG=info

    The latter is available only in 7.11-devel IIRC and it prints something like this:

    r300: AA compression: NO, Z compression: YES, HiZ: YES

    The text in bold is the Hyper-Z status. We don't enable it by default because of some bugs, but most apps should work fine. If you find a bug, please report it at https://bugs.freedesktop.org/
    Do you know when these things will get 'ported' to r600g? Or are they not needed / supported by the hardware?

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
  •