31–40 of 97 posts
Direct access to the GPU...is that done in some kind of sandbox at least? How do Mantle/Metal/DX12 do it?
I think one of the primary reasons more people don't target GPUs to offload computation, is because it -- most often -- requires proprietary drivers running on the host OS, for it to work (at an acceptable speed).
Imagine if putting an AMD of nVidia card in your box was the same as adding a CPU. If you wanted to write OpenCL to execute on the GPU, thread allocation, memory management etc. for that would be part of an open source OpenCL library, that your application links to, and then you can write OpenCL kernels that execute on the GPU via these libraries. No need for proprietary driver blobs running on the host machine.
I hope we can get to a point where trying to sell a GPU that requires a proprietary driver running in the host OS is as viable as trying to sell a CPU that requires the same.
Earlier quoted context omitted.
I get that AMD wants this because it will make CPU performance less important for gamers, as they can't currently compete against Intel here. AMDs APU concept would become more attractive that way. Valve etc. want this because OpenGL sucks, but DX is Win only. Microsoft will want to defend its DX stronghold - can they, on a technical level? Will Nvidia play along?
> Valve etc. want this because OpenGL sucks Actually Valve labeled OpenGL to be "shockingly efficient" in one of their presentations (postmortem of porting the Source Engine to Linux).
> "I know it's possible for Linux ports to equal or outperform their Windows counterparts, but it's hard. At Valve we had all the driver devs at our beck and call and it was still very difficult to get the Source engine's perf. and stability to where it needed to be relative to Windows. (And this was with a ~8 year old engine - it must be even harder with more modern engines.)"
http://richg42.blogspot.co.uk/2014/11/state-of-linux-gaming....
I had a long debate on multiple forums recently regarding the almost uselessness of OpenGL in presence of something like OpenCL, especially when OpenGL does its job (as a graphics library) in a very crappy manner by trying to be part-framework, part-library, and not doing either properly, and making the life of a graphics programmer a living hell, who has to code 80% of the graphics pipeline by hand or using third pa…
Well, then you're going be disappointed by Vulkan as well. OpenGL (and modern GPUs) are built around screen space rasterization of points, lines and triangles. Being aimed primarily at the graphics part of GPUs, Vulkan uses the same primitives.
The major difference to OpenGL is, that you no longer do stuff like
glGenTextures(...)
glBindTexture(…, texID)
glTexStorage…(...)
glTexImage…(...)
glActiveTexture(... + i)
glBindTexture(…, texID)
glUniform1i(sampler_index, i)
vkCmdBindDescriptorSet(cmdBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, textureDescriptorSet[0], 0);
vkQueueSubmit(graphicsQueue, 1, &cmdBuffer, 0, 0, fence);
vkMapMemory(staticUniformBufferMemory, 0, (void **)&data);
// ...
vkUnmapMemory(staticUniformBufferMemory);
Earlier quoted context omitted.
I've spent 15 years working on OpenGL, but I'd kick it to the kerb in a heartbeat. AMD and NVIDIA are free to implement Vulkan on Windows and Linux, but the problem is that we will probably be stuck with OpenGL 4.0 on Mac OS X for the foreseeable future.
From the website: > Will work on any platform that supports OpenGL ES 3.1 and up Furthermore, Apple is on the working group.
Very exciting! I wonder: when will we be able to start making projects with this? It would be interesting to see how it compares with OpenCL when it comes to doing things like Bullet physics' GPU rigid body solver and so on. Also, of course, ray tracing! :D
OpenCL will become a library that is implemented by interacting with the GPU via the Vulkan API, and as an application developer you'd use OpenCL. Or perhaps you'd never again use OpenCL, because someone else develops a better library.
Perhaps someone creates a Haskell library -- which talks to the GPU via the Vulkan API -- that implements a map function that executes in parallel on the GPU. In that case you wouldn't use OpenCL or Vulkan directly at all.
Earlier quoted context omitted.
I don't know too much about the topic (I wish I did), but how what makes you think so? I see that it says "Will work on any platform that supports OpenGL ES 3.1 and up" and Apple platforms seem not to support that (as of now). However Apple is part of the working group, doesn't that make it very likely they are working on an implementation, too?
Apple are traditionally tardy when it comes to OpenGL. Yosemite is still on 4.1 (2010 release), lacking support for things like compute shaders.
I had a long debate on multiple forums recently regarding the almost uselessness of OpenGL in presence of something like OpenCL, especially when OpenGL does its job (as a graphics library) in a very crappy manner by trying to be part-framework, part-library, and not doing either properly, and making the life of a graphics programmer a living hell, who has to code 80% of the graphics pipeline by hand or using third pa…
> I had a long debate on multiple forums recently regarding the almost uselessness of OpenGL in presence of something like OpenCL, > (...) > I realized this very strongly when I considered doing graphics using OpenGL but with a photorealistic renderer like a path tracer. Well, then you're going be disappointed by Vulkan as well. OpenGL (and modern GPUs) are built around screen space rasterization of points, lines and…
It seems from the Vulkan Language Ecosystem graphic that they expect new languages to be developed that translate to Vulkan, for those who want to work at a higher level.
Earlier quoted context omitted.
Apple are traditionally tardy when it comes to OpenGL. Yosemite is still on 4.1 (2010 release), lacking support for things like compute shaders.
Oh, I see, didn't realize that. That is a pity because I would very much like for cross platform gaming to become much more of a thing and Vulkan does seem likely to be a big milestone in that, esp. considering Valve's involvement.
Despite urban legends propagating the myth, games consoles don't feature OpenGL APIs as such, rather using more low level ones, even if inspired by OpenGL.