OpenGL 4.5 Released With New Features

[Kraut]

So ok Nvidia writes a driver and then krohnos defines the features of this driver the new OpenGL version, no wonder Nvidia is always ahead of amd.

Maybe we should rename Opengl to Nvidia-Api and port Mantle to Linux and call it AMD API, then if one of the vendors support the other vendorspecific engine somewhat ok better than the other vendor support his engine we give a some respect for that, but developers know that there is no vendor-independend engine and konw that they have to support more than one if they want the maximum on both vendors hardware.

A few hours of course nvidia seen this new specs and implemented it in a few hours, next time jsut release it the other way around and dont pretent that the one was made before the other when its not true.

You may want to take a look at the contributor lists (which includes the company/organisation they are working for) in each extension specification.

[blackiwid]

So ok Nvidia writes a driver and then krohnos defines the features of this driver the new OpenGL version, no wonder Nvidia is always ahead of amd.

Maybe we should rename Opengl to Nvidia-Api and port Mantle to Linux and call it AMD API, then if one of the vendors support the other vendorspecific engine somewhat ok better than the other vendor support his engine we give a some respect for that, but developers know that there is no vendor-independend engine and konw that they have to support more than one if they want the maximum on both vendors hardware.

A few hours of course nvidia seen this new specs and implemented it in a few hours, next time jsut release it the other way around and dont pretent that the one was made before the other when its not true.

[bridgman]

Yeah, the shaders as the (vertex and texture) data will be separate from the commands. I kinda skipped this part. The interesting bit for me is, whether it is at all possible to get the gpu commands, that tell the gpu what programms to run on what data, standardised.

It will be standardized across HSA devices - look up Architected Queueing Language (AQL).

[log0]

That's one of the features HSA includes -- the ability for GPUs and CPUs to queue and run commands using a common mechanism. That's one of the nice benefits of userspace queues -- they allow the GPU to self-dispatch without having to involve the CPU.

Note that the GPU shader ISA doesn't actually go in the command buffers -- the code that runs on the shader core goes in a separate area of memory, then you queue commands to the GPU which (a) tell the GPU where to find the program code and (b) tell the GPU to dispatch that program on each element in an N-dimensional range of data.

Yeah, the shaders as the (vertex and texture) data will be separate from the commands. I kinda skipped this part. The interesting bit for me is, whether it is at all possible to get the gpu commands, that tell the gpu what programms to run on what data, standardised.

[log0]

None of these are good options really. You don't want a native hardware interpreter, you just want each manufacturer to make their GPUs, release the assembly documentation, and implement, say, an LLVM module to compile it from some GPU-esque IR code like GLSL. You could do it at runtime or compile time, then.

Basically, what the AMD LLVM module is, except instead of being GLSL -> IR > AMD ISA, it would be <common/any> GPU language -> IR (I have never read into the AMD llvm internals, and I don't know if they are using llvm IR or their own) -> <vendor> ISA.

OpenCL has got a portable (llvm based) IR already. Now you wold need to somehow expose the fixed dunction units (tesselation, rasterization, blending) to OpenCL. But then there are also things like hiz buffers, vertex transform caches and god knows what else...

[bridgman]

Modern GPUs work by processing command buffers. Those buffers are filled by the driver using the CPU, but that is details....

What they want is, to be able to write this command buffers directly with some kind of common GPU command language, a GPU instruction set, I guess.

That's one of the features HSA includes -- the ability for GPUs and CPUs to queue and run commands using a common mechanism. That's one of the nice benefits of userspace queues -- they allow the GPU to self-dispatch without having to involve the CPU.

Note that the GPU shader ISA doesn't actually go in the command buffers -- the code that runs on the shader core goes in a separate area of memory, then you queue commands to the GPU which (a) tell the GPU where to find the program code and (b) tell the GPU to dispatch that program on each element in an N-dimensional range of data.

[efikkan]

Its a restricted subset as a GL extension to write arbitrary shaders with. Hardly control of the device. I mean documentation like a book on your ISA from AMD or Intel:

http://developer.amd.com/wordpress/media/2012/12/AMD_Southern_Islands_Instruction_Set_Architecture.pdf

https://01.org/linuxgraphics/documentation/2013-intel-core-processor-family

Also, having another standard high level language that vendors implement through proprietary interfaces to obfuscated hardware implementations is ignoring the broader problem of why GPUs are in such bad shape. It is because nobody can compete with the status quo implementations through merit because all these proprietary drivers mean you cannot implement your own API. If I were to tell you you cannot program for x86 in C, you must use Fortran, because that is our sanctioned language and the ISA is a trade secret so we supply the only (proprietary) compiler, you would think it insane.

I can agree we would benefit from having more documentation on GPUs from Nvidia.

This point aside, like I've mentioned, we need a universal low level shading language(not assembly) to replace the old OpenGL/Direct3D/Mantle/Glide/etc. style of manipulating graphics through a bunch of API calls to the driver. Doing lots of object manipulations in todays APIs required an enormous amount of API-calls. Reducing the API overhead helps only a little bit. Being able to control the pipeline directly from the GPU would eliminate this bottleneck. Having a compact universal shading language and a small API would greatly speed up support across different drivers, instead of the complex extensions in OpenGL.

[zanny]

Or, have the GPU natively execute a language like C.

None of these are good options really. You don't want a native hardware interpreter, you just want each manufacturer to make their GPUs, release the assembly documentation, and implement, say, an LLVM module to compile it from some GPU-esque IR code like GLSL. You could do it at runtime or compile time, then.

Basically, what the AMD LLVM module is, except instead of being GLSL -> IR > AMD ISA, it would be <common/any> GPU language -> IR (I have never read into the AMD llvm internals, and I don't know if they are using llvm IR or their own) -> <vendor> ISA.

[log0]

Well, even most of our CPUs now are SoCs, so that's not the important thing.

What I got from you guys talking is that I can run code that doesn't need to be processed first by a CPU- I can have a GPU do it all as long as I write it in Assembly. The issue is that it's a huge pain to write things in assembly and it's just easier if you have a CPU that's interpreting a language to assembly to execute onto the GPU, correct? Or, have the GPU natively execute a language like C.

Modern GPUs work by processing command buffers. Those buffers are filled by the driver using the CPU, but that is details....

What they want is, to be able to write this command buffers directly with some kind of common GPU command language, a GPU instruction set, I guess.

[CrystalGamma]

Wait, are you saying that it's possible to run a computer using just a GPU, with no CPU? Like, BIOS, OS, and then Application?

The BCM VideoCore 4 (e.g. in the RPi) actually includes code that sets up the ARM core during boot, so yeah, at least that GPU probably could