Much wow, New "AMDGPU" Kernel Driver

[yoloswag9000]

Yeah, yes http://www.phoronix.com/scan.php?page=news_item&px=MTc3OTk

Way to quote sandy bridge architecture.

You can read, can you?

intel on linux is at OpenGL 3.3

[patrickjp93]

You can read, can you?

If you use open source shit. Intel's proprietary drivers (available to anyone who can download parallel studio xe 2015, aka use your college email) brings it up to 4.3.

[yoloswag9000]

If you use open source shit. Intel's proprietary drivers (available to anyone who can download parallel studio xe 2015, aka use your college email) brings it up to 4.3.

You are kidding, right? It's a development studio, not a damn graphics driver.

[Swndlr]

when i see amd, all im caring about is 300 series cards, although this interested me quite a bit. the future will be a fun place with companies prepping for it like amd is

[patrickjp93]

You are kidding, right? It's a development studio, not a damn graphics driver.

But it allows you to install the driver natively for TESTING YOUR OPENGL 4.3-COMPLIANT CODE (and, as a consequence, anything else).

[yoloswag9000]

But it allows you to install the driver natively for TESTING YOUR OPENGL 4.3-COMPLIANT CODE (and, as a consequence, anything else).

And with OpenGL 4.3 compliant code you mean either C, which should compile everywhere even if you don't have a driver which supports OpenGL 4.3 or you mean GLSL4.3 which can also be lexed, parsed, compiled to some IR or even machine language which might or might now work if you don't have an OpenGL 4.3 compliant driver.

Or you mean something else but then you'd be even more wrong.

[patrickjp93]

And with OpenGL 4.3 compliant code you mean either C, which should compile everywhere even if you don't have a driver which supports OpenGL 4.3 or you mean GLSL4.3 which can also be lexed, parsed, compiled to some IR or even machine language which might or might now work if you don't have an OpenGL 4.3 compliant driver.

Or you mean something else but then you'd be even more wrong.

Well given all OpenGL and OpenCL code is wrapped in C/C++ (if you want performance anyway) or C#, that's exactly what it implies. The compiler can make OpenGL 4.3 code, and you can run it natively on a Haswell or later iGPU since they contain the 2nd most up to date shader model (5.0 just came out with the GTX 900 series) because the studio also comes with a driver you can install directly into Linux.

[yoloswag9000]

Well given all OpenGL and OpenCL code is wrapped in C/C++ (if you want performance anyway) or C#, that's exactly what it implies. The compiler can make OpenGL 4.3 code, and you can run it natively on a Haswell or later iGPU since they contain the 2nd most up to date shader model (5.0 just came out with the GTX 900 series) because the studio also comes with a driver you can install directly into Linux.

There is no such thing as "OpenGL 4.3 code"! And no, there is no intel GPU linux driver other than the open source one.

You're so completely wrong.

[patrickjp93]

There is no such thing as "OpenGL 4.3 code"! And no, there is no intel GPU linux driver other than the open source one.

You're so completely wrong.

No such thing as OpenGL code?...

http://cs.lmu.edu/~ray/notes/openglexamples/

 

And yes, there are Intel closed drivers for Linux, though you have to be either a developer or an enterprise customer to have access (given scientific computing, which, yes, tessellation is useful for when dealing with chaos).

[yoloswag9000]

No such thing as OpenGL code?...

http://cs.lmu.edu/~ray/notes/openglexamples/

That's C code using the OpenGL API.

And yes, there are Intel closed drivers for Linux, though you have to be either a developer or an enterprise customer to have access (given scientific computing, which, yes, tessellation is useful for when dealing with chaos).

Then you don't mind backing up your claim, do you?

[patrickjp93]

That's C code using the OpenGL API.

Then you don't mind backing up your claim, do you?

API = Application PROGRAMMER Interface. OpenGL is a language the same way Java is. C code runs on the CPU and sends OpenGL commands via virtual assembly to the GPU (determined by the drivers for your GPU).

 

I've already backed it up. If you still have your college (or high school) email, you can get it for free via Parallel Studio XE 2015 provided you agree not to publish or sell any application compiled by the Intel compiler collection. Would you like a code sample and output showing OpenGL 4.3 runs natively on Iris Pro 5200?

[yoloswag9000]

API = Application PROGRAMMER Interface.

No, it's Application Programming Interface. The OpenGL API consists of C header files.

 

OpenGL is a language the same way Java is.

-- patrickjp93, Professional Learner, Master's student of Computer Science at Miami University

 

C code runs on the CPU and sends OpenGL commands via virtual assembly to the GPU (determined by the drivers for your GPU).

The only true part of this sentence is "C code runs on the CPU".

 

I've already backed it up.

No, you have not. You just repeat something wrong.

 

If you still have your college (or high school) email, you can get it for free via Parallel Studio XE 2015 provided you agree not to publish or sell any application compiled by the Intel compiler collection.

I don't even say that this is not true. But there is simply no other linux intel GPU driver than the DRM + mesa one so installing a development tool won't change it.

 

Would you like a code sample and output showing OpenGL 4.3 runs natively on Iris Pro 5200?

No, I'd like an official Intel document that says "we have a Linux GPU driver for Intel Graphics which supports OpenGL 4.3".

[patrickjp93]

@YoloSwag Time for you to go back to school on OpenGL.

http://waset.org/publications/8403/virtual-assembly-in-a-semi-immersive-environment

C is translated into virtual assembly on its way into the GPU just as I said via the driver.

And the only difference between an API and a programming language is semantics. By your logic C isn't a language. It's just a simple API for a compiler, which no veteran programmer should agree with. Certain keywords and syntax translate to certain computational functions. That is a language.

As per your Intel doc, feel free to read the parallel studio manual like I did. Now, I have more important things to do than argue with a child who couldn't code his way through a binary search tree.

[osbios]

Uhhh there is no driver blob for Intel GPUs on Linux. And the oss one uses mesa which itself does not have all the groundwork for GL4.3.

Here is a nice overview of mesa implemented features: http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt

Even with many higher features already supported as extensions, 3.3 is the current limit for fully supported core versions. E.g. Radeonsi also runs on a GL3.3 core profile at max.

Well I guess patrickjp93 is just trolling anyway. Can I tag forum users somehow?

[Misanthrope]

Uhhh there is no driver blob for Intel GPUs on Linux. And the oss one uses mesa which itself does not have all the groundwork for GL4.3. Here is a nice overview of mesa implemented features: http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt Even with many higher features already supported as extensions, 3.3 is the current limit for fully supported core versions. E.g. Radeonsi also runs on a GL3.3 core profile at max. Well I guess patrickjp93 is just trolling anyway. Can I tag forum users somehow?

 

Yes click the third button on the top right and then on bbcode select member and type it out osbios or otherwise like this:

[member='namehere']

[yoloswag9000]

http://waset.org/publications/8403/virtual-assembly-in-a-semi-immersive-environment

C is translated into virtual assembly on its way into the GPU just as I said via the driver.

No, it's not. C is only used to manipulate the state machine and upload/download buffers. C is not translated into "virtual assembly", it gets compiled and linked to a binary (ELF on linux). The shaders (GLSL) also are not "tranlated into virtual assembly" but get compiled to GPU machine code which is specific to the hardware.

 

And the only difference between an API and a programming language is semantics. By your logic C isn't a language. It's just a simple API for a compiler, which no veteran programmer should agree with. Certain keywords and syntax translate to certain computational functions. That is a language.

No, it's not. A programming language can exists without an API, an API cannot exist without a programming language.

If you write a program in C, you're going to use the language C and use the standard c library (stdlib) which is an API.

 

As per your Intel doc, feel free to read the parallel studio manual like I did.

If you read it, you can quote from it, can you? So why don't you do exactly that?

Wikipedia says that the intel GPU linux driver supports opengl 3.3 https://en.wikipedia.org/wiki/Intel_HD_Graphics

Intel's Linux documentation is pretty clear on only supporting OpenGL 3.3 ATM https://01.org/linuxgraphics/documentation

 

@YoloSwag Time for you to go back to school on OpenGL.

[…]

Now, I have more important things to do than argue with a child who couldn't code his way through a binary search tree.

Nice to know that this community is not full of assholes.

[yoloswag9000]

Uhhh there is no driver blob for Intel GPUs on Linux. And the oss one uses mesa which itself does not have all the groundwork for GL4.3. Here is a nice overview of mesa implemented features: http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt Even with many higher features already supported as extensions, 3.3 is the current limit for fully supported core versions. E.g. Radeonsi also runs on a GL3.3 core profile at max. Well I guess patrickjp93 is just trolling anyway. Can I tag forum users somehow?

Well, the GPU and the CPU are on the same die and the CPU only works with the Intel Microcode, which is a proprietary, encypted blob. So, not completely true but certainly not completely wrong.

[patrickjp93]

No, it's not. C is only used to manipulate the state machine and upload/download buffers. C is not translated into "virtual assembly", it gets compiled and linked to a binary (ELF on linux). The shaders (GLSL) also are not "tranlated into virtual assembly" but get compiled to GPU machine code which is specific to the hardware.

 

No, it's not. A programming language can exists without an API, an API cannot exist without a programming language.

If you write a program in C, you're going to use the language C and use the standard c library (stdlib) which is an API.

 

If you read it, you can quote from it, can you? So why don't you do exactly that?

Wikipedia says that the intel GPU linux driver supports opengl 3.3 https://en.wikipedia.org/wiki/Intel_HD_Graphics

Intel's Linux documentation is pretty clear on only supporting OpenGL 3.3 ATM https://01.org/linuxgraphics/documentation

 

Nice to know that this community is not full of assholes.

GPU machine code is a virtual assembly. PTX is a good example on Nvidia's side of the aisle. Those buffers, just like in OpenCL, are sent to the driver, interpretted, and recompiled to the native hardware's instruction set. Those buffers contain the language parameters of OpenGL. OpenGL is a language, a framework, and an API.

 

Also wrong. You can have a binary executable that takes commands in exactly the same way as an API describes a programming language (like an interpreted language). You cannot have a language without an API to use it. They are co-requisites for each other.

 

I have the paper copy. I don't think there's an online version of it I could copy from. If you find one I'll dig in and find the page for you.

 

Yes, I'm an ass. I'm also extremely good at and passionate about what I do be it music or programming. 

[yoloswag9000]

GPU machine code is a virtual assembly. PTX is a good example on Nvidia's side of the aisle.

The word "virtual assembly" doesn't seem to exist. Whatever you mean, "virtual assembly" is not it.

 

Those buffers, just like in OpenCL, are sent to the driver, interpretted, and recompiled to the native hardware's instruction set. Those buffers contain the language parameters of OpenGL. OpenGL is a language, a framework, and an API.

OpenCL and OpenGL are pretty different and you can't compare them as easily as you want do do here.

OpenCL specifies an API and the OpenCL C language. You can compile OpenCL C code to a kernel and execute a kernel with the API.

OpenGL specifies an API and the GLSL language. You can program the shader pipeline with GLSL code.

How it is done internally doesn't matter.

 

Also wrong. You can have a binary executable that takes commands in exactly the same way as an API describes a programming language (like an interpreted language). You cannot have a language without an API to use it. They are co-requisites for each other.

This sentence doesn't make any sense.

 

I have the paper copy. I don't think there's an online version of it I could copy from. If you find one I'll dig in and find the page for you.

If you have the paper copy you could just quote from that or upload a photo.

[patrickjp93]

The word "virtual assembly" doesn't seem to exist. Whatever you mean, "virtual assembly" is not it.

 

OpenCL and OpenGL are pretty different and you can't compare them as easily as you want do do here.

OpenCL specifies an API and the OpenCL C language. You can compile OpenCL C code to a kernel and execute a kernel with the API.

OpenGL specifies an API and the GLSL language. You can program the shader pipeline with GLSL code.

How it is done internally doesn't matter.

 

This sentence doesn't make any sense.

 

If you have the paper copy you could just quote from that or upload a photo.

Easiest example of a virtual machine language is byte code for a virtual machine. A driver is a virtual machine. C# and Java compile into virtual assembly representation before being interpreted by the JVM or the .net VM. Same concept. The driver figures out what to do with the virtual assembly created by the compilation of the C+OpenGL/OpenCL program, depending on application.

 

OpenGL is a framework for using a GPU to do graphics and graphics only, however some smart people have figured out how to use tesselation in scientific computing. The premise is exactly the same even though purpose differs. The pipeline of OpenGL is the same as the buffer queue of OpenCL, just another form with different expectations of output, but the same concept and general usage.

 

That sentence makes a lot of sense. Think your OS kernel and doing command line stuff. It's a language as much as it is an API. I think you confuse programming language with Turing-complete languages, neither of which subsumes the other.

 

I'll hunt down the page(s) later this evening then.

[osbios]

Well, the GPU and the CPU are on the same die and the CPU only works with the Intel Microcode, which is a proprietary, encypted blob. So, not completely true but certainly not completely wrong.

I don't expect much GPU related parts in the Intel microcode, if any at all.

Would be interesting to see if the intel mesa drivers work without supplying and microcode with Linux at boot. Then you stuck with what you bios/efi is using and can tell if the driver actually depends on "firmware" upgrades.

GPU machine code is a virtual assembly.

GPU machine code is GPU machine code.

"Virtal assembly" as intermediate Bytecode like TGSI(LLVM), or the PTX you mentioned that Nvidia uses with cuda.

By using it you only need to build a single GLSL/HLSL/CUDA parser.

The actually hardware depending components then just need to work with the intermediate Bytecode. This design removes duplicated work and makes the hardware depending parts smaller.

But that is just an internal driver design and does not change the fact that the GPU gets fed a specific GPU instruction set and not "Virtal assembly".

[patrickjp93]

I don't expect much GPU related parts in the Intel microcode, if any at all.

Would be interesting to see if the intel mesa drivers work without supplying and microcode with Linux at boot. Then you stuck with what you bios/efi is using and can tell if the driver actually depends on "firmware" upgrades.

GPU machine code is GPU machine code.

"Virtal assembly" as intermediate Bytecode like TGSI(LLVM), or the PTX you mentioned that Nvidia uses with cuda.

By using it you only need to build a single GLSL/HLSL/CUDA parser.

The actually hardware depending components then just need to work with the intermediate Bytecode. This design removes duplicated work and makes the hardware depending parts smaller.

But that is just an internal driver design and does not change the fact that the GPU gets fed a specific GPU instruction set and not "Virtal assembly".

The GPU gets fed that via the driver, as I've basically been saying.

[yoloswag9000]

The GPU gets fed that via the driver, as I've basically been saying.

You're basically saying many things. Your terminology is so bad and you're mixing up all kinds of words, names and concepts. You probably mean the correct thing, but you say wrong stuff all the time.

[yoloswag9000]

I don't expect much GPU related parts in the Intel microcode, if any at all.

Would be interesting to see if the intel mesa drivers work without supplying and microcode with Linux at boot. Then you stuck with what you bios/efi is using and can tell if the driver actually depends on "firmware" upgrades.

I honestly have no idea if/how the CPU microcode ties into the GPU. The problem here is that you need the microcode for the CPU to initialize, and you need to initialize the CPU to use the integrated GPU, therefor you need a non-free blob to use intel graphics.

GPU machine code is GPU machine code.

"Virtal assembly" as intermediate Bytecode like TGSI(LLVM), or the PTX you mentioned that Nvidia uses with cuda.

By using it you only need to build a single GLSL/HLSL/CUDA parser.

The actually hardware depending components then just need to work with the intermediate Bytecode. This design removes duplicated work and makes the hardware depending parts smaller.

But that is just an internal driver design and does not change the fact that the GPU gets fed a specific GPU instruction set and not "Virtal assembly".

I have never heared "Virtual assembly" before but I do understand intermediate bytecode, and intermediate representation (IR). Not even google knows virtual assembly.

[patrickjp93]

You're basically saying many things. Your terminology is so bad and you're mixing up all kinds of words, names and concepts. You probably mean the correct thing, but you say wrong stuff all the time.

No, I've been consistent the entire time and not changed anything. You're twisting terms around.