I was thinking that the system would work in 16 bit more - 565 and just convert to 18 bit. i.e. the composition happens at 16 bit, not 32. It's definitely an overhead though. Is the screen update done via an eglSwapBuffers call on a single composited surface representing the screen? It might not take very long to try it? and could be faster than the overheads bought about by dealing in 18 bit or 32 bit land when rendering (more bandwidth needed - particularly if pixels are touched multiple times). No obvious winner - it just might be quick to try.
Presumably the rendering routines in the software GL library would also have to be modified (unless the platform is using hardware). Mathias Agopian <[EMAIL PROTECTED] gle.com> To Sent by: android-porting@googlegroups.com [EMAIL PROTECTED] cc ooglegroups.com Subject [android-porting] Re: Android 02/12/2008 09:43 porting problem - LCD BPP Please respond to [EMAIL PROTECTED] ooglegroups.com On Tue, Dec 2, 2008 at 1:25 AM, Phil HUXLEY <[EMAIL PROTECTED]> wrote: > Alternatively, couldn't a blit be inserted somewhere such that a conversion > is done at the point of updating the display (and would this include a > regionlist of areas that have changed to optimise it?). Is there such an > 'update point'? I think this would be slower generally. You'd end up doing all the composition in 32-bits, and then doing another copy/conversion by hand. I don't think it buys you anything. Also this would not match the EGL model very well, which SurfaceFlinger (very purposedly) relies on. In my experience update regions don't buy you much because the case you care about is when you're "flinging" a list and that tends to update the whole screen; surfaceflinger uses them though. I should have mentioned in the email before that pixelflinger has some logic to be able to replace the generated code by hand-written routines (see scanline.cpp). You'd want to do this for a few common operations like: RGBA32 -> RGB18 with and without blending. I think the code it'll generate won't be bad at all, but you'll be able to use pld() and/or process several pixels at a time. One of the annoying part will be to chose a new constant for the new format. The namespace for those is limited and global to the platform (there are no way -yet- to create pixel formats dynamically at runtime -- which the codegen should be able to handle). We just need to be absolutely sure that whichever value we pick won't conflict with future version of the platform (I already added a few formats post 1.0). Mathias > > > > > > > Mathias Agopian > <[EMAIL PROTECTED] > gle.com> To > Sent by: android-porting@googlegroups.com > [EMAIL PROTECTED] cc > ooglegroups.com > Subject > [android-porting] Re: Android > 02/12/2008 09:14 porting problem - LCD BPP > > > Please respond to > [EMAIL PROTECTED] > ooglegroups.com > > > > > > > > On Mon, Dec 1, 2008 at 11:03 PM, FlyCry <[EMAIL PROTECTED]> wrote: >> >> My lcdc support 2 format of 18bpp framebuffer. One is 18bpp packed. >> Another is a format of 3 byte: >> Red[5:0] 0 0 Green[5:0] 0 0 Blue[5:0] 0 0 >> could the second format be configed in android display? > > So there are no mode where it has the color components in the higher 6 > bits?! > > There is a way to configure pixelflinger to be able to render into > arbitrary bit-patterns, however, the format you're describing has > never been tested (obviously). It would also be a huge performance hit > because: > 1) we would have to make sure all windows are created in 32-bits (only > mode > 16 bits supported by the software render), which also implies > much higher memory usage and bus pressure > 2) the 32-bits surface will have to be converted at runtime and in > software to 18 bits. > > To make it work you'd have to add a new pixelformat describing your > framebuffer to pixelflinger, then you would have to make sure the code > that handles the framebuffer (EGLNativeDisplay.cpp) returns that. > You'd have to modify surfaceflinger to always create 32-bits surfaces. > Currently there is no abstraction for all these aspects, so it'll have > to be hacked in. > > On top of that, you'll have to replace all the 16-bits assets (because > you wouldnt' get any benefit otherwise). > > Performance will likely be bad do to the increased bus pressure, > memory usage and CPU pressure needed for conversion. > > > I can't believe the framebuffer cannot be configured to 32-bits like this: > xxxxxxxxbbbbbb00gggggg00rrrrrr00 > this wouldn't cost anything more in h/w (just more address space, but > who cares?), and it would be a lot more efficient from a software > point of view. > > mathias > > >> Thanks. >> >> On 12月2日, 下午12时42分, Mathias Agopian <[EMAIL PROTECTED]> > wrote: >>> Hi, >>> >>> On Mon, Dec 1, 2008 at 8:22 PM, FlyCry <[EMAIL PROTECTED]> wrote: >>> >>> > My board has an lcd of 18 bpp, but android UI is 16 bpp. So the >>> > display is abnormal when andriod runs. Could android be configed to 18 >>> > bpp? And how to do it? >>> > Thanks for anyone attention to this topic. >>> >>> What's the format of your 18bpp framebuffer? (hopefully it's not 18bpp > packed!). >>> >>> Mathias >> > >> > > > > ForwardSourceID:NT000040E6 > > > ForwardSourceID:NT000040F6 --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---