Video of latest xbmc code on Raspberry Pi
(2013-10-01, 00:04)MilhouseVH Wrote: Thanks. I'll re-cache my fanart at 1080 and see if 5 seconds is a problem (over NFS, still waiting for the USB3 memory stick). I'll then use a delay of 0 and see if I notice any difference. One thing that occurs to me is that, if GPU memory is limited, couldn't textures simply be evicted from GPU RAM as required? Then you could have a longer lazy eviction time, but also evict on demand if/when required to free up RAM.

There is a "discardable" flag on GPU buffers which means it can be discarded if another allocation will fail.
I'm not sure if that will produce a blank texture or random corruption when it attempts to render (or something worse!). May be worth testing.
It won't be ideal, as xbmc will believe the texture is still valid, so will never reupload it, so it won't recover as memory is freed up.

A better scheme might be for xbmc to query free GPU memory on each texture upload. If it's too low, then kick the texture delete thread with a timeout of 0.
But, this is getting a bit too pi specific/intrusive, and so hard to get accepted into xbmc.

Messages In This Thread
RE: Video of latest xbmc code on Raspberry Pi - by popcornmix - 2013-10-01, 00:27
RE: - by godson - 2013-10-13, 00:29
USB 2.0 vs. Class 10 vs. USB 3.0 - by xbs08 - 2013-12-13, 11:56

Logout Mark Read Team Forum Stats Members Help
Video of latest xbmc code on Raspberry Pi6
This forum uses Lukasz Tkacz MyBB addons.