• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 358 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OpenVG and SGX Performance

Andrew Poole
Intellectual 570 points
Other Parts Discussed in Thread: OMAP3530

Hi,

I am currently developing a graphics application to run on an OMAP3530. I am experiencing performance issues with the number of frames per second the application can achieve. I hope that someone may be able to clarify things or help point out some performance tricks.

I have chosen to go down the OpenVG route. My application is not very complicated in terms of graphics and I only want to draw simple 2D primitives; lines and curves for boxes and circles, etc... With OpenVG's vector based graphics, it is also easy enough to draw text on screen using any TTF or OTF file.

I am running the DVI output at a resolution of 1280x1024 with a 24-bit RGB (32bit ARGB internally) pixel depth but struggle to reach even 35Hz drawing a couple of square boxes on the screen. Is there any reason for this? I realise that the entire screen has to be redrawn at each frame and so I have looked into the OpenVG feature, 'scissoring'. However, creating a small scissor rectangle slows down the FPS quite significantly and so it appears that using this feature it not an option to speed up performance.

I have also, just recently, seen the release notes for the 3.01.00.06 version of the Graphics SDK (I am using 3.01.00.02). Worryingly it states the support for OpenVG 1.1 uses CPU for majority of the tasks. Can anyone explain this in further detail?

Sorry there are a few questions there, any advice will be helpful!

 

Andy

  • 0
    TI__Intellectual 1910 points

    Andy,

       The SGX is used to do the affine transforms and the rendering by the OpenVG library .  However, the SGX requires that all the geometry be tessellated into lists of triangles.  It is this tessellation step that is done by the ARM.  This should not be a problem if you keep your paths short and non-crossing.  Things like bezier curves and outline fonts must be converted to paths and those paths may be long and crossing which might explain the poor performance you are seeing.

    Regards, Clay

  • 0 in reply to Clay Montgomery
    Intellectual 570 points

    Hi Clay,

    Thank you for your quick answer... Can I assume that using 'many short paths' is better than using 'fewer long paths'?

    I am still having a few doubts about the performance of my OMAP3530. I have created a test case where I have 6 resizing boxes in screen - I am not just scaling the boxes but instead, translating the sides in an out from the box's centre (i.e. exploding the box). I am finding that, at a resolution of 1280x1024, the average frame rate is 38fps. This doesn't sound right to me. I am drawing a total of 4 paths per box, making a total of 24, very short, non-crossing paths. I should also add that I am using fast anti-aliasing, which I know will slow down the performance somewhat, but I would still expect it to be higher than 38fps.

    Since most of the screen does not need to be updated, I have tried setting up a scissor rectangle around the 6 resizing boxes but this strangely slows down performance a fair bit.

    Are there any explanations as to why I am getting such a poor frame rate? and why, when enabling scissor rectangles, the frame rate drops?

    Thanks very much,

     

    Andy