[OMAP3530] SGX Pixel Format Output

Andy,

I am not sure I understand "I am not looking to use the DSS as I don't want to output the data to DVI, LCD or analog TV" ? The DSS does not really care what it is connected to, and simply pushes out up to 24 bits of data continually.

The display sub-system can basically be configured to dump memory to the output port in various bit widths up to 24 bits. Alternatively it can implement scaling, blending etc... between up to three memory sources.

Is your objective to blend with some externally generated video source or are all your sources available withing OMAP?

Regarding the SGX, it can only render in either 16 bit 565 or 32 bit 8888 formats.

In order to do what you need it would be necessary to have the SGX render in 32 bit 888 then use NEON to pack into 24 bit 5658 format, which the DSS could then pass out.

Depending on what your source video format is, it might be possible to feed the video to the OMAP camera in port and do the blending completely inside OMAP rather than an FPGA?

What exactly is your topology and video formats etc...?

BR,

Steve

Steve,

Sorry for the vagueness of my question, I have recently started looking at the OMAP3530 device and I am not completely familiar with it yet!

The objective is effectively to blend custom generated graphics from the OMAP3530 (I.e. menus and HUD style graphics) onto some external video. This video will not be available to the OMAP and so it is important that colour information including an alpha value can be received from the output port. This way the FPGA will blend the graphics and external video using the 8-bit alpha value. I think the idea of doing it this (in the FPGA) was is to remove any latency on the video that could be caused if the OMAP performed the blending.  The video will initially be in a digital format and the FPGA will be used convert the video into various standards.

Is there any help available on both setting up the DSS and using NEON to pack the RGBA8888 output into RGBA6568?

Thanks very much,

Andy

Andy,

It may be a little complex for you to externally blend and merge the 2 video streams since the frame rates will potentially be both slightly different and not aligned. This means that your FPGA will need to buffer at least one of the streams to do frame synchronization. If you can synchronize the external video to the OMAP output then you will be OK, but I wanted to make you aware of this asynchronous issue you will otherwise find.

This is not an OMAP specific issue, but a general issue when trying to merge 2 independent video sources. Even if they are supposedly the same frame rate, they will not be unless specifically frame locked.

Regarding the DSS, it is pretty simple to configure and there are examples and documentation available for both direct hardware configuration and through Linux if you are using an OS. The Linux documentation should have some documentation. For direct hardware access I can send you example code.

You may also want to look at the following web pages.

http://wiki.omap.com/index.php/Display_Subsystem

http://wiki.omap.com/index.php/Adding_new_DVI_resolutions

http://wiki.omap.com/index.php/LCD_connectivity

http://wiki.omap.com/index.php?title=Category:OMAP35x

BR,

Steve

Steve,

Thank you for the wiki links,

To avoid buffering the entire frame, what we propose is that we will interrupt the OMAP from the FPGA at the beginning of each video field (the beginning of the field as understood by the FPGA).  The software will respond to this interrupt and reset the read pointer to the video buffer in the OMAP device.  There will be some variability in the time software takes to activate this reset, but this will be accommodated by the buffer in the FPGA. We believe this should help us synchronise the graphics output with the video stream in the FPGA.

Regards,

Andy

Andy,

It is not just a simple case of changing the OMAP read pointer unfortunately.

OMAP internally synchronizes register updates to its own timing, so any changes to read pointers will not occur until the display sub-system reaches the end of its output frame. This is so that it is not necessary for software to be precise in updating registers since the hardware will transfer the shadow registers to the hardware during blanking.

Unfortunately, this is exactly NOT what you want in your application.

Basically, making OMAP a slave to some external video sync is not easy.

I will check to see if it is even possible, since the only way I can think of synchronizing at the moment is to reset the controller, but then you will have a few frames delay before the re-configuration is completed.

One possibility is to change the OMAP output blanking time on a frame to frame basis to try and align the video sources. This would work since it would not disrupt the actual video stream output from OMAP. This would not be able to quickly respond to large changes in master frame rate though, and would kinda work like a PLL where you would be making OMAP track the master video through a feedback loop.

BR,

Steve

Hi Steve,

Referring back to your answer to my question about the RGB565+A8 pixel format:

Steve Clynes said:

In order to do what you need it would be necessary to have the SGX render in 32 bit 888 then use NEON to pack into 24 bit 5658 format, which the DSS could then pass out.

I am still a bit unsure how I would go about doing this. I am able to create a 'packing' function using neon instructions to convert RGBA8888 to RGBA5658 but I am not sure how I would obtain the output of the SGX to act as an input to my packing function and how I would send the output of the my packing function to the DSS.

Can you provide any help on this at all?

Thanks,

Andy

Andy,

The SGX simply renders to a buffer in memory (which is subsequently displayed under normal conditions), so the trick is really to know where this buffer is.

I will ask our SGX expert to jump in to this conversation to help discuss the buffer access.

BR,

Steve

Andy,

   There are 3 types of off-screen buffers the SGX can render to, Pixmaps, pBuffers and FBOs.  This article explains the differences between these:

http://wiki.davincidsp.com/index.php/Render_to_Texture_with_OpenGL_ES

I recommend you look at the Pixmap approach since that is supported in our current Graphics SDK (for Linux).  However, you will need a way to detect when the SGX has completed rendering each frame and that is not well supported in the current SDK.  It will be improved in the next release.

Regards, Clay

Clay,

Thank you for your help.  Are there any available code examples of reading from the Pixmap buffer (I am using OpenVG rather than OpenGL, but I assume that all the commands needed for Pixmap and Pixelbuffers are all EGL)?

After reading data from the buffer and repacking the data using a NEON based function, where am I to write the data to for the DSS to use? Also, from what I have been reading, it appears that I can only synchronise reading from the pixel after a complete frame of rendering, which would incur a 1 field delay to the DSS.  Is there any way to reduce this delay (i.e. perform per-pixel packing from the SGX to the DSS)?

Thanks,

Andy

Andy,

  I have not been able to locate any example code for this.  It is very new and I expect that it has not been tested with OpenVG yet, but the structure to look for is:

Clay, Andy,

You can take a look at sgxperf2, with option of pixmap surface (inSurfaceType == 1),

https://gforge.ti.com/gf/project/gleslayer/scmsvn/?action=browse&path=%2Ftrunk%2FPackages%2FOMAP3_Graphics_SDK%2FGLESLAYER_SGXPERF_20%2Fsgxperf_gles20_vg.cpp&revision=12&view=markup

There is one test TEST9, for SVG as well.

Andy,

If you are not using any other video/display related driver features other than a simple frame buffer display then it is fairly simple to point the DSS to a region of memory and simply display it. This can be done "behind the back" of the OS by writing to the BA0/BA1 registers of the selected display processing pipe. Additionally, you can trigger an interrupt based on the display sub-system output frame to ensure that to only write to this display buffer during the blanking period. If you do not do this then you either need to double buffer or you will see tearing artifacts.

Hi,

Thank you for all your help and advice.

I am going down the route of rendering from the SGX into a Pixmap buffer. I have however a problem with choosing a configuration. I am creating a list of attributes for the EGLConfig, which includes the 'EGL_SURFACE_TYPE' set to 'EGL_WINDOW_BIT | EGL_PIXMAP_BIT' for using pixmaps, but when I call eglChooseConfig(..), no matching configs are returned. I have called eglGetConfigs(..) and found that only a total of 8 are possible and none of them have the EGL_PIXMAP_BIT set (not even for OGLES), which would explain why the call to eglChooseConfig(..) failed!

Is there any specific setup required to create an ARGB8888 pixmap e.g. bootargs (I do have 'omapfb.mode=dvi:1024x768MR-16@60' set, if that is correct)?

Since I am using the 2009 stable release of Angstrom for the Beagleboard, the Graphics SDK version built is 3.00.00.09. Will that cause a problem? I have tried to build in the 3.01.00.02 version of the SDK but have had no success.

Any hep to get the pixmap buffer working would be great!

Thanks

Andy

I was a bit premature with posting my last question... I have been able to get a matching config for ARGB8888 which supports pixmaps by finally installing the later SDK of 3.01.00.02 as part of my build of Angstrom!

Andrew Poole said:

Hi,

Thank you for all your help and advice.

I am going down the route of rendering from the SGX into a Pixmap buffer. I have however a problem with choosing a configuration. I am creating a list of attributes for the EGLConfig, which includes the 'EGL_SURFACE_TYPE' set to 'EGL_WINDOW_BIT | EGL_PIXMAP_BIT' for using pixmaps, but when I call eglChooseConfig(..), no matching configs are returned. I have called eglGetConfigs(..) and found that only a total of 8 are possible and none of them have the EGL_PIXMAP_BIT set (not even for OGLES), which would explain why the call to eglChooseConfig(..) failed!

Is there any specific setup required to create an ARGB8888 pixmap e.g. bootargs (I do have 'omapfb.mode=dvi:1024x768MR-16@60' set, if that is correct)?

Since I am using the 2009 stable release of Angstrom for the Beagleboard, the Graphics SDK version built is 3.00.00.09. Will that cause a problem? I have tried to build in the 3.01.00.02 version of the SDK but have had no success.

Any hep to get the pixmap buffer working would be great!

Thanks

 

Andy

I was a bit premature with posting my last question... I have been able to get a matching config for ARGB8888 which supports pixmaps by finally installing the later SDK of 3.01.00.02 as part of my build of Angstrom!

Hi, Andy:

We are working on the Omap graphics SDK. The version we are using is 3_00_00_09. But it has some issues. So we would like to try a newer version.

However, we could not find the download page of Omap graphics SDK 3.01.00.02.

Where did you download the package ?

Thanks

Kevin

Hi Kevin,

I have found that navigating the TI site can be a little difficult. I presume that the 3.01.00.02 version of the SDK is the latest, but it did solve a few problems I was having with 3.00.00.09. Here is the link to the download page:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS.html

Regards,

Andy

Andrew Poole said:

Hi Kevin,

I have found that navigating the TI site can be a little difficult. I presume that the 3.01.00.02 version of the SDK is the latest, but it did solve a few problems I was having with 3.00.00.09. Here is the link to the download page:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/latest/index_FDS.html

Regards,

Andy

Thanks a lot.

Kevin

Steve Clynes said:

...it is fairly simple to point the DSS to a region of memory and simply display it. This can be done "behind the back" of the OS by writing to the BA0/BA1 registers of the selected display processing pipe.

Hi Steve,

I know it has been a while since you posted this reply, but I was wondering how I can point the DSS to a region of memory "behind the back" of the OS? You mentioned writing to the BA0/BA1 registers of the selected processing pipe but I have no idea how to do this! It there any help you can provide me about these registers, what I write to them and how I write it?

Thanks very much

Andy

Andy,

Just to add to this...

What I mentioned above only addresses getting the data out of OMAP and does not address the generation of the data in the first place.

I believe the SGX can generate image data plus alpha, but I do not know too much about setting this up.

BR,

Steve

Steve,

Thank you for your quick response, I shall start looking at the technical manual. As I had mentioned in earlier posts, I am generating the data from the SGX in an ARGB8888 format straight to a pixmap, and then from there I am using the NEON to manipulate the data into a 24-bit ARGB8565 format. This is stored in the lower 24 bits of a 32 bit word so I would expect that when I point the DSS to the area of memory containing the manipulated pixel data, the DSS can send out those 24bit of useful data.

Thanks again!

Andy

Andy,

If you are packing the data into the lower 24 bits of the 32 bit word then you should configure the frame buffer format to be 24 bit unpacked, and TFTDATALINES to be 24.

This will give you 1 pixel + alpha per output clock, which is certainly easier to process than 16 bit of packed :)

BR,

Steve