Ok I can see you take exception to it being harder than OpenGL and your limited use-cases will not benefit from Vulkan, but that is ok. We won't all be limited just because you are. The key problems with OpenGL are resolved with Vulkan:
-The implementation requires that application-specific optimizations be in the driver, this is wrong. Application code belongs in the application, not in the driver.
-OpenGL is inherently serial which limits the ability to exploit multi-core CPUs, whether this be unnecessary patterns that require multiple threads submitting work to a single draw thread or cases - such as mobile - where you have low single-core performance. You may not have this in your limited experience but many of us deal with applications that extend beyond the capacity of a CPU single core.
-The added flexibility gives us more control to exploit multi-GPU systems, again you might not need that but that's ok.
Now you can say you don't have these problems so therefore you don't need the added complexity, that's fine. You can use a higher level toolkit like the Visualization Toolkit for example or an engine like Unity or Unreal Engine or better yet you could use an OpenGL-like higher level API that sits atop Vulkan which could be easier to use at the cost of efficiency and flexibility. You can even continue developing in OpenGL because it will still exist for a long time to come and even when the major vendors stop supporting it there are plenty of open source driver implementations and even software implementations if you are so inclined.
But looking at what has been released wtf should I be tracking the internal state of the GPU in application code?
Because when you're working asynchronously you need to know when operations are complete. Is that really the basis for your criticisms of the API?
BOOM! here is the admission from you that Vulkan has already failed as a replacement for the ***application-level*** OpenGL. Instead of a three-tier system (hardware, driver, application [OpenGL]) your architecture moves to four-tier (hardware, driver, Vulkan, framework) because of the *crappy API design* of Vulkan.
No, with OpenGL we end up with application code in the driver, which is wrong, application-specific code does not belong in the driver. Vulkan fixes that which means for high performance applications Vulkan will be hugely beneficial and for those of you who don't need high performance you can go with one of the many options I already listed for you.
Ok it is quite clear you don't know anything about Vulkan hence your inability to give any specifics on what you think is wrong with it. Not a conceptual level, when I say specific I mean specific about the API. You can't do that because you don't know anything about it, you're ranting about your own misinterpretation. So try again to be specific.
Sorry, the economics of Vulkan are not favorable for me - because the *design* of the API is horrible
Cite the specific design aspects. What parts of the API design are "horrible"? If you know what you're talking about this should be very easy.
Obviously what you need is a higher level API, which can be built atop Vulkan, DirectX, Metal and/or Mantle and that will solve your problem, it will be far less efficient but it will be easy and you won't be holding everybody else back. That's your problem solved.
Ok, so our (friendly) debate is simply about which has the greater priority: ease-of-use, verses to-the-metal performance. Yes? we are simply debating which is more important.
Well not really, I'm not really interested in a conceptual debate. If you could have a high performance, easy to use API then sure that would be great, so what I am trying to understand is what your specific grievances are wrt APIs like Vulkan, Mantle, Metal and DX12. Naturally somebody who has done years of OpenGL without understanding what exactly it is abstracting is going to find Vulkan difficult but that is simply because your view of how 3D graphics pipelines work is limited to what you see in the API, meanwhile the hardware that is being abstracted has changed so much that your view is completely wrong now and the API is horribly inefficient because the OpenGL machine description isn't representative of modern hardware.
So my questions for you, which need to be addressed before I can answer your more specific questions
It's a bit intellectually dishonest to suggest you cannot answer my questions without me first answering these. Clearly mine are very specific and don't need answers to your questions to be able to answer them.
I don't know if you are a Khronos member who has an emotional interest in this - so my apologies if I have offended you, because I appreciate the great work those guys are doing - and how they are moving OpenGL forward.
No, I am not.
All I'm saying is the success of an API has a lower weighting on raw performance and a greater weighting on ease-of-use and *longevity* (the latter being OpenGL's strength).
The problem that you seem to want to ignore - because learning something new is too hard - is that OpenGL is a mess of antiquated cruft that is no longer representative of the underlying hardware. I get it, those set in their ways will struggle but we can't hold back the hardware architecture with an inefficient abstraction just because some people are aversed to change.
I'm just trying to get an honest opinion through to you - because you don't seem to understand what *users* are looking for in an API. Thanks for giving some of your precious time to this debate.
Well tell me then, what specifically is wrong with Vulkan compared to OpenGL?
Double-handling is bad. However, the most modern programming languages are multi-threaded and you can't just give application memory to hardware without a rigmarole of pinning memory (to stop a garbage collector from moving memory around during compaction - which is fine with applications but not to give to hardware).
You don't give application memory to hardware, you allocate GPU memory for use in your application. Why do you think you will have problems with Vulkan in terms of multi-threading?
I have never, ever seen GL_OUT_OF_MEMORY, and I've been doing this a long time.
Oh well it mustn't be a problem then, of course that's only one example. I'm hardly going to enumerate them in the hopes I find one you've hit upon.
The current OpenGL drivers are very good at managing memory, far better than most application developers. Pushing driver-level memory management to application developers is a design failure, AFAICS, as I will comment on below.
But it isn't driver-level memory management, as I already said it is about having the driver do less and that does not necessarily mean the application developer has to do more. Some more, but not a whole lot.
It *is* about the application developer do more. That is the upshot of the API changes.
But what you are not understanding is that this is not about the application developer taking on the responsibilities of the driver writer. Specifically why do you think this is the case?
Consider what it is like for people coming to OpenGL for the first time - the number of concepts that must be acquired to load a shader and render a simple 3D line or bitmap is horrendous and FAR greater than earlier OpenGL versions.
It isn't about it being easy, it is about doing it properly. An abstraction is supposed to be representative of the thing it is abstracting, OpenGL in its current state absolutely is not. Your beef is with the hardware developers, not Khronos and your advocating for it to be easy rather than effective which is a poor attitude.
This is the same argument for working in assembly.
No it absolutely is not. Your argument is that the abstraction should not be representative of the underlying hardware simply because it is too hard, that is just a cop out.
Furthermore, you end up doing exactly what OpenGL was designed to avoid - writing lots of code paths for different GPU classes.
Please provide an example. If you indeed to think this then you do not understand this at all. I suggest you go and read up on this rather than making baseless assertions.
The ENTIRE POINT of OpenGL is to have the driver act as a hardware abstraction, and the driver writer (who is an expert in the hardware) can write optimizations so that the hundreds of thousands of application developers using OpenGL don't have to.
And OpenGL is most definitely NOT an abstraction of modern hardware, the driver writer still indeed does write the hardware specific code which is precisely what a driver is.
There are existing mechanisms to indicate when a buffer is no longer needed at the application level.
Yes, poor inefficient mechanisms which leads to application-specific optimizations in drivers that become monolithic blobs.
Then the OpenGL driver decides when it is best to reclaim the memory.
And it very often gets it wrong, which is why we have so many application-specific optimizations in the drivers, this is the wrong way to do it. I would be happy to hear your arguments as to how to resolve this with the current OpenGL incarnation though?
Again, in order to save a little bit of driver effort on last-generation hardware it means that hundreds of thousands of application developers now ha
Actually, most of the games which have used GameWorks to date have been multi-platform games.
Yes but that's only for completely non-essential things, you can't use it for anything you absolutely must have. If AMD provided something akin to GameWorks (TressFX is coming along slowly, and was even used in Tomb Raider) then developers will use that to improve the visual fidelity on AMD GPUs (including consoles).
Yes that's pretty much correct, nVidia provides extra, easy-to-use tools to exploit their hardware so some developers will invest some time in them. But that's obviously only for extra non-essential things.
Well yes, but of course Windows, OS X & GNU/Linux are all, generally speaking, the PC platform as you can very often run 2 or more of those operating systems on the same hardware. This is not true of iOS, Android or the console operating systems.
IMHO this is also a mistake. Having the application developer do driver-level resource management is a fail, IMHO.
Why exactly? Take glUniform calls for example, having the driver create its own buffer to copy that data into and then transfer that to the GPU memory is far less efficient than having the application map to the GPU directly.
I like APIs that operate on two levels: one level is the low-level stuff, where you are required to make every decision (Vulkan); then you have another part of the *same* API that has convenience methods for very common things that nearly every application needs (as OpenGL does).
The black box of the driver means that when you allocate memory on the GPU you don't know how much it is using, worse still if it fails and you get an GL_OUT_OF_MEMORY error, which could mean a few different things. Do you have no system or GPU memory left? How much do you need to free up? Instead of that you allocate the memory rather than telling the driver to do it, you already specify pretty much all the parameters when you do it in OpenGL anyway.
Pushing more work to the application developer just so the driver developer can do less is a fail and will result in lower adoption.
It's not about having the application developer do more, it's about having the driver do less and more closely mapping the application's resource usage to the GPU instead of the driver acting as an intermediate layer. You know how long you need memory for so why allow the driver to make assumptions about it?
Consider the case for new developers who want to use all the convenience methods of OpenGL 1 and 2, but these were stripped out in OpenGL 4 for the benefit of driver writers.
Maintaining useless, inefficient cruft that complicates the API is a burden on maintainers and those wishing to learn, why have a multitude of ways to do the same thing? That's just a mess.
Sure that's true for PC exclusives but you do have to remember that a lot of games these days target multiple platforms and if you're targeting the major consoles then any nVidia-specific tools/libraries are not an option.
I certainly do think Metal is a poor solution (being platform-specific, proprietary and not as comprehensive as Vulkan - based on knowledge of Mantle), especially when we have Khronos trying to unify the 3D graphics world and the lagging of OpenGL in comparison to Metal and DirectX will be addressed with Vulkan.
With AMD opening up the GPU it means the OpenGL driver writers can squeeze more performance out, without the application developer having to do the low-level work. This is the model I personally prefer.
The problem here is the OpenGL driver model, ultimately the real performance gains are around application-specific changes to the behavior of the driver - specifically resource management - so you end up with a monolithic driver that has a lot of application-specific code in it. Vulkan alleviates this by putting this in the hands of the application developer rather than having to rely on the driver.
I hope Apple also make good use of this, the Apple OpenGL drivers run at about half the speed of AMD's Windows OpenGL drivers on the same hardware (a recent Mac Pro with dual D700s under OS X and Bootcamp-ed to Windows).
Apple have Metal, they aren't interested in OpenGL, hence the reason their drivers are so far behind.
This is great news for those working in real time 3D.
It's great if you're targeting a narrow hardware range because you can now optimize specifically for it but we've had this at the vendor level before (S3, 3Dfx, nVidia, ATi, PowerVR, Matrox, 3DLabs, etc.) and it was a nightmare. Even if the application supported your card that didn't mean it supported it particularly well, or as well as other cards. So picking a graphics card was less about how powerful the card was and more about how popular it was with developers.
Another thing about this "open" concept that nobody is really talking about amidst the cheerleading: AMD is trying to push *proprietary* AMD-only hardware features that don't fit very well with current APIs -- and that includes Vulkan, BTW, not just the old APIs.
Seems like you're thinking of Mantle (which is of course the basis for the Vulkan work) but Vulkan - like OpenGL - will be an open specification, not proprietary.
The idea is not to fit with current APIs because current API paradigms are not well suited to modern hardware. For example a lot of the workload is serial and so cannot leverage any significant amount of the available CPU power, Vulkan (and DirectX 12) change this and allow multiple threads to do things like create and submit command buffers in parallel. Another part of it is that the resource management of the current high-level APIs is just an abstraction of the generic driver implementation so we see performance gains when the power of the hardware is exploited through explicit application-specific optimizations made in the driver by the vendor working with the game developer. Vulkan and DirectX 12 break from this by transferring the onus of low level resource management to the game developer so they can fully utilize the hardware in the way they need without being hamstrung by the driver.
And, as I said, https://github.com/torvalds/li... is a perfectly acceptable location for the kernel source. If you respond to their written offer and they point you there then that is perfectly fine.
Are you talking about the XBox when you claim: "Why make a half-assed version for a niche platform that can't support proper graphics?"?
No, this article is about Linux graphics drivers and that while they have gotten better for brand new hardware they have gotten a lot worse for older hardware.
Here's the reason why: there's money on the table.
But there isn't, because the target is a niche.
There's an advantage too to writing multiplatform, as any programmer knows: if it works on several systems, its less likely to have crashing bugs and to work better.
Umm...no, there's no factual basis to support such a thing.
It even makes QC easier, since you don't necessarily have to test every permutation of game progress, since the differences in game play on different OSes can exercise different path orders
How does that result in less burden on QC? You still have to test everything and you have to test it on every target platform.
especially useful in a multithreaded program, where nondeterministic code paths is a serious cause for bad bugs in software.
And since every platform has different methods for handling multiple threads that increases the burden on QC. Just because it works on one platform doesn't mean it will work on every platform.
Because of the community you get specialized version of drivers that remove unneeded checks for specific applications. This isn't possible with Windows drivers as they are usually not open source. It all comes down to the open source nature of Linux and it's distributions.
You're talking about open source rather than Linux. A great deal - the majority actually - of the hardware drivers for Linux are in fact closed source.
They could target Forza at other or multiple platforms and still have "full" physics.
Why make a half-assed version for a niche platform that can't support proper graphics? Having a high resolution visual experience isn't some "status symbol" it is being able to express the vision of the art designer and to create an immersive experience for the gamer. Previously we had to expend considerable effort to scale down assets and remove detail because of hardware constraints, now the hardware is powerful enough that we waste much less time compromising the art design.
The physics calculations shouldn't be "lost" on other platforms, even if some graphics are, unless perhaps they are using the GPU for physics also?
Very often the GPU is used for physics calculations.
Human "apes" are drawn to the big shiny red ball, as usual. And fancy graphics are a status symbol: keeping up with the Jones'.
I think your problem is your inability to see anything beyond the "big shiny red ball". Go play tuxracer if you want but the latest Forza, for example, offers a *lot* more than just realistic graphics, now of course as an "ape" you can't see that can you? You're too distracted by the "shiny" to notice everything else. If you're going to try to create a realistic experience with physics, sound and AI then why would you not do the same with graphics?
In what cases is it "tailored to squeeze every ounce of power out of it's hardware"?
...an any case where the admin/owner decides to take a trip through make config , in extreme cases literally tear out unused bits of kernel from source (then recompile), or on a lesser scale, tweak up/etc/sysctl.
Not really, that might reduce the footprint a bit but it's a far cry from tailoring it to "squeeze every ounce of power out of it's hardware". I doubt many - if any - people actually do much outside of what you specified. The real hardware-specific performance gains are going to be achieved with good hardware drivers, not just omitting things from the kernel.
But there are distros of Linux, like Gentoo...where you can install it and custom compile your kernel, etc...for the hardware it is running on.
Yes that is what I said, if you make a custom version of software to target specific hardware you're more than likely to get better performance than software that targets a range of hardware. But in reality the investment in the hardware driver is going to provide far more value than modifying the kernel.
If for nothing else, this is nice for squeezing out the most of your older hardware you might be wanting to run things on rather than toss it in the trash.
Yet as this article demonstrates, the open source drivers for older hardware often regress into an unworkable state, obviously the time spent on making this older hardware work is not worth the effort.
Linux has much less overhead and is often tailored to squeeze every ounce of power out of it's hardware.
In what cases is it "tailored to squeeze every ounce of power out of it's hardware"? In its most common form (Android, Debian/Slackware/RedHat-based desktop and server distributions) it is about wide hardware compatibility. Even most embedded are just the stable kernel tree.
Linux if built for specific hardware can achieve much better performance than Windows in it's current state.
That's true of anything. If you make a special version of software that targets specific hardware it is most likely going to run better than software that targets a whole range of hardware.
Slashdot Mirror
But if a dev isn't yet eligible to target consoles, it's more likely to get suckered into this crap.
If a dev isn't eligible to target consoles then they aren't targeting consoles are they? (yes, that is a rhetorical question)
Ok I can see you take exception to it being harder than OpenGL and your limited use-cases will not benefit from Vulkan, but that is ok. We won't all be limited just because you are. The key problems with OpenGL are resolved with Vulkan:
-The implementation requires that application-specific optimizations be in the driver, this is wrong. Application code belongs in the application, not in the driver.
-OpenGL is inherently serial which limits the ability to exploit multi-core CPUs, whether this be unnecessary patterns that require multiple threads submitting work to a single draw thread or cases - such as mobile - where you have low single-core performance. You may not have this in your limited experience but many of us deal with applications that extend beyond the capacity of a CPU single core.
-The added flexibility gives us more control to exploit multi-GPU systems, again you might not need that but that's ok.
Now you can say you don't have these problems so therefore you don't need the added complexity, that's fine. You can use a higher level toolkit like the Visualization Toolkit for example or an engine like Unity or Unreal Engine or better yet you could use an OpenGL-like higher level API that sits atop Vulkan which could be easier to use at the cost of efficiency and flexibility. You can even continue developing in OpenGL because it will still exist for a long time to come and even when the major vendors stop supporting it there are plenty of open source driver implementations and even software implementations if you are so inclined.
But looking at what has been released wtf should I be tracking the internal state of the GPU in application code?
Because when you're working asynchronously you need to know when operations are complete. Is that really the basis for your criticisms of the API?
BOOM! here is the admission from you that Vulkan has already failed as a replacement for the ***application-level*** OpenGL. Instead of a three-tier system (hardware, driver, application [OpenGL]) your architecture moves to four-tier (hardware, driver, Vulkan, framework) because of the *crappy API design* of Vulkan.
No, with OpenGL we end up with application code in the driver, which is wrong, application-specific code does not belong in the driver. Vulkan fixes that which means for high performance applications Vulkan will be hugely beneficial and for those of you who don't need high performance you can go with one of the many options I already listed for you.
Ok it is quite clear you don't know anything about Vulkan hence your inability to give any specifics on what you think is wrong with it. Not a conceptual level, when I say specific I mean specific about the API. You can't do that because you don't know anything about it, you're ranting about your own misinterpretation. So try again to be specific.
Sorry, the economics of Vulkan are not favorable for me - because the *design* of the API is horrible
Cite the specific design aspects. What parts of the API design are "horrible"? If you know what you're talking about this should be very easy.
Obviously what you need is a higher level API, which can be built atop Vulkan, DirectX, Metal and/or Mantle and that will solve your problem, it will be far less efficient but it will be easy and you won't be holding everybody else back. That's your problem solved.
I get that you're trying desperately hard to be pedantic but how does any of that affect what I said?
Ok, so our (friendly) debate is simply about which has the greater priority: ease-of-use, verses to-the-metal performance. Yes? we are simply debating which is more important.
Well not really, I'm not really interested in a conceptual debate. If you could have a high performance, easy to use API then sure that would be great, so what I am trying to understand is what your specific grievances are wrt APIs like Vulkan, Mantle, Metal and DX12. Naturally somebody who has done years of OpenGL without understanding what exactly it is abstracting is going to find Vulkan difficult but that is simply because your view of how 3D graphics pipelines work is limited to what you see in the API, meanwhile the hardware that is being abstracted has changed so much that your view is completely wrong now and the API is horribly inefficient because the OpenGL machine description isn't representative of modern hardware.
So my questions for you, which need to be addressed before I can answer your more specific questions
It's a bit intellectually dishonest to suggest you cannot answer my questions without me first answering these. Clearly mine are very specific and don't need answers to your questions to be able to answer them.
I don't know if you are a Khronos member who has an emotional interest in this - so my apologies if I have offended you, because I appreciate the great work those guys are doing - and how they are moving OpenGL forward.
No, I am not.
All I'm saying is the success of an API has a lower weighting on raw performance and a greater weighting on ease-of-use and *longevity* (the latter being OpenGL's strength).
The problem that you seem to want to ignore - because learning something new is too hard - is that OpenGL is a mess of antiquated cruft that is no longer representative of the underlying hardware. I get it, those set in their ways will struggle but we can't hold back the hardware architecture with an inefficient abstraction just because some people are aversed to change.
I'm just trying to get an honest opinion through to you - because you don't seem to understand what *users* are looking for in an API. Thanks for giving some of your precious time to this debate.
Well tell me then, what specifically is wrong with Vulkan compared to OpenGL?
Double-handling is bad. However, the most modern programming languages are multi-threaded and you can't just give application memory to hardware without a rigmarole of pinning memory (to stop a garbage collector from moving memory around during compaction - which is fine with applications but not to give to hardware).
You don't give application memory to hardware, you allocate GPU memory for use in your application. Why do you think you will have problems with Vulkan in terms of multi-threading?
I have never, ever seen GL_OUT_OF_MEMORY, and I've been doing this a long time.
Oh well it mustn't be a problem then, of course that's only one example. I'm hardly going to enumerate them in the hopes I find one you've hit upon.
The current OpenGL drivers are very good at managing memory, far better than most application developers. Pushing driver-level memory management to application developers is a design failure, AFAICS, as I will comment on below.
But it isn't driver-level memory management, as I already said it is about having the driver do less and that does not necessarily mean the application developer has to do more. Some more, but not a whole lot.
It *is* about the application developer do more. That is the upshot of the API changes.
But what you are not understanding is that this is not about the application developer taking on the responsibilities of the driver writer. Specifically why do you think this is the case?
Consider what it is like for people coming to OpenGL for the first time - the number of concepts that must be acquired to load a shader and render a simple 3D line or bitmap is horrendous and FAR greater than earlier OpenGL versions.
It isn't about it being easy, it is about doing it properly. An abstraction is supposed to be representative of the thing it is abstracting, OpenGL in its current state absolutely is not. Your beef is with the hardware developers, not Khronos and your advocating for it to be easy rather than effective which is a poor attitude.
This is the same argument for working in assembly.
No it absolutely is not. Your argument is that the abstraction should not be representative of the underlying hardware simply because it is too hard, that is just a cop out.
Furthermore, you end up doing exactly what OpenGL was designed to avoid - writing lots of code paths for different GPU classes.
Please provide an example. If you indeed to think this then you do not understand this at all. I suggest you go and read up on this rather than making baseless assertions.
The ENTIRE POINT of OpenGL is to have the driver act as a hardware abstraction, and the driver writer (who is an expert in the hardware) can write optimizations so that the hundreds of thousands of application developers using OpenGL don't have to.
And OpenGL is most definitely NOT an abstraction of modern hardware, the driver writer still indeed does write the hardware specific code which is precisely what a driver is.
There are existing mechanisms to indicate when a buffer is no longer needed at the application level.
Yes, poor inefficient mechanisms which leads to application-specific optimizations in drivers that become monolithic blobs.
Then the OpenGL driver decides when it is best to reclaim the memory.
And it very often gets it wrong, which is why we have so many application-specific optimizations in the drivers, this is the wrong way to do it. I would be happy to hear your arguments as to how to resolve this with the current OpenGL incarnation though?
Again, in order to save a little bit of driver effort on last-generation hardware it means that hundreds of thousands of application developers now ha
Actually, most of the games which have used GameWorks to date have been multi-platform games.
Yes but that's only for completely non-essential things, you can't use it for anything you absolutely must have. If AMD provided something akin to GameWorks (TressFX is coming along slowly, and was even used in Tomb Raider) then developers will use that to improve the visual fidelity on AMD GPUs (including consoles).
Yes that's pretty much correct, nVidia provides extra, easy-to-use tools to exploit their hardware so some developers will invest some time in them. But that's obviously only for extra non-essential things.
Well yes, but of course Windows, OS X & GNU/Linux are all, generally speaking, the PC platform as you can very often run 2 or more of those operating systems on the same hardware. This is not true of iOS, Android or the console operating systems.
IMHO this is also a mistake. Having the application developer do driver-level resource management is a fail, IMHO.
Why exactly? Take glUniform calls for example, having the driver create its own buffer to copy that data into and then transfer that to the GPU memory is far less efficient than having the application map to the GPU directly.
I like APIs that operate on two levels: one level is the low-level stuff, where you are required to make every decision (Vulkan); then you have another part of the *same* API that has convenience methods for very common things that nearly every application needs (as OpenGL does).
The black box of the driver means that when you allocate memory on the GPU you don't know how much it is using, worse still if it fails and you get an GL_OUT_OF_MEMORY error, which could mean a few different things. Do you have no system or GPU memory left? How much do you need to free up? Instead of that you allocate the memory rather than telling the driver to do it, you already specify pretty much all the parameters when you do it in OpenGL anyway.
Pushing more work to the application developer just so the driver developer can do less is a fail and will result in lower adoption.
It's not about having the application developer do more, it's about having the driver do less and more closely mapping the application's resource usage to the GPU instead of the driver acting as an intermediate layer. You know how long you need memory for so why allow the driver to make assumptions about it?
Consider the case for new developers who want to use all the convenience methods of OpenGL 1 and 2, but these were stripped out in OpenGL 4 for the benefit of driver writers.
Maintaining useless, inefficient cruft that complicates the API is a burden on maintainers and those wishing to learn, why have a multitude of ways to do the same thing? That's just a mess.
Sure that's true for PC exclusives but you do have to remember that a lot of games these days target multiple platforms and if you're targeting the major consoles then any nVidia-specific tools/libraries are not an option.
With AMD opening up the GPU it means the OpenGL driver writers can squeeze more performance out, without the application developer having to do the low-level work. This is the model I personally prefer.
The problem here is the OpenGL driver model, ultimately the real performance gains are around application-specific changes to the behavior of the driver - specifically resource management - so you end up with a monolithic driver that has a lot of application-specific code in it. Vulkan alleviates this by putting this in the hands of the application developer rather than having to rely on the driver.
I hope Apple also make good use of this, the Apple OpenGL drivers run at about half the speed of AMD's Windows OpenGL drivers on the same hardware (a recent Mac Pro with dual D700s under OS X and Bootcamp-ed to Windows).
Apple have Metal, they aren't interested in OpenGL, hence the reason their drivers are so far behind.
This is great news for those working in real time 3D.
It's great if you're targeting a narrow hardware range because you can now optimize specifically for it but we've had this at the vendor level before (S3, 3Dfx, nVidia, ATi, PowerVR, Matrox, 3DLabs, etc.) and it was a nightmare. Even if the application supported your card that didn't mean it supported it particularly well, or as well as other cards. So picking a graphics card was less about how powerful the card was and more about how popular it was with developers.
Another thing about this "open" concept that nobody is really talking about amidst the cheerleading: AMD is trying to push *proprietary* AMD-only hardware features that don't fit very well with current APIs -- and that includes Vulkan, BTW, not just the old APIs.
Seems like you're thinking of Mantle (which is of course the basis for the Vulkan work) but Vulkan - like OpenGL - will be an open specification, not proprietary.
The idea is not to fit with current APIs because current API paradigms are not well suited to modern hardware. For example a lot of the workload is serial and so cannot leverage any significant amount of the available CPU power, Vulkan (and DirectX 12) change this and allow multiple threads to do things like create and submit command buffers in parallel. Another part of it is that the resource management of the current high-level APIs is just an abstraction of the generic driver implementation so we see performance gains when the power of the hardware is exploited through explicit application-specific optimizations made in the driver by the vendor working with the game developer. Vulkan and DirectX 12 break from this by transferring the onus of low level resource management to the game developer so they can fully utilize the hardware in the way they need without being hamstrung by the driver.
And, as I said, https://github.com/torvalds/li... is a perfectly acceptable location for the kernel source. If you respond to their written offer and they point you there then that is perfectly fine.
How do you know?
Because they're both x86, so I just installed the same OS on both.
You have compiled them and/or have the buildchain to verify that the source code for both is the same?
That seems pretty moronic, I just used the same install media on both.
Are you talking about the XBox when you claim: "Why make a half-assed version for a niche platform that can't support proper graphics?"?
No, this article is about Linux graphics drivers and that while they have gotten better for brand new hardware they have gotten a lot worse for older hardware.
Here's the reason why: there's money on the table.
But there isn't, because the target is a niche.
There's an advantage too to writing multiplatform, as any programmer knows: if it works on several systems, its less likely to have crashing bugs and to work better.
Umm...no, there's no factual basis to support such a thing.
It even makes QC easier, since you don't necessarily have to test every permutation of game progress, since the differences in game play on different OSes can exercise different path orders
How does that result in less burden on QC? You still have to test everything and you have to test it on every target platform.
especially useful in a multithreaded program, where nondeterministic code paths is a serious cause for bad bugs in software.
And since every platform has different methods for handling multiple threads that increases the burden on QC. Just because it works on one platform doesn't mean it will work on every platform.
If your desktop runs ARM then maybe, but I doubt it.
Most Windows-based tablets are x86, not ARM.
Because of the community you get specialized version of drivers that remove unneeded checks for specific applications. This isn't possible with Windows drivers as they are usually not open source. It all comes down to the open source nature of Linux and it's distributions.
You're talking about open source rather than Linux. A great deal - the majority actually - of the hardware drivers for Linux are in fact closed source.
They could target Forza at other or multiple platforms and still have "full" physics.
Why make a half-assed version for a niche platform that can't support proper graphics? Having a high resolution visual experience isn't some "status symbol" it is being able to express the vision of the art designer and to create an immersive experience for the gamer. Previously we had to expend considerable effort to scale down assets and remove detail because of hardware constraints, now the hardware is powerful enough that we waste much less time compromising the art design.
The physics calculations shouldn't be "lost" on other platforms, even if some graphics are, unless perhaps they are using the GPU for physics also?
Very often the GPU is used for physics calculations.
Human "apes" are drawn to the big shiny red ball, as usual. And fancy graphics are a status symbol: keeping up with the Jones'.
I think your problem is your inability to see anything beyond the "big shiny red ball". Go play tuxracer if you want but the latest Forza, for example, offers a *lot* more than just realistic graphics, now of course as an "ape" you can't see that can you? You're too distracted by the "shiny" to notice everything else. If you're going to try to create a realistic experience with physics, sound and AI then why would you not do the same with graphics?
In what cases is it "tailored to squeeze every ounce of power out of it's hardware"?
...an any case where the admin/owner decides to take a trip through make config , in extreme cases literally tear out unused bits of kernel from source (then recompile), or on a lesser scale, tweak up /etc/sysctl.
Not really, that might reduce the footprint a bit but it's a far cry from tailoring it to "squeeze every ounce of power out of it's hardware". I doubt many - if any - people actually do much outside of what you specified. The real hardware-specific performance gains are going to be achieved with good hardware drivers, not just omitting things from the kernel.
But the tablet version of Windows 10 is probably not the best example since it's been optimized for the hardware (drivers).
The version running on those tablets is the same Windows 10 you run on desktops.
It still doesn't put Linux behind Windows performance wise.
Like anything you need to look at the specific use-case and hardware involved, there is no one answer that applies to all.
But there are distros of Linux, like Gentoo...where you can install it and custom compile your kernel, etc...for the hardware it is running on.
Yes that is what I said, if you make a custom version of software to target specific hardware you're more than likely to get better performance than software that targets a range of hardware. But in reality the investment in the hardware driver is going to provide far more value than modifying the kernel.
If for nothing else, this is nice for squeezing out the most of your older hardware you might be wanting to run things on rather than toss it in the trash.
Yet as this article demonstrates, the open source drivers for older hardware often regress into an unworkable state, obviously the time spent on making this older hardware work is not worth the effort.
Linux has much less overhead and is often tailored to squeeze every ounce of power out of it's hardware.
In what cases is it "tailored to squeeze every ounce of power out of it's hardware"? In its most common form (Android, Debian/Slackware/RedHat-based desktop and server distributions) it is about wide hardware compatibility. Even most embedded are just the stable kernel tree.
Linux if built for specific hardware can achieve much better performance than Windows in it's current state.
That's true of anything. If you make a special version of software that targets specific hardware it is most likely going to run better than software that targets a whole range of hardware.