Don't forget the Cell

[androvsky]

It's worth mentioning that even if people do upgrade to >2.10, there's still Cell video acceleration thanks to unsolo and spu-medialib, and I know that the mesa opengl people are FINALLY actually working on OpenGL for the Cell, and Sony will never shut that down as long as you can run linux on the PS3.

Obviously it won't be as fast as the RSX, but then again, RSX access wasn't likely to give us OpenGL support any time soon, if ever.

It's further worth mentioning I meant this to be a reply to RSX ps3 need help thread, please feel free to move this if necessary.

[aegiswings]

I don't think OpenGL using the cell is really going to be usable at all. Remember the days of software rendering? Performance will be so miserable it won't be worth doing graphics at all. Unless you think Quake 2 is pretty cutting-edge, that is. The major hurt is going to be in texture mapping. Everything will run great if you use simple texture flat-shaded polygons. I don't see why the mesa people even bother.

[ooPo]

You're both misinformed. There's some info here:

http://en.wikipedia.org/wiki/Mesa_3D

Whilst Mesa 3D supports several hardware graphics accelerators, it may also be compiled as a software-only renderer.

Basically, Mesa 3D is an implementation of the OpenGL API that you can plug your hardware acceleration code into. We're not 'finally' getting it, you already have it when you install Linux on your PS3. People are working on offloading parts to the SPUs to make it faster than the software-only mode it uses currently.

Having RSX access also wouldn't 'give' you OpenGL, but it would let you offload parts of Mesa 3D to it. This is basically what a 3D driver does - provide the hooks you need to use it in libraries like OpenGL and DirectX.

What does this mean? Go ahead and write your apps now and they'll run. Everyone has OpenGL already. When/if SPU and RSX support are completed in the future they'll run faster.

[aegiswings]

Basically, Mesa 3D is an implementation of the OpenGL API that you can plug your hardware acceleration code into. We're not 'finally' getting it, you already have it when you install Linux on your PS3. People are working on offloading parts to the SPUs to make it faster than the software-only mode it uses currently.

I've used Mesa before and I think it's great. I was questioning people who are bothering porting Mesa to the cell processor. Software rendering is dreadfully slow. So slow that you are lucky to run a modern 3D app and see a single frame. The gap between hardware accelerated rendering and software rendering is only increasing, even as CPU's get faster because GPUs get even faster. Offloading parts of Mesa to be accelerated on the cell might be a fun project but it's still software rendering and I don't think it's going to result in performance that is worth the effort.

Finally, I don't think RSX support in the form of an OpenGL driver is ever coming. If Sony decides to someday provide one, great, we'll use that and suddenly OpenGL apps will just work. In the meantime OpenGL apps using Mesa won't be adequate. I think what is more likely is that we somehow figure out how gain access to the RSX again (like we did in pre 2.10). In that case, we are basically relying on the Rennoveau team to figure out the NVIDIA technology and then using that on the PS3. We won't have a full OpenGL driver but we'll be able to use at least some of the 3D acceleration I don't think Mesa will be useful in that situation either because I don't see how you would be able to mix hardware acceleration with software rendering.

[Kuroikaze]

If you're comparing software rending on a general purpose CPU like an Intel or AMD to software rendering on something more math oriented like the cell, you're incredibly misinformed.

the Cell has a lot more in common with a GPU than a general purpose CPU.

With proper optimization, you could probably get PSP or even PS2 level graphics doing software rendering on a PS3 at 480p.

In fact, the PS3 originally didn't have the RSX. They were going to use the Cell and SPUs to render graphics.

[jbit]

It's worth while pointing out that at some SCE presentations (I think the PS3s first E3) they showed some tech demos that rendered and calculated using just the Cell (no RSX). Sony always point this out during the demos. I think they had some fly by using satellite map data to generate real time 3D terrain doing rendering on Cell... amongst other things.

edit:
Here's a link to what I'm referring to, I think there are more STI tech demos either in this video, or others. :)
http://video.google.com/videoplay?docid ... 9#1h00m45s

[ooPo]

We won't have a full OpenGL driver but we'll be able to use at least some of the 3D acceleration I don't think Mesa will be useful in that situation either because I don't see how you would be able to mix hardware acceleration with software rendering.

What do you think a 'full OpenGL driver' is? Nvidia, ATI and the rest start with a software implementation and offload stuff to their videocards when possible. There is no hardware that provides a native OpenGL interface. Its all a mix of varying degrees.

Besides, a lot of actual rendering these days is being done with pixel shader code running on shader units. This is essentially what a SPU is. Offloading parts of Mesa 3D to the SPUs is certainly not a waste of time.

[androvsky]

You're both misinformed. There's some info here:

http://en.wikipedia.org/wiki/Mesa_3D

Whilst Mesa 3D supports several hardware graphics accelerators, it may also be compiled as a software-only renderer.

Basically, Mesa 3D is an implementation of the OpenGL API that you can plug your hardware acceleration code into. We're not 'finally' getting it, you already have it when you install Linux on your PS3. People are working on offloading parts to the SPUs to make it faster than the software-only mode it uses currently.

Having RSX access also wouldn't 'give' you OpenGL, but it would let you offload parts of Mesa 3D to it. This is basically what a 3D driver does - provide the hooks you need to use it in libraries like OpenGL and DirectX.

What does this mean? Go ahead and write your apps now and they'll run. Everyone has OpenGL already. When/if SPU and RSX support are completed in the future they'll run faster.

Apparently I oversimplified the issue slightly. I specifically mentioned Mesa OpenGL for the Cell (implying use of the SPUs), not the PowerPC which is what we essentially have now. And without use of the SPUs, current Mesa is useless for virtually anything beyond simple test applications. I know, I tried neverball on my PS3. :( If you want to develop for OpenGL on the PS3, do it on your PC in C with a Geforce 3 video card. A good Mesa implementation on the Cell probably could be that fast, keeping in mind there probably won't be any problems with the hardware not supporting certain features, like advanced shaders. ;)

And yes, I know RSX won't 'give' us OpenGL. All RSX access would do is give the poor nouveau people something more to work on. Last I checked, in order for Mesa to offload calculations to a video card, there has to be some understanding of how the video card actually works. :)

I said "finally" because the mesa-dev mailing list said that Tungsten Graphics, Inc (one of Mesa's sponsers) said they were paying for a couple of the lead developers to work on a Cell port (offloading to SPUs) back in May. They decided to make it part of the Gallium infrastructure, so they didn't write any SPU code until mid-December, iirc. Hopefully a usable implementation won't take too terribly long.

[aegiswings]

What do you think a 'full OpenGL driver' is? Nvidia, ATI and the rest start with a software implementation and offload stuff to their videocards when possible. There is no hardware that provides a native OpenGL interface. Its all a mix of varying degrees.

Long gone are the days when the hardware is simply used to accelerate parts of the rendering pipeline. Actually what NVIDIA hardware provides is very close to a full OpenGL interface (I don't know about ATI) and it's become impossible to interrupt that pipeline and replaces parts of it with software.

The NVIDIA methods provided by the hardware correspond pretty directly to the OpenGL functions. For example there are hardware methods to set the stencil mode, set the blend functions, set the clip rectangles, and send vertex data to the device. All of the rendering is done in hardware and there really isn't any option to avoid some of the pipeline and do it in software. The OpenGL libraries themselve are pretty simply these days. Most of the work is actually done in the driver portion that does things like manage the video memory ont he device and set up the objects, notifiers, DMA buffers etc. that the hardware uses.

[ooPo]

I never said they were simply accelerating parts of a rendering pipeline. Of course there's a lot more than that going on. What I said is that until you're sending actual OpenGL commands directly to the hardware, you're still running software with hardware acceleration.

My point was that writing off Mesa 3D as useless because it was software is silly. Offloading code to the RSX & SPUs is no different than how the major companies do it - they're just further along in the process. And have hardware documentation. And paid developers. And so on...

[warrennn]

I strongly disagree about the "uslessness" of software rendered OpenGL.

I suppose that it is useless for games and rendering of complicated scenes, but I wrote a program to analyze an optical instrument (a build-up cavity for enhanced second harmonic generation) and it is rendered very quickly on my PS3. It consists of 4 mirrors (two flat and two concave, all thick 3D objects) and some Gaussian laser beams, all of which use shading and remote light sources. The whole instrument can be rotated with the mouse in real time and this operation is incredibly smooth. In fact, hardware acceleration would be no help at all.

I suppose the bottom line is that it depends upon the opjects being rendered, but there are a large number of things which work very well with software rendering. I would of course like to see RSX supported OpenGL, but don't expect it to happen.

[ldesnogu]

Long gone are the days when the hardware is simply used to accelerate parts of the rendering pipeline. Actually what NVIDIA hardware provides is very close to a full OpenGL interface (I don't know about ATI) and it's become impossible to interrupt that pipeline and replaces parts of it with software.

Now I wonder why nvidia and ati have been recruiting code gen specialists for years (long before pixel shading and/or CUDA were a la mode) ;-)

Some parts of OpenGL are not implemented in HW, that'd be too costly and most of the time useless.

The OpenGL libraries themselve are pretty simply these days.

Hum... :)
I think you should take a look at driver sizes and at OpenGL spec.

[unsolo]

Software Open GL accelleration on cell would be a nice feature not only for the ps3 but also for future cell compatible or cell platforms. Even as a proof of consept it would be great to have.

[aegiswings]

Quote:
The OpenGL libraries themselve are pretty simply these days.

Hum... :)
I think you should take a look at driver sizes and at OpenGL spec.

By OpenGL library I mean just the device independent front end of the library that parses the parameters and handles the data. This part is a relatively thin front-end and most of it is error checking and maintaining things like the graphics context, the drawables, and the display. Sure the OpenGL spec has gotten pretty huge but most of it is redundant and the PS3 uses OpenGL ES anyways which is thankfully much smaller and eliminates much of the difficult things that used to have to be handled by the library like immediate mode (begin/end) rendering. Everything interesting is done by the "driver" portion of the library which is responsible for sending data and maintaining the hardware.

OpenGL *is* all done in hardware these days. A prize to anyone who can point out one non-trivially part of OpenGL that isn't implemented in hardware?

[androvsky]

I strongly disagree about the "uslessness" of software rendered OpenGL.

I suppose that it is useless for games and rendering of complicated scenes, but I wrote a program to analyze an optical instrument (a build-up cavity for enhanced second harmonic generation) and it is rendered very quickly on my PS3. It consists of 4 mirrors (two flat and two concave, all thick 3D objects) and some Gaussian laser beams, all of which use shading and remote light sources. The whole instrument can be rotated with the mouse in real time and this operation is incredibly smooth. In fact, hardware acceleration would be no help at all.

I suppose the bottom line is that it depends upon the opjects being rendered, but there are a large number of things which work very well with software rendering. I would of course like to see RSX supported OpenGL, but don't expect it to happen.

Point taken, and further, your program sounds useful for something I'm doing too :)

[androvsky]

OpenGL *is* all done in hardware these days. A prize to anyone who can point out one non-trivially part of OpenGL that isn't implemented in hardware?

Depends on what you mean by non-trivial. One of the truly annoying things about OpenGL is doesn't like you finding out what is and is not handled by hardware, and what's handled by the driver in the cpu.

I'll toss out one example I ran into. Texture mapping an RGB bitmap or an RGBA bitmap. Nvidia cards at least expect an alpha channel for texture maps, and it expects BGRA format, not RGB. Therefore the above examples need to be swizzled, and the RGB needs an alpha channel added. Granted, I don't know if the CPU is still used to do this or if the newer cards use the pixel shaders to handle the conversions, but the end result is the same: They won't texture a polygon with an RGB bitmap. Attempting to do so will result in a very impressive drop in texturing performance.

[ooPo]

OpenGL *is* all done in hardware these days. A prize to anyone who can point out one non-trivially part of OpenGL that isn't implemented in hardware?

http://www.opengl.org/pipeline/article/vol003_7

Being that the video hardware is virtualized, user-mode components (the OpenGL ICD is one of those) no longer have direct access to that hardware, and need a kernel transition in order to program registers, submit command buffers, or know the real addresses of the video resources in memory.

Sounds to me that there's a hardware driver that supports a lower-level acceleration API and both OpenGL and DirectX commands get translated to this layer as they're executed. This would mean OpenGL not only isn't implemented in hardware, but indicates a trend towards a more generalized acceleration API in the future.

[ldesnogu]

OpenGL *is* all done in hardware these days. A prize to anyone who can point out one non-trivially part of OpenGL that isn't implemented in hardware?

OpenGL shading language compilation? What's my prize? :)

[aegiswings]

OpenGL shading language compilation? What's my prize? :)

That's a good one, but I think on the PS3, shaders are precompiled and so the compiler isn't part of the library but a standalone utility run when the application is built.

In general, I guess you are right although I've always dealt with pre-compiled shaders.

[aegiswings]

OpenGL *is* all done in hardware these days. A prize to anyone who can point out one non-trivially part of OpenGL that isn't implemented in hardware?

http://www.opengl.org/pipeline/article/vol003_7

Being that the video hardware is virtualized, user-mode components (the OpenGL ICD is one of those) no longer have direct access to that hardware, and need a kernel transition in order to program registers, submit command buffers, or know the real addresses of the video resources in memory.

Sounds to me that there's a hardware driver that supports a lower-level acceleration API and both OpenGL and DirectX commands get translated to this layer as they're executed. This would mean OpenGL not only isn't implemented in hardware, but indicates a trend towards a more generalized acceleration API in the future.

That's a pretty interesting page about Vista but it is reflecting more of how Microsoft likes to write it's OSes rather than the current state of graphics hardware. Graphics hardware hasn't changed at all with the release of Windows Vista. What is going here is that Microsoft is adding yet another layer of abstraction to it's display system (and at the same time killing performance.)

Modern graphics hardware already has a concept of multiple hardware contexts. There is actually a scheduler running inside GPUs that perform hardware context switches that swap in and out the whole state of the graphics device. This is completely internal to the GPU and the CPU and the OS isn't involved at all. This allows you to draw in different graphics contexts as if you had multiple graphics cards. I don't know why Microsoft is getting involved with their "video scheduler" -- GPU's already do that for you. They are just adding another layer of overhead we don't really need.

Vista might abstract away the communications with the graphics hardware (pushbuffers and register access) and require a kernel transition to access it but the commands ultimately being sent to the hardware still are pretty close to OpenGL itself. The abstraction from internal graphics state to OpenGL is provided by the GPU itself, not by the OpenGL driver or by Vista's HAL.

There is no low-level acceleration API. What appears to be happening is Vista's OpenGL is just passing on the OpenGL functions to an ICD, if one exists, and that ICD packages up the data to be sent to the hardware and then it calls the HAL to actually manipulate the GPU registers and send the data. None of this is necessary for graphics acceleration in other OSes. This is only so Vista can do the stuff that Beryl has been doing for some time now (except Vista isn't hardware accelerated).

[ldesnogu]

Well I don't know how I can convince you. I work for a company that does GPUs, so I have some inside view, which of course I can't share unless you sign an NDA ;)

[aegiswings]

Well I don't know how I can convince you. I work for a company that does GPUs, so I have some inside view, which of course I can't share unless you sign an NDA ;)

I can't really convince you either for the same reasons even though I have the PS3 OpenGL driver code sitting right in front of me. :)

[ldesnogu]

Well I don't know how I can convince you. I work for a company that does GPUs, so I have some inside view, which of course I can't share unless you sign an NDA ;)

I can't really convince you either for the same reasons even though I have the PS3 OpenGL driver code sitting right in front of me. :)

Hehe I guess embedded GPUs are still far from PS3 class GPUs :)

[aegiswings]

Well I don't know how I can convince you. I work for a company that does GPUs, so I have some inside view, which of course I can't share unless you sign an NDA ;)

I can't really convince you either for the same reasons even though I have the PS3 OpenGL driver code sitting right in front of me. :)

Hehe I guess embedded GPUs are still far from PS3 class GPUs :)

What embedded GPUs do you work with? PowerVR?

[audi100quattro]

Software Open GL accelleration on cell would be a nice feature not only for the ps3 but also for future cell compatible or cell platforms. Even as a proof of consept it would be great to have.

I actually think there might be a closed source implementation out there. Perhaps something like Mesa itself accelerated using RapidMind's fancy data parallel approach, anybody know? How much faster is it as opposed to running Mesa purely on the PPU?

Mesa is MIT licensed, and the rest I'm sure you could get licensed from SGI.

edit: google shows this, which confirms how hard (and proprietary) it is even with RapidMind's wrapper/compiler/runtime.