Hiya,
Are there any suggestions for GL actions that are good or bad in terms of PI performance?
Not general stuff but anything specific to the PI?
I'm just poking around with my code in an attempt to see where all the time goes and at the moment it seems that pushing any sort of data across to GL seems rather slow. IE even pushing a matrix or vector to a shader seems rather expensive? More expensive perhaps than the actual drawing.
Any ideas why and what sort of code would be best to reduce that?
Finally is there any way of pulling any information out of the gpu at run time? I'm just doing the most basic of timing to try and work out what's going on. So anywhere else I can pull data from would obviously be useful when it comes to trying to work out what is going on.
Cheers,
Re: GLES2 optimisation?
Hi, not sure I can add anything beyond what you've discovered already but to get the pi3d system running faster I did the following things:
- got rid of all ifs from the shaders (well you need a couple to discard fragments etc) this means lots of different shaders to do slightly different jobs [ed: also dividing is very expensive!]
- passed all the unif variables in one or two arrays, slightly artificial putting three not very related floats into one vec3 but saves loads of time!
- passed all the matrices in one array (both, I'm not using a normal matrix)
- moved as much as possible from fragment to vertex shader
- moved as much as possible from vertex to python. This later is a bit of a trade-off which probably wouldn't apply in tight C code but the gpu is *very* fast so it can often do a calculation 6 times (for a plane say) in much less time than python can do it once.
I think the only way to get info out of the gpu is as an image, ie glReadPixels or suchlike. Might be quite a lot of work and I'm not sure there's a lot of information available in the shader to send back (like time; I suspect the gpu works in a parallel dimension where time has a different meaning).
- got rid of all ifs from the shaders (well you need a couple to discard fragments etc) this means lots of different shaders to do slightly different jobs [ed: also dividing is very expensive!]
- passed all the unif variables in one or two arrays, slightly artificial putting three not very related floats into one vec3 but saves loads of time!
- passed all the matrices in one array (both, I'm not using a normal matrix)
- moved as much as possible from fragment to vertex shader
- moved as much as possible from vertex to python. This later is a bit of a trade-off which probably wouldn't apply in tight C code but the gpu is *very* fast so it can often do a calculation 6 times (for a plane say) in much less time than python can do it once.
I think the only way to get info out of the gpu is as an image, ie glReadPixels or suchlike. Might be quite a lot of work and I'm not sure there's a lot of information available in the shader to send back (like time; I suspect the gpu works in a parallel dimension where time has a different meaning).
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d
-
dom
- Raspberry Pi Engineer & Forum Moderator
- Posts: 5502
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: GLES2 optimisation?
Make sure all messags go from ARM to GPU. Every read from GPU causes the pipeline to be flushed which is very expensive. This includes glGetError. Only include glGetError in a macro that is disabled for release builds.
Re: GLES2 optimisation?
Thanks for the tip dom. I'm currently trying to optimize dosbox for public consumption.dom wrote:Make sure all messags go from ARM to GPU. Every read from GPU causes the pipeline to be flushed which is very expensive. This includes glGetError. Only include glGetError in a macro that is disabled for release builds.