Android porting problem - LCD BPP

[FlyCry]

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.

[Mathias Agopian]

Hi,

What's the format of your 18bpp framebuffer? (hopefully it's not 18bpp packed!).

Mathias

[FlyCry]

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?
Thanks.

On 12月2日, 下午12时42分, Mathias Agopian <pixelflin...@google.com> wrote:
> Hi,
>

[Mathias Agopian]

On Mon, Dec 1, 2008 at 11:03 PM, FlyCry <flyc...@gmail.com> 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

[Phil HUXLEY]

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'?






Mathias Agopian
<pixelflinger@goo
gle.com> To
Sent by: android...@googlegroups.com
android-porting@g cc
ooglegroups.com
Subject
[android-porting] Re: Android
02/12/2008 09:14 porting problem - LCD BPP


Please respond to
android-porting@g
ooglegroups.com

ForwardSourceID:NT000040E6

[Mathias Agopian]

On Tue, Dec 2, 2008 at 1:25 AM, Phil HUXLEY <phil....@3dlabs.com> 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

[Phil HUXLEY]

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
<pixelflinger@goo
gle.com> To
Sent by: android...@googlegroups.com
android-porting@g cc
ooglegroups.com
Subject
[android-porting] Re: Android

02/12/2008 09:43 porting problem - LCD BPP

ForwardSourceID:NT000040F6

[Mathias Agopian]

On Tue, Dec 2, 2008 at 1:52 AM, Phil HUXLEY <phil....@3dlabs.com> wrote:
> 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

What's the point of using a 18-bits framebuffer if most graphics are
done in 16-bits? I assumed, the goal would be to take advantage of the
extra 2 bits

> definitely an overhead though. Is the screen update done via an
> eglSwapBuffers call on a single composited surface representing the screen?

yes

> 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).

No, in this scenario, they would be rendering into a 565 buffer as
usual, which would be composited in 565, and eventually converted to
666 during eglSwapBuffers(). GL doesn't need to be changed, just the
implementation of the EGLNativeWindowType.


Unless the panel cannot be configured to 565 (that would be crazy), I
wouldn't go down that road, if it's not going to improve visual
quality.

[Phil HUXLEY]

Perhaps I wasn't being clear enough. Some LCD panels do have 18 bits per
pixel, but use some (2 or 3) of those bits for other things (can't remember
what), so the actual colour resolution is 16 bits or less.

All I was suggesting was stay in a traditional 565 domain until the final
buffer swap to the screen (i.e. don't change any of the rendering side -
not even the configs), but do as efficient a conversion as possible on the
final swap - potentially easy to do if that final swap can be singled out.

Mathias Agopian
<pixelflinger@goo
gle.com> To
Sent by: android...@googlegroups.com
android-porting@g cc
ooglegroups.com
Subject
[android-porting] Re: Android

02/12/2008 10:09 porting problem - LCD BPP

ForwardSourceID:NT0000410E

[FlyCry]

Thanks for your helpful replies.
Acctually, my lcdc support 24-bits packed framebuffer to 18-bits
output to suit the 18bpp lcd. The framebuffer format is
rrrrrr00gggggg00bbbbbb00, packed.
I configed pixelflinger as RGB888. That could compatible to the 24-
bits packed framebuffer. But I found the red and the green exchanged
their place. Is android's default color space BGR but not RGB? The
hardware can't swap red and green. Is there anything I can do to make
android swap red and green.
Thanks a lot.

On 12月2日, 下午6时39分, Phil HUXLEY <phil.hux...@3dlabs.com> wrote:
> Perhaps I wasn't being clear enough. Some LCD panels do have 18 bits per
> pixel, but use some (2 or 3) of those bits for other things (can't remember
> what), so the actual colour resolution is 16 bits or less.
>
> All I was suggesting was stay in a traditional 565 domain until the final
> buffer swap to the screen (i.e. don't change any of the rendering side -
> not even the configs), but do as efficient a conversion as possible on the
> final swap - potentially easy to do if that final swap can be singled out.
>
> Mathias Agopian
> <pixelflinger@goo
> gle.com> To
> Sent by: android...@googlegroups.com
> android-porting@g cc
> ooglegroups.com
> Subject
> [android-porting] Re: Android
> 02/12/2008 10:09 porting problem - LCD BPP
>
> Please respond to
> android-porting@g
> ooglegroups.com
>

> > On Tue, Dec 2, 2008 at 1:25 AM, Phil HUXLEY <phil.hux...@3dlabs.com>

> ForwardSourceID:NT0000410E- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Mathias Agopian]

On Tue, Dec 2, 2008 at 11:45 PM, FlyCry <flyc...@gmail.com> wrote:
>
> Thanks for your helpful replies.
> Acctually, my lcdc support 24-bits packed framebuffer to 18-bits
> output to suit the 18bpp lcd. The framebuffer format is
> rrrrrr00gggggg00bbbbbb00, packed.
> I configed pixelflinger as RGB888. That could compatible to the 24-
> bits packed framebuffer. But I found the red and the green exchanged
> their place. Is android's default color space BGR but not RGB? The
> hardware can't swap red and green. Is there anything I can do to make
> android swap red and green.

you mean red and blue, right?

SurfaceFlinger should be using RGB (a byte of red followed by a byte
of green, followed by a byte of blue). Unless there is a bug in
pixelflinger, that's what it should do. I will check tomorrow if this
is working properly (I don't think 24-bits mode have ever been used
before).


Mathias

[FlyCry]

Yes, red and blue.
Thanks!

On 12月3日, 下午4时20分, Mathias Agopian <pixelflin...@google.com> wrote:

> >> - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Mathias Agopian]

As far as I can tell from a quick inspection of the code, pixelflinger
reads and outputs RGB24 formats as R,G,B as it should.

Are you sure your framebuffer takes RGB and not BGR? Also are you
using "PIXEL_FORMAT_RGB_888" when initializing the frame-buffer
surface?

you can see the routines in pixelflinger/codeflinger/load_store.cpp

mathias

[FlyCry]

In my opinion, RGB means red in the high byte and blue in the low
byte. But it seems that andriod use red in the low byte and blue in
the high byte. I modified the code of load_store.cpp to exchange red
and green. Now the display is Ok.
Thank you very much.

> ...
>
> 阅读更多 >>- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Mathias Agopian]

On Wed, Dec 3, 2008 at 8:37 PM, FlyCry <flyc...@gmail.com> wrote:
>
> In my opinion, RGB means red in the high byte and blue in the low
> byte. But it seems that andriod use red in the low byte and blue in
> the high byte. I modified the code of load_store.cpp to exchange red
> and green. Now the display is Ok.
> Thank you very much.

The notion of "high" byte and "low" byte in a 24-bits frame buffer is
a little odd. Since these are not 32 bits or 16 bits numbers, I'm not
sure what you mean.

I stand by what I said, android supports RGB, in that order. One byte
of red, one byte of green, followed by one byte of blue. R,G,B... btw,
this order happens to be OpenGL's GL_RGB internal format for textures.

You *cannot* change load_store.cpp like that, you have now broken
OpenGL's glTexImage2D() :-(

Mathias

[gogofly]

Greeting,
Now 16 BPP is used at FB driver and surface flinger, but blue color
has more weight on the display, I don't know why?
The 16 BPP format is: RRRRRGGGGGGBBBBB (RGB565) in the fb driver, is
the surface flinger different data format with driver?Thanks!
Mark

On Dec 4, 12:47 pm, Mathias Agopian <pixelflin...@google.com> wrote:

> ...
>
> read more >>- Hide quoted text -
>
> - Show quoted text -

[David Given]

Mathias Agopian wrote:
[...]

> The notion of "high" byte and "low" byte in a 24-bits frame buffer is
> a little odd. Since these are not 32 bits or 16 bits numbers, I'm not
> sure what you mean.

People typically use the same order that the equivalent 32-bit format
would be. So the first byte, red, is the LSB and the last byte, blue, is
the MSB.

> I stand by what I said, android supports RGB, in that order. One byte
> of red, one byte of green, followed by one byte of blue. R,G,B... btw,
> this order happens to be OpenGL's GL_RGB internal format for textures.

Just to make life more complicated, if you look at a GL_RGB pixel in a
word, what you usually see is:

<- MSB LSB ->
00000000bbbbbbbbggggggggrrrrrrrr

...which causes a lot of people to refer to this as BGR. Just to make
life even *more* confusing, the same school of thought will happily
refer to the exact same format as RGB if they're on a big-endian system.

Which is why it's always really useful to follow Mathias' lead and use
the GL_ names. They're at least well-defined!

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ ⍎'⎕',∊N⍴⊂S←'←⎕←(3=T)⋎M⋏2=T←⊃+/(V⌽"⊂M),(V⊝"M),(V,⌽V)⌽"(V,V←1⎺1)⊝"⊂M)'
│ --- Conway's Game Of Life, in one line of APL

[Mathias Agopian]

On Thu, Dec 4, 2008 at 3:55 PM, David Given <d...@cowlark.com> wrote:
> Mathias Agopian wrote:
> [...]
>> The notion of "high" byte and "low" byte in a 24-bits frame buffer is
>> a little odd. Since these are not 32 bits or 16 bits numbers, I'm not
>> sure what you mean.
>
> People typically use the same order that the equivalent 32-bit format
> would be. So the first byte, red, is the LSB and the last byte, blue, is
> the MSB.
>
>> I stand by what I said, android supports RGB, in that order. One byte
>> of red, one byte of green, followed by one byte of blue. R,G,B... btw,
>> this order happens to be OpenGL's GL_RGB internal format for textures.
>
> Just to make life more complicated, if you look at a GL_RGB pixel in a
> word, what you usually see is:
>
> <- MSB LSB ->
> 00000000bbbbbbbbggggggggrrrrrrrr
>

I don't understand what "looking at a GL_RGB pixel in a word" means. A
word has 32 bits, GL_RGB has 24. What you see in the word depends on
how you read that word in the first place. you could have done an
aligned access at the address of where R is (in which case you'd have
the next pixel's R in the top byte and not zeros), or you could have
done an unaligned access at the address just before, or you could have
read all components one byte at a time and merge them back together...
etc...

> ...which causes a lot of people to refer to this as BGR. Just to make
> life even *more* confusing, the same school of thought will happily
> refer to the exact same format as RGB if they're on a big-endian system.
>
> Which is why it's always really useful to follow Mathias' lead and use
> the GL_ names. They're at least well-defined!

Agreed :-)
Also, as I pointed out before, the change that was made to the source
code to "make it work", breaks GL_RGB.

Mathias

[David Given]

Mathias Agopian wrote:
[...]

> I don't understand what "looking at a GL_RGB pixel in a word" means. A
> word has 32 bits, GL_RGB has 24.

Well, I thought it was pretty obvious --- you load your 24 bits, in
natural order, into the bottom end of a quad, exactly the same way that
you'd load a 32 bit value or a 16 bit value or an 8 bit value!

The only thing that makes it the slightest bit complicated is that
GL_RGB is unaligned so you wouldn't be able to use a simple LDR
instruction, but that's just an implementation issue.

[FlyCry]

Hi, Mathias. Sorry to reply until now, cause somthing else I have to
deal with in my job.
I modified the assembly code of load_store.cpp. You mean that it would
break GL_RGB? So if LCDC needs a BGR framebuffer, but android gives an
RGB. What can I do to work it out? Could android give BGR display?

>  signature.asc
> < 1K查看下载

[Mathias Agopian]

Hi,

I talked about this a little bit in my 2nd answer to this thread. You
will have to create a new BGR pixel-format and use this one. Adding a
pixel format to the system is not too hard, but it requires adding a
constant into multiple files (and make sure they all match).

For your information, a 32-bits BGR format has been added to the
system after 1.0 was released (it is needed for the GPU to render into
32-bits surfaces).

Have a look at pixelflinger's format.cpp, this is where the
pixelformats are defined, it will ripple from there (the corresponding
header file has a list of the other files that must be updated).

Eventually, I should define all the useful pixelformat enums somewhere
so that we don't have collisions when people add new formats.

In theory pixelfinger can handle pretty much any pixel configuration;
so we could add a mechanism to create formats at runtime, which would
also avoid the namespace problem.

Mathias

[FlyCry]

When I try to add a new pixel format for my board, I found a macro
GGL_PIXEL_FORMAT_RGB_888 = 3, // 3x8-bit RGB
I can use this format. Because the LCDC can use this 3x8-bit
framebuffer to BGR666 output.
And also I modified the EGLDisplaySurface.cpp to
GGL_PIXEL_FORMAT_RGB_888.
At that moment, I found red and blue are exchanged. Because of LCDC
BGR666 output.
So I modified load_store.cpp to exchange red and blue.
Will the whole modified code break OpenGL? Or if I want to use
GGL_PIXEL_FORMAT_RGB_888, is there any way to make it to BGR without
any change to load_store.cpp?
Thanks

> >> < 1K查看下载- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Mathias Agopian]

Hi,

On Mon, Dec 8, 2008 at 6:19 PM, FlyCry <flyc...@gmail.com> wrote:
>
> When I try to add a new pixel format for my board, I found a macro
> GGL_PIXEL_FORMAT_RGB_888 = 3, // 3x8-bit RGB
> I can use this format. Because the LCDC can use this 3x8-bit
> framebuffer to BGR666 output.
> And also I modified the EGLDisplaySurface.cpp to
> GGL_PIXEL_FORMAT_RGB_888.
> At that moment, I found red and blue are exchanged. Because of LCDC
> BGR666 output.
> So I modified load_store.cpp to exchange red and blue.
> Will the whole modified code break OpenGL?

Yes.

> Or if I want to use
> GGL_PIXEL_FORMAT_RGB_888, is there any way to make it to BGR without
> any change to load_store.cpp

Yes. You need to create a new format, with a new unused constant. The
constant is a index in an array in pixelflinger/format.cpp -- you need
to add the format's description there (just swap the values for R and
B). Make sure EGLDisplaySurface.cpp returns your new format.

And it should just work :-)

Mathias

[FlyCry]

Thanks a lot!
I'll try it.

On 12月9日, 上午11时00分, Mathias Agopian <pixelflin...@google.com> wrote:
> Hi,
>

> >> - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[FlyCry]

Thank you, Mathias!
I have succeed in 18 bpp display at andriod with your great help.