6 ms·
The idea that nVidia and AMD are detecting your games, and then replacing shaders, optimizing around bugs, etc should be absolutely terrifying. And vice versa,
by byuu 12y ago
The idea that nVidia and AMD are detecting your games, and then replacing shaders, optimizing around bugs, etc should be absolutely terrifying. And vice versa, the idea of having to fix every major game's incredibly broken code is equally terrifying. And it's a huge hit to all of us indie devs, who don't get the five-star treatment to maximize performance of our games. So overall, I'd say this is a step in the right direction.
However! Having written OpenGL 3 code before, the idea that Vulkan is going to be a lot more complex, frankly scares the hell out of me. I'm by no means someone that programs massive 3D engines for major companies. I just wanted to be able to take a bitmap, optionally apply a user-defined shader to the image, stretch it to the size of the screen, and display it. (and even without the shaders, even in 2015, filling a 1600p monitor with software scaling is a very painful operation. Filling a 4K monitor in software is likely not even possible at 60fps, even without any game logic added in.)
That took me several weeks to develop just the core OpenGL code. Another few days for each platform interface (WGL/Windows, CGL/OSX, GLX/Xorg). Another few days for each video card's odd quirks. In total, my simple task ended up taking me 44KB of code to write. You may think that's nothing, but tiny code is kind of my forte. My ZIP decompressor is 8KB, PNG decompressor is another 8KB (shares the inflate algorithm), and my HTTP/1.1 web server+client+proxy with a bunch of added features (run as service, pass messages from command-line via shared memory, APIs to manipulate requests, etc) is 24KB of code.
Now you may say, "use a library!", but there really isn't a library that tries to do just 2D with some filtering+scaling. SDL (1.2 at least) just covers the GL context setup and window creation: you issue your own GL commands to it. And anything more powerful ends up being entire 3D engines like Unity that are like using a jack hammer to nail in drywall.
And, uh ... that's kind of the point of what I'm doing. I'm someone trying to make said library. But I don't think I'll be able to handle the complexity of all these new APIs. And I'm also not a big player, so few people will use my library anyway.
So the point of this wall of text ... I really, really hope they'll consider the use case of people who just want to do simple 2D operations and have something official like Vulkan2D that we can build off of.
Also, I haven't seen Vulkan yet, but I really hope the Vsync situation is better than OpenGL's "set an attribute, call an extension function, and cross your fingers that it works." It would be really nice to be able to poll the current rendering status of the video card, and drive all the fun new adaptive sync displays, in a portable manner.
- jallmann 12y ago> The idea that nVidia and AMD are detecting your games, and then replacing shaders, optimizing around bugs, etc should be absolutely terrifying. Actually it's par for the course, if you care about backwards compatibility. Raymond Chen has many, many stories about the absolutely heroic lengths Microsoft has gone to ensure that popular, yet broken, programs continue to work smoothly between Windows upgrades [1][2][3][4][5]. On Depending on Undocumented Behavior: [1] http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/12/23/45481... [2] http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/10/15/55296... Why Not Just Block Programs that rely on Undocumented Behavior? [3] http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779... Who cares about backwards compatibility? (A lot of people): [4] http://blogs.msdn.com/b/oldnewthing/archive/2006/11/06/999999.aspx http://blogs.msdn.com/b/oldnewthing/archive/2006/11/06/99999... Hardware breaks between upgrades, too: [5] http://blogs.msdn.com/b/oldnewthing/archive/2003/08/28/54719.aspx http://blogs.msdn.com/b/oldnewthing/archive/2003/08/28/54719... Joel Spolsky's (somewhat dated) "How Microsoft Lost the API War" gives a good overview of the above concerns: [6] http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html
- greggman 12y agoI'd argue there's also a bigger problem. There have never been conformance tests for OpenGL until recently. They finally wrote some for ES and then finally started backporting them to OpenGL. Worse, they rarely check the limits, only the basics. They also they didn't check anything related to multiple contexts. The point being the drivers are/were full of bugs on the edge cases. Testing works. If there were tests that were relatively comprehensive and that rejected drivers that failed the edge cases they'd gone a long way to mitigating these issues because the dev's apps wouldn't have worked. There's also just poor api design. Maybe poor is a strong word. Example, uniform locations are ints so some apps assume they'll be assigned in order then fail when they get to a machine where they're not. Another example, you're allowed to make up resource ids. OpenGL does not require you to call `glCreateXXX` just call `glBindXXX` with any id you please. But of course if you do that maybe some id you use is already being used for something else. So id=1 works on some driver but not some other. I'm excited about Vulkan but I'm a little worried it's actually going to make the driver bug issues worse. If using it in a spec compliant way is even harder than OpenGL and your app just happens to work on certain drivers other driver vendors will again be forced to implement workarounds.