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 --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
