3D-graphics engine SGX544 of AM572x

Hi,

I will ask the AM57X team to comment.

Hi Michi,

This should be done through the DDK sources, which unfortunately are 3P resource and cannot be modified. I checked the kernel code and from there you can disable the whole GPU (not just one core), which is not suitable for your query.

Best Regards,
Yordan

What operating point are they planning to use for the GPU? If they're not already using the lowest operating point, I think they would save more power by using both GPU cores at a lower operating point (which would be more easily supported).

Dear　Brad-san,

Thank you for your reply and additional comment.

Customer's target is not save power. They would like to make the graphic performance similar to AM5718  by using AM5728.  As you know, AM5718's GPU is only one. So they would like to disable one GPU core.

Best regards,

Michi

Biser:

My problem is sort-of related to the original posted question so perhaps you can help.

I am working on an embedded navigational system targeting the commercial avionics industry. Currently we are hoping to use the ARM AM5728 processor that incorporates a PowerVR/SGX544 GPU. In order to ultimately get FAA and EUROCONTROL certification we must use "real-time-processing" which precludes using either Linux or Windows on our target hardware. Currently I am driving our LCD over GPIO pins from a local frame-buffer which I render manually. This works well but it is too slow for real-world application. I need to find a solution for using a GPU on a non-OS ("bare-metal") hardware.

What do I need to do get the COMPLETE programming specifications for utilizing the SGX544 in a non-OS situation? I have been in contact with Susi Barrett at Imagination-Technologies to get the needed documentation directly from them ~ However, she pointed me back to TI to get the information. Will you be able to supply that or simply point me back to Imagination-Tech again. . . :-)

Dean Wedel

Dean Wedel said:

Currently I am driving our LCD over GPIO pins from a local frame-buffer which I render manually. This works well but it is too slow for real-world application. I need to find a solution for using a GPU on a non-OS ("bare-metal") hardware.

Did I understand that right -- you're currently bit-banging the LCD interface with GPIO?  Why aren't you using the display subsystem?  This hardware is fully documented in the TRM.

Dean Wedel said:

What do I need to do get the COMPLETE programming specifications for utilizing the SGX544 in a non-OS situation?

We don't have the support infrastructure in place to accommodate this type of request.  I imagine you will say something along the lines of "just give us all the documentation and we can figure it out ourselves without any support".  I can speak from experience here, that's not going to be possible with the GPU, i.e. no matter how good your engineering team may be, there are going to be issues that come up requiring in depth support that we cannot provide.

Now that said, you still have many, many CPU cores available in AM572x where you can perform various graphics-like operations in your own software.  The DSPs would be a great candidate for this type of work, and I expect it will be much easier to certify since you will have full control of the software.

Brad:

Thanks for responding to my rambling question. . .

To clarify what I'm currently doing: I am using the the LCD sub-system to drive the output-pins. I should have said I am driving the LCD pins rather than the GPIO pins ~ I didn't intend to be misleading. The LCD sub-system allows me to have two DMA blocks (for double-buffering) which I manually "draw" my images into and then pointing the sub-system to the correct DMA block using RasterDMAFBConfig() function call.

Understand your concerns with the SGX544 support and respect that decision. I already have abbreviated documentation on the assembly-language data that the SGX544 uses but this does not outline at all how the ARM L3 in-stream/out-stream configuration is to be setup. . . .

On a closely related option: do you offer documentation for the Vivante GC320 2D Accelerator which is also included on the AM5728 ? It seems to me that using an engine that is optimized for graphics would give better performance than using something like the DSP sub-system.

Sincerely,
Dean

Hi Dean,

Sorry, same story for the GC320. I agree with your thought that the SGX544 and GC320 would be best suited from a hardware perspective for doing graphics-related tasks. However, due to your specific requirements for "bare metal" and certification, I don't think either one will be a viable option.

Brad