[hatari-devel] Suggestion about small additions for v1.4

Eero Tamminen eerot at users.berlios.de
Mon May 17 20:09:18 CEST 2010


Hi,

On Sunday 16 May 2010, Kåre Andersen wrote:
>> For scaling I can easily see OpenGL being faster (the 3D HW is
>> accessing pixels already in dedicated/faster 3D HW memory), but if
>> there's a  significant performance difference when just blitting data
>> from "CPU owned" RAM like happens in normal Hatari case, there just
>> must be something really screwed in OSX SDL graphics pipeline.
>
> Something is indeed very much screwed in the OSX SDL 1.2 pipeline...
> But unfortunately, performance is still lackluster (~40% cpu on 2.4Ghz
> Core2Quad) with OpenGL blits. Atleast its possible to scale to any
> arbitrary size with no cpu cost...

Basically 3D HW / OpenGL helps with performance only in the cases where
you're dealing with lots & complex geometry and where your texture content
is static.  If all you use it for is pushing constantly updating texture
content and basically no geometry, it can be even slower than using CPU
for that.

E.g. in Omap3, doing something like memcpy with the 3D HW gives you maybe
1/5 of performance of doing it with CPU.  This is because it's running at
1/5 speed while using the same memory as CPU (and neither that nor AFAIK x86
provide cache coherency between CPU and GPU i.e. control transfer implies
a cache flush).  If you can do it asynchronously to the CPU and your CPU is
otherwise fully occupied, you may still get some performance advantage on
shared memory systems, but if you have a discrete graphics card, this
depends on how much slower your HW interface (PCI/AGP/PCI-E) to the graphics
card is compared to your RAM.


> > It's possible that in the OpenGL case it's just a question that then
> > the program can tell when the display updates should be synched to
> > Vsync().
>
> Well, for the first time I am seeing the same tearing on OS X as i get
> in linux... OS X forces double buffering (in window mode), but gives
> the user no way to synchronize to the VBL... OpenGL context windows
> bypass this buffering.
>
>> Btw. When doing anything with OpenGL, please use (ES subset of) the
>> OpenGL v2 API.  Skip OpenGL v1, stuff it's not really portable to
>> devices that are soon to be going to be majority of the devices people
> > have.
>
> OpenGL ES is not for desktop systems, and iirc version 2 looses the
> state machine completely (OpenGL ES 2 != OpenGL 2.x).

No, the difference concerns fixed functions, but that is really a difference
between focus in OpenGL v1.x and later OpenGL versions, it's nothing
specific to ES subset of the OpenGL API.

Newer full OpenGL API is actually closer to ES API than v1.x API.

The issue I'm after, is that although the full OpenGL API is backwards
compatible to earlier OpenGL versions (e.g. through software fallbacks),
the v2.x ES subset of the OpenGL API drops support for the fixed function
APIs from v1.x.

http://en.wikipedia.org/wiki/OpenGL_ES


> Sure, its nicer 
> to program, but not really useful for us OS X users. However, I dont
> see any reason not to support ES in addition - it would just be an
> entirely different codepath. The one does not exclude the other...

What I'm suggesting is avoiding v1.x OpenGL specific API and using
the ES *subset* of OpenGL 2.x API, not the ES extensions.


	- Eero



More information about the hatari-devel mailing list