Performance?

[Twinkletoes]

What should I expect from my Pi in terms of framerate?

Let's assume I'm displaying 2 overlaid full screen 1080p quads with partial transparency on the top layer, with 1080p textures. What are you seeing in your tests for the frame draw time?

Would hard float make much of a difference? Are any of the available distributions any better than the others for OpenGL optimisation?

Bryan

[jamesh]

The OpenGL stuff runs almost all on the GPU. Overclocking that gives some more performance, and overclocking the Pi gives you a bit more. Not sure how much on the Arm side runs in float, so I would'nt expect too much performance gain there.

I'd use the latest Wheezy build and latest GPU firmware if you want the best performance. Or Raspbian.

[Twinkletoes]

I am using squeeze because raspbian and wheezy both say they are buggy - I'll give them a go.

Which of Raspbian and wheezy is likely to give me the best result?

How do I download latest GPU firmware? I've been using rpi-update - does that include it?

Bryan

[jamesh]

Well, they are both alpha, but in a pretty good state. I'd go Wheezy for the moment, but its expected that the standard Debian release will be moved to Raspian in the future. Pretty cheap to get two SD cards and compare them......

rpi_update will get you the latest firmware.

[Twinkletoes]

OK - I did an rpi-update last night on squeeze and saw no benefit. The Julia shader seemed to be the culprit - without it I got 60fps, with it I got 15.

Bryan

[jmacey]

the Julia shader is generally quite slow due to the loops in it, I've managed to get quite high poly / frame rate using simple Ambient, Specular Diffuse shader with 1 light.

This video is about the most polys I've pushed http://youtu.be/Jr1XL11ogJI

The biggest problem I've encountered is CPU bound processing before going to the GPU

[Twinkletoes]

I'm looking at a few full screen quads with full HD textures, so my app is all about fill rate rather than polys. Anyone else here done any playing with full screen stuff?

Bryan

[jmacey]

not tried yet but have got textures working ok, but did find larger textures (1K Square) were very slow to load / process. Ended up using a 512x512 and that worked ok.

[jmacey]

BTW if it's just image data how about blitting the data using the dispmanx stuff, there is an interesting thread here http://www.raspberrypi.org/phpBB3/viewt ... =33&t=7672

[dch26]

i have noticed no bugs in the raspbian distro when playing with opengl es.

i am using full screen 1920x1200 and texturing works well. admittedly, my textures are not super hi res.
i find that anything higher than 512x512 takes an eternity to load.

see my post at:
http://www.raspberrypi.org/phpBB3/viewt ... 68#p119468

i will try some larger objects for you, and try and get some timings - as i appreciate Twinkletoes isnt that interested in polygon counts

dch

[dom]

BTW if it's just image data how about blitting the data using the dispmanx stuff, there is an interesting thread here http://www.raspberrypi.org/phpBB3/viewt ... =33&t=7672

Yes, for 2D scaling and blending, then dispmanx will be much more efficient.

[Twinkletoes]

Yes, dispman would be fine until I want to do something that isn't a 2d rect - then I need gles. I may as well stick with gles all along. Any thoughts on whether 4 512x512 textures are faster than 1 1k texture? Can vertices in a buffer be coded in such a way that the shader can use a different texture per triangle without sending separate buffers?

[jmacey]

Switching textures on a per tri basis is ok just set the bind to the id of the texture you need. I think the main slowdown is the actual loading of the texture to texture memory. What is it you are actually trying to do?