Graphics Performance

[Iain B. FIndleton]

It appears to me that the implementation on the FR is not capable of 
moving an updated frame buffer in memory to the chip's video buffer, 
presuming they are different, without draping. Since the controller 
appears to be able to rescan its own video buffer without flicker, I 
wonder what the issue is in moving the frame buffer data? At the speeds 
available on the FR, moving 640 x 480 x 2 = 614,400 bytes from memory to 
a video buffer at 30 Hz needs about 18 MB/sec.

What is the bandwidth for memory moves?


Carsten Haitzler (The Rasterman) wrote:
> 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. :(
>
>