Announcement

Collapse
No announcement yet.

Microsoft Eyeing OpenGL Compute + GLES 3.1 For Its Mesa D3D12 Backend

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Quackdoc
    replied
    Originally posted by darkdragon-001 View Post
    A "Vulkan Driver" could then be AMDVLK for example, right?

    Everything you mentioned lives in the mesa code base, right?

    So when an application like a game or a window manager interfaces with the Vulkan API directly, Gallium3D is not needed at all?
    This is all correct. zink returns generic vulkan calls, so any device that has a working vulkan driver should work, even proprietary ones like nvidia.

    Would it be possible to implement a Vulkan state tracker to run any Vulkan application on a D3D12 driver then?
    while this is correct, it wouldn't be the most performant, but it would do the job for getting vulkan support on d3d12, there is already dozen driver which is a WIP Vulkan over d3d12. but it is still at a proof of concept stage, I don't think it can even run vkcube yet without modification. I'm not sure if it uses gallium or not, but I think it does.

    Leave a comment:


  • darkdragon-001
    replied
    Originally posted by Quackdoc View Post

    Gallium is based on three layers,

    The driver, IE RadeonSI, ZInk, Iris
    Galliums API
    And the state tracker, IE. OpenGL, Gallium nine etc.

    The state tracker is what provieds OpenGL support. it is the "front end" so to speak, so a rendering path would look like this

    State Tracker -> G3D -> Driver -> Hardware
    OR
    OGL -> G3D -> Radeon SI -> Hardware.

    For both zink and D3D12 it looks like this

    OGL -> G3D -> Vulkan -> Vulkan Driver -> Hardware
    OGL -> G3D -> D3D12 -> D3D12 Driver -> Hardware

    Thanks a lot for the clarification!

    A "Vulkan Driver" could then be AMDVLK for example, right?

    Everything you mentioned lives in the mesa code base, right?

    So when an application like a game or a window manager interfaces with the Vulkan API directly, Gallium3D is not needed at all?

    Would it be possible to implement a Vulkan state tracker to run any Vulkan application on a D3D12 driver then?

    Leave a comment:


  • Birkett83
    replied
    Originally posted by Quackdoc View Post

    you missed the point completely. the point is that they are working on a d3d12 driver instead of an open driver like vulkan.

    they could use zink to do that, zink would be better suited for the task, as it has a larger userbase, and thus more devs potentially working on it. d3d12 backend is NOT about windows getting better opengl support, its about microsoft being able to use their GPL Shim in virtual machines.

    that is what we are talking about, not that people should abandon OGL for vulkan
    The GPL shim you're talking about, are you referring to the DXGKRNL driver microsoft have written and have attempted to upstream into the linux kernel? ( https://www.phoronix.com/scan.php?pa...-Uphill-Battle ) - I don't think the kernel maintainers will accept it, since there's no open source d3dx12 library for linux that would use the driver. I wholeheartedly support the kernel maintainers in not wanting a driver that isn't fully open source in their kernel.

    Regarding microsoft's new open source OpenGL implementation that uses a d3dx12 backend, either on windows or on linux (using microsoft's out-of-tree dxgkrnl driver) or - how could that be a bad thing for the open source community? It allows people who want to run WSL2 to run OpenGL apps, so more people can use open source stuff in more places (that's good!) and doesn't lock anyone into the microsoft ecosystem. It seems to me the real threat is microsoft providing the d3dx12.so for developers to port dx12 apps to linux, since those apps would only be able to run on WSL2 or hyperV, not on native linux kernels.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by darkdragon-001 View Post

    Sorry, but I still don't get it...

    My understanding is the following:

    Zink translates from Vulkan->OpenGL
    Microsoft's new thing translates from D3D12->OpenGL
    AMDVLK translates from AMD-API->Vulkan
    Gallium3D translates from Hardware-API->OpenGL

    What is wrong with it?
    I honestly can't figure out what you think G3D is, so ill just explain it entirely.

    Gallium is based on three layers,

    The driver, IE RadeonSI, ZInk, Iris
    Galliums API
    And the state tracker, IE. OpenGL, Gallium nine etc.

    The state tracker is what provieds OpenGL support. it is the "front end" so to speak, so a rendering path would look like this

    State Tracker -> G3D -> Driver -> Hardware
    OR
    OGL -> G3D -> Radeon SI -> Hardware.

    For both zink and D3D12 it looks like this

    OGL -> G3D -> Vulkan -> Vulkan Driver -> Hardware
    OGL -> G3D -> D3D12 -> D3D12 Driver -> Hardware

    Leave a comment:


  • darkdragon-001
    replied
    Originally posted by Quackdoc View Post

    zink IS a vulkan driver d3d12 IS a d3d12 driver, NOT a OGL specific thing.
    Sorry, but I still don't get it...

    My understanding is the following:

    Zink translates from Vulkan->OpenGL
    Microsoft's new thing translates from D3D12->OpenGL
    AMDVLK translates from AMD-API->Vulkan
    Gallium3D translates from Hardware-API->OpenGL

    What is wrong with it?

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by Birkett83 View Post
    Providing better OpenGL support on windows should make it easier to port existing software written in OpenGL to windows and make it easier for developers who might otherwise choose to target direct X to go with the more portable OpenGL instead.

    For the cynical among you, feel free to object that OpenGL is a legacy API at this point and anything new ought to target vulcan instead, so developers wanting the features of a modern API will still have to choose dx12 on windows... But complaining that an MIT-licenced OpenGL implementation on windows is in itself bad for the future of open source software is just silly.
    you missed the point completely. the point is that they are working on a d3d12 driver instead of an open driver like vulkan.

    they could use zink to do that, zink would be better suited for the task, as it has a larger userbase, and thus more devs potentially working on it. d3d12 backend is NOT about windows getting better opengl support, its about microsoft being able to use their GPL Shim in virtual machines.

    that is what we are talking about, not that people should abandon OGL for vulkan

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by darkdragon-001 View Post
    How is mesa structured internally? Shouldn't it be possible to provide a D3D12 backend alongside a Vulkan one and e.g. use Zink as an OpenGL frontend for both?
    zink IS a vulkan driver d3d12 IS a d3d12 driver, NOT a OGL specific thing.

    Leave a comment:


  • darkdragon-001
    replied
    How is mesa structured internally? Shouldn't it be possible to provide a D3D12 backend alongside a Vulkan one and e.g. use Zink as an OpenGL frontend for both?

    Leave a comment:


  • Birkett83
    replied
    Providing better OpenGL support on windows should make it easier to port existing software written in OpenGL to windows and make it easier for developers who might otherwise choose to target direct X to go with the more portable OpenGL instead.

    For the cynical among you, feel free to object that OpenGL is a legacy API at this point and anything new ought to target vulcan instead, so developers wanting the features of a modern API will still have to choose dx12 on windows... But complaining that an MIT-licenced OpenGL implementation on windows is in itself bad for the future of open source software is just silly.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by MadeUpName View Post
    Isn't this a job for Vulkan?
    That would require microsoft to do something that doesn't solely benefit them to lock users to their platform.

    Leave a comment:

Working...
X