Weekly report 12

August 16th, 2010 topfs2

This is the last weekly report and I would like to thank google and the beagleboard community for the fun summer! It have been a wonderful opportunity and I’ve learned heaps and gotten extremely interested in embedded development.

Status

  • Done further investigation regarding finding the performance bottleneck and is reasonably sure its not shaders any more, which is good. I have noticed that it seems likely that many skins suffer from texture cache issues which is due to textures being to large and making SGX having to do unnecessary work to handle the presentation. I’ve verified this by splitting up a texture in 4 pieces and received 50% performance increase. It seems it doesn’t depend on the size of the rendering area but the texture size. This is of course only true if the USSE isn’t running at maximum capacity since then larger render area would make it slower. And on most skins it is running at full capacity which is were dirty region is useful.
  • Since much of the performance increase is done by skinners and hard to fix magically by code I’ve written up a documentation with what I’ve learned which could be used by skinners who wants to make a lightweight skin. Documentation can be found at elinux wiki (http://elinux.org/BeagleBoard/GSoC/2010_Projects/XBMC#Documentation)
  • Added a background to the beagleskin which makes it look rather close to confluence while still running at 30fps in 720p on the BeagleBoard C4.

Plan

  • Need to google abit for rebase in git so I can upload the patches done during gsoc to google. Or just use format-patch, not sure which is the best.
  • Take a few weeks off before going back to school :)
  • Need to find a suitable something to hook up the beagleboard to when arriving to Canada so I can continue to play with it :)
  • Continue with the lightweight skin, I very much like to use it despite it being far from finished.
  1. Hitcher
    August 16th, 2010 at 18:04 | #1
    Reply | Quote

    Interesting reading regarding the skinning side of things because I’m always looking to improve the performance of my skins and would like to know a few things.

    You mentioned using smaller ‘power of two’ textures for backgrounds to improve loading but this would result in textures getting upscaled which wouldn’t look good for finer details but would using four 640×360 textures (to make up a 1280×720 background) be any better?

    Also could use expand on the use of the border tag please?

    - ‘Scaling and positioning textures in accelerated rendering systems is usually almost for free which means using the border tag in skinning to limit the size of a texture could significantly lower the needed load.’

    Thanks.

    • topfs2
      September 6th, 2010 at 15:50 | #2
      Reply | Quote

      Hi!

      Well basically on certain GPU’s they support any size of the texture (this support is apart of the specification for GLES 2.0 and GL 2.0) were before it was only power of two. However how the GPU handle this is another matter and its in reality up to the GPU creator to choose. They can make a GPU which handles it perfectly (this is mostly the case on modern desktop cards) or they may support and work with it but its slow. The latter is supposibly true on beagleboards GPU but I never found any significant change in it but the GPU creators says it should be slower.

      Basically for the GPU on BeagleBoard (this may hold true to many embedded gpus) the size of the texture is more important than the size its being presented at. i.e. a texture which is 512×512 and rendered at 512×512 may be slower than one that is 128×128 being rendered at 512×512. This is due to how the GPU has to fetch the texture for rendering and may need to fetch the larger texture multiple times eating gpu cycles. This means that its great to use the border tag since you can create a texture which may be 128×128 with a border and just a few pixels in the middle which you set to be scaled alot higher.

      As for the splitting of textures it really should be done automatically and a skinner shouldn’t need to split a background into 4 pieces for it to be optimized, it was mostly a fun fact that it was faster and a possible optimization for me at some point to add codewise.

      Thanks for the interest and hope I answered the questions :)

Comments are closed.