glenalec
Posts: 12
Joined: Tue Dec 13, 2011 3:32 am
Location: Wollongong, Australia
Contact: Website

Code between framebuffer and output?

Mon Oct 22, 2018 1:13 am

(Hoping this is a suitable forum - the query seems more bare-metal-ish than graphics-ish - it is certainly a very very low-level query, well below any potential OS-layer! TBH, if no-one can answer it, I won't be overly surprised, it is very obscure :-) )

I am wondering if the VideoCoreIV subsystem has the ability to do some custom color-space conversion between the final framebuffer and the video output (HDMI, DSI, DPI).

It would be convienient* to have my frame buffer in a non-RGB format** and have a small bit of code running between the framebuffer and the RGB encoder(s) on the HDMI/DSI/DPI lines to convert to RGB at the absolute last stage of my graphics pipeline. Code would be running on some part of the VidCore subsystem (assuming it has support for such things) on a custom VidCore software stack (luckily I only need 2D acceleration, for now at least).


* Last-stage conversion is not absolutely necessary - I could do the colorspace conversion on the way to the framebuffer if I had to, but doing it at the last possible stage appeals to my sense of neatness. (Another alternative I am playing with is outputting my custom color space as-is on the HDMI RGB port (I'm sure the hardware doesn't actually care what the bits represent, as long as they align with what it expects) and using a HDMI-in-out equipped FPGA board to do the conversion in an in-line dongle. However on-boarding the conversion in software would, obviously, be easier than messing around with external quasi-hardware solutions).

** Think something L*a*b*-like (Y-B, R-G, Luminance) but without the rigorous color-correctness requirement - I have a fairly simple integer algorithm relying mainly on adds, inverts, and shifts worked out for the actual conversion.

glenalec
Posts: 12
Joined: Tue Dec 13, 2011 3:32 am
Location: Wollongong, Australia
Contact: Website

Re: Code between framebuffer and output?

Mon Oct 22, 2018 1:18 am

Also note, for now I am not asking for details on /how/ to do it, just if VideoCoreIV can support doing such a thing.

LdB
Posts: 872
Joined: Wed Dec 07, 2016 2:29 pm

Re: Code between framebuffer and output?

Mon Oct 22, 2018 2:58 am

I can't really work out what you are trying to do so I can only sparse comment.

Typically on the VC4 you would do colorspace conversion by simply using a shader in the GL pipeline the destination a framebuffer the source whatever format your data is in. If you look at OpenGL there are a myriad of GLSL colorspace conversion shaders samples on net. In operation the GLSL code gets converted to VC4 assembler code by the shader compiler and gets injected into the VC4 pipeline to execute so the VC4 manhandles the conversion of your format to display.

There is a compositor on the GPU but I have a feeling the "buffers" (I believe they are an abstraction) must be one of the standard RGBA formats from code I have seen. A couple of the mods play around in that space and may drift by and expand.


jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20751
Joined: Sat Jul 30, 2011 7:41 pm

Re: Code between framebuffer and output?

Mon Oct 22, 2018 3:48 pm

There are some registers to allow the final HVS output to have a colour correction, but they are not used, and not apaprently expose via an API. Is this the sort of thing you are after?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

bzt
Posts: 177
Joined: Sat Oct 14, 2017 9:57 pm

Re: Code between framebuffer and output?

Fri Nov 09, 2018 5:03 pm

glenalec wrote:
Mon Oct 22, 2018 1:13 am
It would be convienient* to have my frame buffer in a non-RGB format**
You can do that. Right now there's only RGB and BGR defined (no YCMK or YUV), but since the state uses u32, there's space for more formats in the future.

Until then you could also try to use a palette, another non-RGB framebuffer, where you can pre-calculate 256 different color values, and only write byte indeces to the framebuffer (seriously limited by the maximum number of colors, but could be enough for certain applications).

Imho the best solution (as already suggested by @LdB) don't mind the framebuffer pixel format, use a shader to convert from your colorspace to the VC's.

bzt

Return to “Bare metal, Assembly language”