Graphics Performance

Carsten Haitzler (The Rasterman) raster at rasterman.com
Fri Apr 3 15:38:22 CEST 2009


On Fri, 3 Apr 2009 14:25:48 +0100 Thomas White <taw at bitwiz.org.uk> said:

> On Sat, 4 Apr 2009 00:01:16 +1100
> Carsten Haitzler (The Rasterman) <raster at rasterman.com> wrote:
> 
> > beware of jumping all over 3d as the solution. i have recently been
> > working on a gles2 engine for evas. i have run it on 2 platforms
> > (s3c6410 and omap3530). both with hardware opengles2 (and capable of
> > high res etc.) and software beats gles2. yes - evas software
> > rendering is faster. oddly enough the movial guys and trolltech (qt)
> > guys see the exact same performance problems. gl is slower (i know
> > that i and the trolls have seen about a 1/4 speed of gl vs software).
> 
> I'm really interested as to why this might be the case.  Do you have
> any ideas?  Something like the increased overhead of the extra API and
> latency associated with swapping contexts?

not 100% sure. at first i thoguht maybe lots of context changes. i cleaned that
up and had them changed as little as possible - only got about 10% more. what
i'd expected. i suspect the gl scissor ops simply dont optimally clip
operations early in the rendering (at the geometry stage) like the do in
software (evas's clips clip really early). but i have yet to prove that.

software is capable of being smarter. gles is stuck in the "Render the whole
window or nothing" phase. anything else doesnt work or is not supported or is a
software path anyway. so you have to re-render the whole backbuffer just to
update 1 button that changed. of course as long as both are rendering the whole
buffer - they are on even ground, but software can take more optimal paths and
only re-render sub-sections. i also know the gles drivers perform excess
memcpy's of data (with the cpu) to get it to the screen - software engine is
able to avoid at least 1 copy there (when in 32bbpp). texture "uploads" are a
big drain on performance - so if you have dynamic data (video or generated
pixels) software beats gl by a wide margin as it can do this "zero copy". gl
requires a texture upload. gles2 also requires everything be a shader - there is
no more fixed pipeline. you have lots of problems here when it comes to quality
of the shader compiler - and even if it is implemented at all. it's a black
box. but as of gles2 you have no choice - you MUST use shaders. also i suspect
there is a bit of nastiness in always having to put all draw ops through the gl
transform matrix - when really all the code is doing is trying to pass pixel
coordinates. another problem is RGBA va ARGB. ARGB is by far and wide the most
common 2d pixel format. but the gles committe in their infinite wisdom decided
to only support RGBA - thus you are forced to either swizzle from ARGB to RGBA
at tex upload time... overhead, or do it at draw time in the shader - possibly
impacting performance a bit.

but these are just my set of things i am sure have some impact. but i really
have not found a good reason for the big difference. gl hardware should SPANK
software's butt. by a country mile. but it doesn't. :(

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com





More information about the community mailing list