Graf Zahl wrote:For the record - it was the clip planes, not the stencil buffer, that were broken. And they were so broken that just enabling them made the driver lose it.
Ah, my mistake, sorry.
Graf Zahl wrote:For the record - it was the clip planes, not the stencil buffer, that were broken. And they were so broken that just enabling them made the driver lose it.
Rachael wrote:OpenGL simply isn't it for AMD,
That isn't very likely to happen in any case since id Software will continue to run as an independent studio. Minecraft still uses OpenGL as you stated and there's actually an ANGLE implementation that wraps OpenGL ES behind a Direct3D backend which is available for use in Windows UWP. And more and more games are using Vulkan as it is becoming more cross-platform; there's already a Vulkan-to-D3D12 wrapper and Vulkan is already running on the Switch.(Random aside: wonder if the Microsoft buy out will change id's long history of using OpenGL/Vulkan.)
Graf Zahl wrote:What I don't understand here is why Zink is being developed as part of a driver and not as a standalone drop-in library that can be used anywhere. This will inevitably limit its usefulness to the point where potential customers may just skip over it.
Blzut3 wrote:Granted I would personally think it would be more useful as a system wide installation instead of relying on every piece of software shipping Zink. But I don't see any reason that it couldn't be provided by the application.
Graf Zahl wrote:Think Windows, not Linux. On windows it's not SOP to install dependencies, they are normally shipped with the application.
Graf Zahl wrote:Think Windows, not Linux. On windows it's not SOP to install dependencies, they are normally shipped with the application.
Cacodemon345 wrote:It should not be impossible to build Mesa3D's Zink as a layer over Vulkan for Windows since it already can be built as a software OpenGL renderer library for that platform.
Blzut3 wrote:There is probably room for debate on if a high level API is even needed. My suspicion is that the reason we haven't heard much from people trying to make a new high level API (there was lot of talk about this when Vulkan first launched) is because Vulkan/DX12/Metal have become less scary as time goes on, combined with many previous instances of needing to write custom rendering code being replaced with ever more generic, low cost game engines. For people doing hobby programming to turn into a profession later on, it doesn't make a whole lot of sense to invest into learning a high level API when you'll be needed to use a low level one on the job. Certainly would be nice to have a lower barrier to entry, but is OpenGL really the right tool for that?
Blzut3 wrote:Perhaps an even better question to ask would be with DXVK making D3D11 cross platform, is OpenGL a better tool than D3D11 for the job?
Graf Zahl wrote:I think you missed the potential customer base by a wide margin. I'M thinking more of professional software that needs to do a bit of 3D rendering without worrying too much about performance. In such environments productivity matters - and one thing Vulkan surely is not and never will be is being conductive to productivity. When writing such software I do not care about having to transition texture images or synchronize all actions or suffer obtuse crashes, and so on.
Graf Zahl wrote:Of these two APIs, D3D11 is far and away the better one, but this DXVK project looks like another one of those failures-by-design which is limiting itself to an unattractive scope, being solely meant for use with Wine.
Blzut3 wrote:Ah, if I recall correctly AMD made V-EZ to try to target this use case, but must have had no demand since they seemingly dropped it soon after announcing it.
Blzut3 wrote:I'm not sure what the status on the effort is but there is a DXVK-Native project which allows building dxvk as a Linux shared object. Intention last I heard is to upstream the changes. Supposedly wine developers are interested in moving the translation out to native. Not entirely sure why they would care though.
In any case I expect that there will be enough "ick Microsoft" reaction to the idea of using D3D11 in native Linux code that adoption as a cross platform high level graphics API will be poor regardless.
Users browsing this forum: No registered users and 1 guest