Woah, AMD Releases OpenGL 4.0 Linux Support!

[smitty3268]

OpenCL is a separate package, since it needs to work on our CPUs even if there is no AMD graphics solution installed.

If we only made GPUs then we could put OpenCL in the graphics driver and be done with it

Sorry, but that doesn't make any sense to me. OpenCL is primarily intended to be used on video cards, bundling it in with the driver is exactly where it belongs. It's good that it can also run on CPU's, and for that you should have an optional package that people with Intel GPUs can download themselves, but it doesn't make any sense to force everyone to do that. Unless you really think that OpenCL is never going to take off and you're only implementing it at all as a checkbox item so you can say it's supported.

[smitty3268]

Stupid 1 minute edit...

I mean, you don't have DirectCompute seperated out like that from the Windows DirectX drivers. I don't see what the difference is, besides the obvious point that the OpenGL spec apparently doesn't force you to bundle it in.

[bridgman]

It's probably more correct to say that DirectCompute is primarily intended to be used on video cards, and that bundling DirectCompute in with the (graphics) driver is exactly where it belongs...

... and that's what we did.

OpenCL is aimed at a broader range of target hardware, including a lot of platforms which don't even have GPUs :

http://www.khronos.org/opencl/

I wouldn't be surprised if the OpenCL runtime was included in the graphics stack in the future, but we do want to make sure that (for example) a user with an AMD CPU and a non-AMD GPU still has decent support. Now that the ICD spec is out there are more delivery options.

IIRC there was a lot of discussion about this on the OpenCL amd.com forums.

[Kano]

@Qaridarium

I do not intend to buy any hardware. If AMD wants that i can test OpenGL 4 they could easyly send me a card (a phenom ii x6 + board would be also ok).

[cutterjohn]

Don't the R6XX and R7XX series(and earlier?) also have some tesselation hw? Just that noone ever used it...

[mirv]

Don't the R6XX and R7XX series(and earlier?) also have some tesselation hw? Just that noone ever used it...

Amd have had a custom tessellation extension for some time, yes - pretty sure it was since the R600 days. I don't know what differences there are between that and the current requirements for OpenGL 4.0 however.

[cutterjohn]

Ah, but now reading through all 8 pages, I remember where the problem lies, the double precision 64b floats. The earlier GPUs only support 32b IIRC which means that they will never be fully compliant with OpenGL 4.x(and above).

@qaridarium
are you ever satisfied with what is currently available? Or are you on AMD's payroll as some sort of OGM?

[koenvdd]

Most GPU's since rv670 (hd3xxx) support 64 bit. Tessellation is one of the problem points for oGL 4.0 on older hardware. Whereas it features some form of tessellation it is different from the tessellation spec'd by oGL 4.0.

Ah, but now reading through all 8 pages, I remember where the problem lies, the double precision 64b floats. The earlier GPUs only support 32b IIRC which means that they will never be fully compliant with OpenGL 4.x(and above).

@qaridarium
are you ever satisfied with what is currently available? Or are you on AMD's payroll as some sort of OGM?

[BlackStar]

Don't the R6XX and R7XX series(and earlier?) also have some tesselation hw? Just that noone ever used it...

It was used, but it was a much less flexible solution than the one mandated by OpenGL 4.0: R600/700 had fixed-function tessellation hardware, whereas OpenGL 4.0 requires tessellation shaders (R800/GF100).

I think all R800 parts will expose OpenGL 4.0 even if they don't all support 64bit processing (this can be emulated using two 32bit numbers - slow, yes, but that's the price of progress!) The high-end parts have native 64bit processing running at 2/5 the speed of the 32bit pipeline (vs 1/2 on GF100).

We won't be seeing 64bit in consumer graphics anytime soon, so that's not an issue.

[Heiko]

The high-end parts have native 64bit processing running at 2/5 the speed of the 32bit pipeline (vs 1/2 on GF100).

I recently heard that nVidia scaled the DP performance down for consumer cards to 1/8th on GF100... For the professional gpgpu cards it is still 1/2 though.