An API that doesn't require mixed-mode rendering gets my vote (Ask anyone
who had to wrestle with JSR-184 in the java world - there was one instance
of a benchmark that effectively halved the frame rate acheived by drawing
the 'fps' value using Java - not many pixels touched, but ugly
uploads/downloads). Presumably an Application would get a special GL
window that then could not be drawn to using software? GL programmers are
well used to avoiding mixed-mode rendering, it has always been a
significant performance issue. It would be better to composite UI stuff on
top of GL stuff using different windows. The issues of making a GL app go
fast is a separate issue from making the composition work well.
That coupled with a full-screen optimisation will make a significant
performance diffecence to an OpenGL ES game.
ETA - Does high priority mean sometime in H1 2009?
Mathias Agopian
<[EMAIL PROTECTED]
gle.com> To
Sent by: android-porting@googlegroups.com
[EMAIL PROTECTED] cc
ooglegroups.com
Subject
[android-porting] Re: Use of 3D
26/11/2008 10:30 Hardware Accelerator
Please respond to
[EMAIL PROTECTED]
ooglegroups.com
On Wed, Nov 26, 2008 at 2:10 AM, Phil HUXLEY <[EMAIL PROTECTED]>
wrote:
>
> Thanks Mathias,
>
> - So in the world of enabling GL rendering and software rendering to the
> same surface (and related copies), whet are the points that require the
> buffer to be copied and does the copy need to go both ways - for example
if
> the following happens...
>
> GL rendering
> SW rendering -> Implies that the GL buffer is uploaded.
> More GL rendering.. -> Implies that the Buffer is downloaded
> again (so that the render target contains both Previously rendered GL
stuff
> and SW stuff)
> More SW rendering -> Implies another upload of the GL buffer
> Update the screen -> Assorted buffers are composited onto the
screen.
Basically you'd need to hook up eglWaitGL() and eglWaitNative()
properly. As I said, it becomes ugly.
Android requires that you'd be able to draw into your surfaces with
the CPU, and that these can be used as textures (in another process).
Generally, we don't need to be able to draw in a given surface with
both the CPU and GPU, but the current API doesn't allow to not support
this. The new API will.
> - There is an EGL extension called EGL_lock_surface which is a
requirement
> for OpenKODE, that enables sw access to a GL buffer (this doesn't mean
that
> no copies will be going on). Not sure how widely supported this is. You
> could base your implementation on using this extension (OpenKODE is
gaining
> momentumn) - and driver writers will either strive to support it
> efficiently, or use copies (which would probably be needed anyway). The
> Lock/Unlock of a surface demarks when it's possible to use one over the
> other.
This sounds like a good idea.
> - Are there any optimisations that kick in if the GL window is
full-screen
> so that compositing becomes nothing more than a buffer swap? In the
> quality games world, this is actually what you want.
There are not at the moment, but such an optimization in planed. It
will be implemented in SurfaceFlinger.
> - Thanks for the pointer w.r.t. getting going if we reallllly want to,
the
> performance might be ugly though.
It may not be that bad depending on your h/w. If your screen is not
too big (QVGA or HVGA) and if you have a good bandwidth between the
GPU and main memory; it depends on your h/w really. A 2 ms overhead
for instance would be acceptable. When you're approaching 5 or 6 ms,
it starts getting too high.
> - Do you have an ETA for the OpenGL ES HAL ? It's not on the published
> roadmap.
No ETA, but It is high on the list of priorities.
Mathias
ForwardSourceID:NT00003A56
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
