GL performance

[gregd72002]

Hi,

I guess this topic has already many flavours (i.e. xorg, opengl), however I'm interested in the performance people are getting when running glxgears (with no arguments).

On archlinux one needs mesa-demos package, on debian.. dunno

On my archlinux it is around 27.2 FPS...

What are the other results? I guess the huge benefit will be once someone manages to get the right drivers/access to the GPU but from my understanding this is not currently possible and all the results should be around 27 FPS.

Cheers,

Gregory

[shirro]

Why would anyone be interested in glxgears? It is software rendering.

All the action is happening with OpenGL ES.

Pick a shader demo from glsl.heroko.com or http://www.iquilezles.org/apps/shadertoy/ and if it will run at all I can tell you how many frames at full hd running on the Pi.

[JonB]

glxgears is a lousy benchmark.

Read this if you'"re unconvinced..

http://wiki.cchtml.com/index.p....._Benchmark

That link is the number one Google hit when you type glxgears into the search prompt.

[redneon]

The problem with running glxgears is that it'll be using the unaccelerated X driver so it will be incredibly slow. A better benchmark would be to compile and run the sample hello_triangle application in /opt/vc/src/hello_pi as that uses the bcm_host lib and will therefore use accelerated graphics.

[RichardUK]

To answer the question, The GPU is showing promise. Quake3 60 FPS @1080p! That is impressive! But I am finding some unexpected bottle necks so I expect with some driver updates it will get quicker.

In short, it punches well above it's weight.

[AlArenal]

Any benchmark is good as long as you know what exactly you are measuring.

As people already said, glxgears is software-ony and the X driver isn't optimized, either. So this benchmarks is some kind of a simple real world benchmark for completely unaccelerated 3D.

Low-level benchmarks may reveal the power of the hardware and quality of drivers, giving you an idea of what is theoretically possible. But user acceptance is based rather on real world performance.

[jmacey]

I'm getting really good performance using my own library. I do matrix calculations on the CPU and then send to a shader on the GPU, here is a video http://www.youtube.com/watch?v=Jr1XL11o ... ature=plcp showing it in action with very little code optimisation (I'm basically trying to break the gpu at present to see what the limits are)

These are the full Stanford models so very high poly, the Buddha and dragon are 100000 triangles each, the bunny 69666 and the troll 36512 the rest are created procedurally and each one is sent to the GPU as a Vertex Buffer Object. In this case I've allocated the max GPU memory (128 / 128 CPU/GPU split). The shader is doing basic per vertex Phong model with one static light.

I will release the code later this week just need to add texture support.

Jon

[Jim Manley]

Hi Jon,

I'm really glad to see your work and am following it. Have you gotten a chance to finish up the Pi port of your code to include the texture support per your last post, above?

Thanks!

[jmacey]

yes texture support is now in the lib, it uses ImageMagick for loading (which is in the apt repo). The latest code is now available on google code (with a demo of loading an textured model .obj in the downloads section)

http://code.google.com/p/pingl/

The only thing I need to complete now is the text rendering (I decided to use freetype for this) It does the basic glyph loading but the font metric / layouts are not quite correct, will work on this soon once all the exam marking / boards are over at the end of this week