In the meantime, are there any other solutions that you and the Google #squad plan to offer? Like...people who will answer a phone call?
267 karma · joined November 3, 2014
Are you trying to quickly understand how to draw a triangle to a screen with a texture? I would say...write a quick software rasterizer.
Are you trying to understand how modern GPUs work, and how to use them? Use Vulkan/DX12/Metal.
Are you just trying to draw a ball on the screen and kick it around? Use a game engine.
At this point, OpenGL doesn't really fit any of those boxes. What it does kinda do is...conceptually show you how 3D rendering works, but does it faster than your first software rasterizer would, and abstracts a bit of the math away if you use the API in just the right way.
The most important aspect of OpenGL is that it has a huge legacy catalog of software, including courses that teach 3D graphics programming with OpenGL.
> They say they continue to support OpenGL in parallel, but considering that Vulkan was originally called "GLNext", I have my doubts about how long they want to continue to do that.
Meh, they've been using "GLNext" in internal presentations forever. "Vulkan" as you know is basically AMD's Mantle more than an evolution to OpenGL. And don't you fret about OpenGL: lots of workstation apps still use it with no intent of changing, so...it'll stick around.
Every time a Vulkan/DX12 post is shared, this sort of comment is written. Modern GPUs are complex. They have a lot of knobs to turn. OpenGL has a lot of these same knobs, except they are implicitly turned for you in the most basic cases. But your average rendering code is nothing like the most basic OpenGL case, and involves much more knob turning.
You'll be fine. If you want to learn about how your modern GPU works, this will suit you. If not, no worries, you still have game engines.
I think it's a similar feeling to being a man, and not really understanding all the crazy shit women have to deal with.
2. It's not just the API. It's the entire SDK that has NV specific hooks that AMD can't tap into
> To define an object’s appearance in a 3D scene, real-time graphics applications use shaders... Eh, the shaders are just a part of the GPU pipeline that transforms your vertices, textures, and shaders into something interesting on the screen.
This is already oversimplifying what GPUs are trying to do for the base case of graphics.
> the interface between the CPU and GPU code is needlessly dynamic, so you can’t reason statically about the whole, heterogeneous program.
Ok, so what is the proposed solution here? You have a variety of IHVs (NV, AMD, Intel, ImgTec, ARM, Samsung, Qualcomm, etc). Each vendor has a set of active architectures that each have their own ISA. And even then, there are sub-archs that likely require different accommodations in ISA generation depending on the sub-rev.
So in the author's view of just the shader code, you already have the large problem of unifying the varieties of ISA under some...homogenous ISA, like an x86. That's a non-trivial problem. What's the motivation here? How will you get vendors to comply?
I think right now, SPIR-V, OpenCL, and CUDA aren't doing a _bad_ job in trying to create a common programming model where you can target multiple hardware revs with some intermediate representation, but until all the vendors team up and agree on an ISA, I don't see how to fix this.
On top of that, that isn't even really the only important bit of programming that happens on GPUs. GPUs primarily operate on command buffers, of which, there is nary a mention of in the article. So even if we address the shader cores inside the GPU, what about a common model for programming command buffers directly? Good luck getting vendors to unify on that. Vulkan/DX12/Metal are good (even great) efforts in exposing the command buffer model. You couldn't even _see_ this stuff in OpenGL and pre-DX12 (though there were display lists and deferred contexts, which kinda exposed the command buffer programming model).
> To use those parameters, the host program’s first step is to look up location handles for each variable...
Ok, I don't blame the author for complaining about this model, but this is an introductory complaint. You can bind shader inputs to 'registers', which map to API slots. So with some planning, you don't need to query location handles if you specify them in the shader in advance. I think this functionality existed in Shader Model 1.0, though I can't find any old example code for it (2001?).
That being said, I certainly don't blame the author for not knowing this, as I think this is a common mistake made by introductory graphics programmers, because the educational resources are poor. I don't think I ever learned it in school...only in the industry was this exposed to me, to my great joy. Though I am certain many smarter engineers figured it out unprompted.
> OpenGL’s programming model espouses the simplistic view that heterogeneous software should comprise multiple, loosely coupled, independent programs.
Eh, I don't think I want a common programming model across CPUs and GPUs. They are fundamentally different machines, and I don't think it makes sense to try to lump them together. I don't think we just assume that we can use the same programming methodologies for a single vs multi-threaded program. I know that plenty tried, but I thought the best method of addressing the differences was education and tools. I'd advocate that most effective way that GPU programming will become more accessible will be education and tools. I have hope that the current architecture of the modern 'explicit' API will facilitate that movement.
Hrm...I've thought about this a lot, and I don't think it's as much as not having interest, as much as not having time. Or at least...not being able to monetarily demonstrate to their employers that it would be worth the engineers time to generate educational resources and better tools.
I do think AMD is trying to get better in this area with their GPUOpen stuff, though of course, you never know what might happen if AMD suddenly becomes top dog.
The API was built so that the cost of compilation by the driver would only be done once (likely at install, or at driver update time). So the idea is that when you are installing your PC game, it is compiling all the shaders against the current driver rev and hardware in your machine. Then when you play the game, it just loads the locally compiled binaries so your game doesn't hitch at random times when the driver compiler decides to kick off a compilation pass.
However, the binary is very sensitive to the driver version (as it owns the compiler), and the hardware itself. The binaries will differ across vendors, vendor architectures, and even sub-revisions inside of a single architecture.
Bonus: This API was provided as part of the GL_ARB_ES2_compatibility extension, in order to ease porting from OpenGL ES 2 to (big) OpenGL. OpenGL has a different API/extension, glProgramBinary, that is preferred for OpenGL. glShaderBinary might not even really work on any desktop implementation.
Probably the best source for this, though this information is relatively...obfuscated: https://community.amd.com/thread/160440
I don't think it's unreasonable to ask for explanation/references/proof of what you mean when you say 'poison'. I don't know your particular experiences with chemotherapy, but I hear this soundbite parroted too often without any effort to actually research what chemotherapy is actually trying to accomplish. I'm not saying people shouldn't investigate their recommended treatment plans, but this often unwarranted suspicion of modern cancer treatment techniques is mystifying to me.
I've seen asynchronous DMAs + command execution (copy engine) exposed in some APIs, but not asynchronous compute shaders.
I don't think they'll do it. I think they're going to shoot for SPIR-V being close enough that SPIR-V compilers generate code good enough that the internal compilers can gen good ISA code.
> They're not overhauling the ISA every year.
They aren't, but the changes rev to rev are more significant than you'd expect. On top of that, the big bumps are significant, such as Fermi to Kepler or Northern Islands to Southern Islands (or whatever). These are not backwards compatible with each other, unlike Intel x86 ISA.
Bonus edit: Also...I'd speculate that some IHVs would rather not expose their IL-to-ISA compiler. Not because of 'secret sauce'. But because they aren't that good, and would rather have the OSS community start fresh and do a better job.
Interestingly, most console developers currently have this sort of access. If they are just targeting consoles (or better, a specific platform), they're able to get a lot done. The tricky part is if they have to target PC and consoles. They have the access they want on consoles, but can't replicate on PC.
Actually, on top of that, replicating that task on PC would mean giving developers a nightmarish mix of varying, quirky architectures to target. Realistically, what most _engine_ devs want on PC are more current and lower level access APIs (DX12 and Vulkan) and maybe even an OSS shader compiler. The compiler wouldn't be even for them to poke at. I think they'd hope that the OSS community might do a better job than the IHVs at maintaining the compiler.