Originally posted by darkdragon-001
View Post
Microsoft Eyeing OpenGL Compute + GLES 3.1 For Its Mesa D3D12 Backend
Collapse
X
-
Originally posted by Birkett83 View PostProviding 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.
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
Comment
-
-
Originally posted by Quackdoc View Post
zink IS a vulkan driver d3d12 IS a d3d12 driver, NOT a OGL specific thing.
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?
Comment
-
-
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?
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
Comment
-
-
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
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.
Comment
-
-
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?
Comment
-
-
Originally posted by darkdragon-001 View PostA "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?
Comment
-
Comment