OpenGL 3 Updates

[Zengar]

You miss the point that GPGPU will become mainstream very soon. For example, Apple won't just release OpenCL – they will be sure to use it too. Video encoding, image processing, game physics, sound procesing – there are lots of possibilities for a normal user. Cuda is already used by never Nvidia drivers to provide PhysiX acceleration.

But I agree that it is pointess to base GL on GPGPU – it is a distinct API. This two things must exist in parallel.

[bobvodka]

Agree, they should exist in their own APIs.

I still see it as a problem however that the hardware is pretty different (and will only get more so once Intel enters the game) which brings up issues with levels of abstraction and how you program them.

As I metioned, optimal for AMD isn't going to be optimal for NV and if you want the pure to the metal power of either chipset any sort of abstraction starts to cause you problems and start to sap that to a degree.

I'll watch OpenCL with intrest.

[Korval]

You miss the point that GPGPU will become mainstream very soon.

To do what? Video encoding, image processing, and sound processing are all stuff that is easily done on the CPU. It is 10x easier to do them on the CPU. After all, if you offload that stuff to the GPU, what is that Quad Core CPU going to be doing?

As for game physics, if you're talking about incidental stuff like particle systems, maybe. If you're talking about physics that actually interacts with the gameplay, no. Once again, it's much easier to do it on the CPU, where you AI and so forth is. AI needs to respond to physics, so it needs access to the physics system.

[zed]

sure everything can be done on the CPU (including graphics) but at what speed,
video encoding even the fastest quadcore takes about an hour to encode a video, a GPU would do that 10x quicker

a lot of stuff can be done by the GPU eg SPU stuff here
http://www.naughtydog.com/corporate/...echGDC2008.pdf

i see now dx11 are making first steps in this direction, my bet is with dx12 or more likely dx13 it will be exactly how i described in an earlier post (d3d wont exist, or more correctly they will be accessed through a layer),
Remember a few years ago there used to be with directx, 2 different apis? directdraw + d3d, but in d3d8 they effectively dropped directdraw. I can remember at the time ppl moaned about the dropping of directdraw (performance etc) but in hindsite Im sure everyone now agrees it was the right way to go.
Like I said we're in the midst of a radical change in GPU usage, ogl3.0 should be aiming for this full programable solution ala CPUs, which will happening at present.

[Overmind]

In about 4 years, we'll have 32 core processors. Another year and a half and it will be 64 cores. The more cores we'll have, the less we will know what to do with them. Over time, the extra processing power of the GPU will become irrelevant compared to the power of multicore CPUs.

[knackered]

unless the GPU is moved onto the CPU die.

[ZbuffeR]

In about 4 years, we'll have 32 core processors. Another year and a half and it will be 64 cores.

You are probably right.

The more cores we'll have, the less we will know what to do with them.

You mean, by lack of imagination ? Or because of the difficulty to efficiently use deeply parallel architectures ?

Over time, the extra processing power of the GPU will become irrelevant compared to the power of multicore CPUs.

I remember Intel saying that since a decade ago, during first days of 3DFX, when they introduced their MMX extensions. I guess they were wrong all that time.
Not all games need all the huge power of a top spec PC with latest CPU and latest GPU. But some application will, for sure !

I would love to play with an earthquake simulator on a big detailed town

[Overmind]

You mean, by lack of imagination ? Or because of the difficulty to efficiently use deeply parallel architectures ?

Of course I mean the difficulty in using parallel architectures

I remember Intel saying that since a decade ago, during first days of 3DFX, when they introduced their MMX extensions. I guess they were wrong all that time.

The big difference between MMX (3dnow, SSE and so on) and a GPU is that MMX is "just" a vector processor, while a GPU is a massively parallel array of vector processors. But now if we look at multicore CPUs with a really large number of cores, that's not that different from a GPU.

The biggest advantage GPGPU has now over normal algorithms is that it can execute lots of instances of a calculation at once. But on multicore CPUs you can do the same. You can even run *different* calculations at the same time

I'm not saying that GPUs will become obsolete. Of course, if the calculation is for some graphics effect (e.g. particle system), and you don't need the result back in main memory, using the GPU still makes sense. The problem here is bus bandwidth.

Nor am I saying GPGPU is useless. It makes sense right now, but I think it will make sense less in the future. But the research will surely be useful. I'm sure the same or very similar algorithms will come in handy when we're desperately trying to get processor utilization to 100% on 64 cores in a few years

[Zengar]

If CPUs of the future will replace GPUs, then massively parallel APIs like OpenCL are still of use. The GPGPU of today is not really about how to use GPU for general purpose any more, it is how to use a massively parallel processor array effectively.

[Korval]

video encoding even the fastest quadcore takes about an hour to encode a video, a GPU would do that 10x quicker

And? Shocking though it may be, doing video encoding is not something that is "mainstream," nor will it be in the near future.

More importantly, video encoding applications don't need their hardware interface to be OpenGL. I have nothing against people using graphics hardware for other things. But OpenGL is a graphics API, and it should always remain so.