OpenGL state on NVIDIA/AMD

Discussion in '3D Hardware, Software & Output Devices' started by DavidGraham, May 14, 2014.

  1. Novum

    Regular

    Joined:
    Jun 28, 2006
    Messages:
    335
    Likes Received:
    8
    Location:
    Germany
    Oh, yeah, it's smart too, but the arrogance will make sure it doesn't happen first ;)
     
  2. silent_guy

    Veteran Subscriber

    Joined:
    Mar 7, 2006
    Messages:
    3,754
    Likes Received:
    1,379
    Oh, so the arrogance part was just trolling?
     
  3. DmitryKo

    Regular

    Joined:
    Feb 26, 2002
    Messages:
    694
    Likes Received:
    577
    Location:
    55°38′33″ N, 37°28′37″ E
    Considering portability across different vendors, from what I gather, Mantle can be mapped to any massively parallel GPU that is based on Direct3D 11.x.

    It's not really tied to AMD hardware since it does not directly expose low-level hardware-specific features. The GPU is still abstracted - there are HLSL shaders and shader compiler, pipeline state changes, and draw calls. There is no access to architecture-specific RISC SIMD code and register stack, no knowledge of actual number and composition of wavefront processors in the GPU execution stack, etc.

    The Mantle API may be closer to the actual graphics hardware, but mostly by removing higher-level abstractions for resources by treating them as just "memory" and changing the binding model and adding draw command lists to allow parallel execution.

    http://www.slideshare.net/DevCentralAMD/mantle-introducing-a-new-api-for-graphics-amd-at-gdc14/23


    As for platform holders, AMD is doing exactly this - i.e. releasing low-level GPU documentation, actively participating in Mesa/Gallium3D project and requesting Linux Kernel team to approve changes that would allow RadeonDRM kernel-mode driver to work as a foundation for Mesa/Gallium3D and fglrx (Catalyst for Linux) and probably other APIs like Mantle.

    None of the above. I believe in a scenario where

    1) Windows developers push AMD to eventually open up the specification;
    2) Valve and SteamOS developers push AMD to provide a working implementation of Mantle on Linux for AMD hardware;

    If the initial implementation matches or exceeds developer expectations, then

    3) Valve and SteamOS developers further push AMD to allow other vendors' implementations and to accept modifications to the API if needed (but still retain the control of the spec);

    If other vendors (i.e. NVidia) are not interested, then

    4)The open source community should be able to implement an open-source Mantle driver on top of Gallium3D and the Nouveau driver, which already supports a good deal of OpenGL 4.x for Mesa (though this might again require reengineering of the graphics kernel API).

    Once (and if) Mantle gets there and builds some momentum in the Linux community, it would be the right moment to consider a committee or industry consortium to maintain the API, but not until then.

    Everything in this thread is just meaningless speculation.
     
  4. DmitryKo

    Regular

    Joined:
    Feb 26, 2002
    Messages:
    694
    Likes Received:
    577
    Location:
    55°38′33″ N, 37°28′37″ E
    Yep, Quake was the killer application for OpenGL gaming on Windows in 1997-1998, then Microsoft somehow got their act together and introduced hardware accelerated transform and lighting in 1999 with Direct3D 7, programmable pixel/vertex shaders in 2000 with Direct3D 8, and HLSL (SM3) in 2003 with Direct3D 9. All the while OpenGL ARB just stalled helplessly then failed any and all attempts to revive the API.

    Base OpenGL 4.4 for all AMD graphics processors starting from EverGreen to Northern Islands and up:

    http://www.g-truc.net/project-0033.html#menu
    http://www.g-truc.net/project-0034.html#menu
    http://en.wikipedia.org/wiki/OpenGL#OpenGL_4.4
    http://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units#Evergreen_.28HD_5xxx.29_Series
     
    #44 DmitryKo, May 20, 2014
    Last edited by a moderator: May 20, 2014
  5. silent_guy

    Veteran Subscriber

    Joined:
    Mar 7, 2006
    Messages:
    3,754
    Likes Received:
    1,379
    At GDC, there were a number of presentations on how to make OpenGL blazing fast with the currently existing APIs.

    How much extra performance will Mantle have over those techniques?

    My guess: very little.

    If so, instead of advocating a whole new API that is controller by one vendor, why not champion the cause of making the existing OpenGL API less bugged for some vendors? Isn't that a much more direct way to fix things?
     
  6. Dave Baumann

    Dave Baumann Gamerscore Wh...
    Moderator Legend

    Joined:
    Jan 29, 2002
    Messages:
    14,079
    Likes Received:
    648
    Location:
    O Canada!
    It was clear that initial adoption of Mantle in BF4 was in an early Beta phase.
     
  7. Dave Baumann

    Dave Baumann Gamerscore Wh...
    Moderator Legend

    Joined:
    Jan 29, 2002
    Messages:
    14,079
    Likes Received:
    648
    Location:
    O Canada!
    Sometimes a clean sheet is just a better way of doing things.
     
  8. Andrew Lauritzen

    Moderator Veteran

    Joined:
    May 21, 2004
    Messages:
    2,526
    Likes Received:
    454
    Location:
    British Columbia, Canada
    Ugh, no. So despite what you said in the previous reply, you're not on the same page with respect to the fundamental facts here. :S

    ... so you completely agree with my point. i.e. a platform vendor (Valve/SteamOS) needs to get involved. I don't understand how you say "none of the above" and then describe one of my two scenarios. But you have to ask the question now - is Valve willing/able to do for SteamOS graphics what Microsoft does with Direct3D? Would getting folks to use a new API that only works on a small subset of Steam machines be a good idea for a new platform that is going for more console-like simplicity?

    One IHV controlling a "portable" spec is a complete non-starter. Valve would have to have the final word on things given input from all of the IHVs and devs.

    Mantle/D3D12-like APIs are not (efficiently) implementable on top of conventional graphics APIs or else we wouldn't need them in the first place.
     
  9. DmitryKo

    Regular

    Joined:
    Feb 26, 2002
    Messages:
    694
    Likes Received:
    577
    Location:
    55°38′33″ N, 37°28′37″ E
    Well, too bad for Intel.

    How so? You are assuming that the platform vendor (Valve/SteamOS) or some committee should control the API spec and push everyone in the right direction. I suggest the spec to remain proprietary with AMD and let open source community provide the implementation. Not hardware vendors or consortiums (like AMD/Nvidia/Khronos as in the case of OpenGL) or platform owners (Microsoft as for Direct3D).

    Why exactly it has to be Valve and not Linux Kernel developers or Gallium3D/Mesa developers?

    Gallium3D is not a conventional graphics API, it's a user mode driver framework. The user-mode library that implements OpenGL is Mesa.

    How exactly "console-like simplicity" for end users is affected by the choice of graphics API?

    As for developers, they are already pushing AMD for Mantle on Linux, not somehow being coerced by AMD into using it. Let them choose - either implement full OpenGL to be compatible with all Steam Machines built to the spec, or only implement Mantle and support a limited subset of SteamOS users. Android Market aka Google Play, iTunes and Microsoft Store all support a wide variety of devices and OS platforms/versions - why can't Steam do?


    Let's not forget that SteamOS itself is currently a very limited subset of Windows/MacOS users on Steam, so Mantle support would initially come from existing Direct3D games on Windows. Supporting SteamOS/Mantle would help these developers get more revenue without re-engineering their titles for OpenGL. And for games built on multiplatform game engines this would be simply a free bonus.
     
    #49 DmitryKo, May 20, 2014
    Last edited by a moderator: May 20, 2014
  10. Blazkowicz

    Legend Veteran

    Joined:
    Dec 24, 2004
    Messages:
    5,607
    Likes Received:
    256
    Valve virtually sells nvidia cards, with the Steam boxen. So back to the idea of nvidia supporting Mantle.

    Eh, could nvidia build a gaming graphics API on top of CUDA?, that would be a good way to be nasty to its competitors.
    (I'm not suggesting that seriously)

    Indeed, it's a "State Tracker" which also allows to implement OpenCL, vector graphics acceleration and possibly other things. Even Direct3D implementations for linux (serious work have been done with D3D9 support)

    I don't see what any leverage linux kernel developers would have. None, except that story about the dma_buf API where the API was limited to GPL kernel modules (that API seems vital to move data between an APU or IGP and GPU for instance). Mainly for debugging reasons : they deemed unacceptable to have a black box messing with that semi-critical stuff. Kernel devs wouldn't be able to even do their work properly.
    This would rule out proprietary AMD Catalyst using the feature even, but the announced re-
    architecturing could work around it.

    I had to check it to not say non sense (March 2014) :
    http://www.phoronix.com/scan.php?page=article&item=amd_catalyst_kernel&num=1

    New linux Catalyst will consist in a open source kernel part coupled with proprietary user space.
    But Catalyst still won't use Gallium. That's what the fully open source one still will do.

    MESA/Gallium 3D write fine software maybe, but they can't force people to be their users.
    It's a given that nvidia won't spend millions refactoring their driver to run on Gallium3D, only to suffer a level of indirection with its performance and bugs, as well as licensing and political issues. They have all their stuff running already (OpenGL, CUDA, NVENC, Quadro - though don't count on SLI or 3D Vision for Geforce) and it's virtually the same under Windows, Linux including on ARM, BSD, (Solaris. is anyone running that as a workstation?)
     
  11. DmitryKo

    Regular

    Joined:
    Feb 26, 2002
    Messages:
    694
    Likes Received:
    577
    Location:
    55°38′33″ N, 37°28′37″ E
    Valve wants to sell Steam games, that's why they figured they need their own SteamOS platform which is locked to the Steam Store. Steam Machines is only a vehicle to distribute SteamOS.

    Yes, but RadeonDRM is a Direct Rendering Manager module, which is the the most basic kernel mode driver responsible for sending rendering commands to the graphics hardware and managing hardware resource. On top of DRM, there is DRI (direct rendering infrastructure) driver, which are currently implemented using Mesa graphics library, Gallium3D state trackers for OpenGL, GLX, OpenGL ES etc, and user-mode Mesa-DRI hardware specific driver which implements translation to actual GPU commands.

    So it is the whole point of the Catalyst refactoring - to have open-source GPL-licensed kernel driver as a foundation for both Catalyst OpenGL driver and Mesa-based DRI user-mode drivers.

    http://en.wikipedia.org/wiki/File:Linux_Graphics_Stack_2013.svg
    http://en.wikipedia.org/wiki/File:The_Linux_Graphics_Stack_and_glamor.svg

    From what I read in the docs, it is also possible to implement other user modules that use the DRM driver in parallel to the Mesa/Gallium infrastructure, and still retain Mesa for emulating other graphics APIs.
    I.e. other than implementing a Gallium3D tracker for Mantle, we there can be a different user-mode module that does its own processing of actual hardware commands independently of DRI/Mesa.

    http://dri.freedesktop.org/wiki/DRM/
    [http://people.freedesktop.org/~ajax/dri-explanation.txt

    That would allow running the Catalyst user-mode driver for OpenGL, Mesa user-mode emulation for Direct3D9/Glide APIs, another user-mode module for Mantle support, etc.


    DRM is part of the Linux Kernel, so it's their area of responsibility, as far as I understand the development model. They can potentially block any changes to the API that may be required for efficient implementation of Mantle on either Radeon or Nvidia hardware.

    They don't need to refactor to Gallium3D, but they need replace their proprietary kernel-mode blob (driver) with a DRM-compliant kernel mode driver, just like AMD does with the Catalyst.

    If they don't comply, then the community could base their efforts on the Nouveau driver in order to implement Mantle on Nvidia hardware.
    So far Nouveau is slowly getting feature complete, but it's still very slow as they currently have issues with proper dynamic clock management and run at very low GPU frequencies.
     
    #51 DmitryKo, May 20, 2014
    Last edited by a moderator: May 20, 2014
  12. Andrew Lauritzen

    Moderator Veteran

    Joined:
    May 21, 2004
    Messages:
    2,526
    Likes Received:
    454
    Location:
    British Columbia, Canada
    ... and everyone else including AMDs previous D3D11 hardware. But, you know, according to the internet Microsoft basically did nothing and copied Mantle for D3D12 so that must be true, right? Devs said it, and devs are experts on GPU hardware, right guys? (insert more twitter quotes from enthusiastic devs)

    The point is "what you gathered" is patently wrong but you believed it anyways because it supported your agenda. That's normal but remember where the information came from and don't dig in your heels when someone corrects you.

    And this is where you demonstrate a lack of understanding of a lot of things.

    I don't generally like to do this, but before we continue I have to ask... are you a developer (ideally graphics) or just a Linux/AMD enthusiast reading random documentation and looking for tidbits that support your world view? If the former and you're willing to learn we might be able to come to an understanding here. Otherwise I have no interest in trying to educate you if you clearly aren't going to listen.
     
  13. Blazkowicz

    Legend Veteran

    Joined:
    Dec 24, 2004
    Messages:
    5,607
    Likes Received:
    256
    I have bad news for you, this thing shows every possible driver for a subset of hardware from four vendors, and it's "Linux Graphics Stack 2013" (so the new AMD model doesn't register on it).

    For a Radeon with Catalyst or a Geforce with "nvidia" the path to a game or Wayland application or compositor is blob -> "LibGL" > [game or Wayland client or compositor] ; the arrows don't explictly touch the mesa parts ?!?
     
  14. DmitryKo

    Regular

    Joined:
    Feb 26, 2002
    Messages:
    694
    Likes Received:
    577
    Location:
    55°38′33″ N, 37°28′37″ E
    If "you are patently wrong" is all that you can disclose, I have no interest in following this either.

    Yes, I probably do. I can't understand why Server Message Block, OpenGL etc. can remain open specs under proprietary control, and the open source community has no problem making a free implementation of them without supervision from any committee, but Mantle has to be so much different. Maybe I don't even need to understand this.

    Neither of the above (I am a former software developer, but I'm neither a Linux developer nor a Linux/AMD enthusiast).

    Proprietary kernel-mode blobs and DRM kernel-mode can not work together because they each try to directly access the same hardware, that's the point.

    However X-Server (DIX) hardware-specific 2D drivers can work in parallel to OpenGL DRI/Mesa by directly interfacing with DRM, since it allows multiple direct rendering clients exactly for cases like this one.

    BTW the most recent development is project Glamor, which seeks to eliminate these hardware-specific 2D drivers by re-implementing X-Server rendering pipeline on top of OpenGL.
    http://en.wikipedia.org/wiki/File:The_Linux_Graphics_Stack_and_glamor.svg

    Make the arrow that points from "Proprietary OpenGL driver" to "proprietary blob" end on "libDRM" instead.

    LibGL is the export module which Linux OpenGL applications should link against, like OpenGL32.dll on Windows.

    It can be either proprietary OpenGL driver or a Mesa-based open-source DRI OpenGL driver, or maybe even proprietary DRI OpenGL driver (which would be the refactored Catalyst once they get it done), but only one of them will be configured to load.
     
    #54 DmitryKo, May 20, 2014
    Last edited by a moderator: May 20, 2014
  15. madyasiwi

    Newcomer

    Joined:
    Oct 7, 2008
    Messages:
    194
    Likes Received:
    32
    One could argue that direct state access and bindless -- among others -- simplify the API by bypassing the driver or existing OpenGL specs in one way or another. At least, they are the precursor of low CPU overhead, straight to the metal APIs that we know today.

    Saying providing backward compatibility is not an industry-friendly behavior is questionable at best. If NVidia cut their support to those CAD developers, one of their competitors would be more than happy to fill their shoes. Surely someone could learn something about how Intel screwed with their "build from the scratch" IA64 and left the industry fall into the grip of its competitor with theoretically inferior but backward compatible alternative?

    Professional software has different life cycle than games, they may have new version released each year, but the graphics engine usually barely changed.

    Something I have to agree...

    Well I would expect it to be totally different. One tested using limited use case, artificial loads, contextually vague metrics done in mere man hours in total while the other is actually involved in porting real product and building alternative gaming platform for PC for months, interacting directly with engineers of respective hardware companies.

    Reviews are only useful for those who are completely have no idea. Those who knows what they need does not rely on them -- at least primarily -- to make their decision.
     
  16. Davros

    Legend

    Joined:
    Jun 7, 2004
    Messages:
    14,899
    Likes Received:
    2,311
    I would certainly switch ihv if they dropped backwards compatibility
     
  17. silent_guy

    Veteran Subscriber

    Joined:
    Mar 7, 2006
    Messages:
    3,754
    Likes Received:
    1,379
    The way I read it, they actively oppose screwing over their existing customers. :wink:

    In link provided, all they say is "we will make sure that old applications will keep on working". They don't say anywhere that they oppose simplifying the API. Quite on the contrary, they say explicitly that deprecated functions will be removed from the core API.

    I don't see how refusing to delete code that has already been written anyway is considered an explicit admission that they reject change.
     
  18. OpenGL guy

    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    2,357
    Likes Received:
    28
    That's not what Andrew means. By recommending that developers *always* use the compatibility profile, it means that applications will *always* have a dependence on the older OpenGL APIs, which is what other vendors might what to break away from. Of course old applications will continue to work, that has nothing to do with new applications dropping the compatibility profile. Here's a quote from Nvidia:
    So the push is for developers to use existing, legacy code instead of fixing the code to use the "core" features.
     
  19. Andrew Lauritzen

    Moderator Veteran

    Joined:
    May 21, 2004
    Messages:
    2,526
    Likes Received:
    454
    Location:
    British Columbia, Canada
    Indeed, but I'm talking specifically about games/game engines here. I'm totally fine with them branching off a version of GL for CAD forks or whatever but encouraging modern games to keep making use of legacy features in new code is pure vendor lock-in.

    Perhaps you missed this bit:
    "NVIDIA recommends that developers always create a Compatibility profile context, to ensure full backwards compatibility of existing OpenGL code."
    Edit: OpenGL Guy beat me to it ;)

    That's a nonsense recommendation for new code. And frankly even continuing to bolt on new features to compatibility profiles is making the problem worse in the long term. Obviously every still needs to support legacy stuff in their drivers... ex. DX7/8/9 stuff still works on modern hardware. But we're not trying to make compute shaders work with DX7 for good reason.
     
  20. silent_guy

    Veteran Subscriber

    Joined:
    Mar 7, 2006
    Messages:
    3,754
    Likes Received:
    1,379
    Fair enough. The way I read that was that you should define compatibility mode for *existing code*. Because, well, that's what it says. :wink:

    I don't see any recommendation says hat you should use compatibility mode for new code.
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...