On Thu, Nov 29, 2012 at 8:57 PM, Marek Olšák <maraeo@xxxxxxxxx> wrote: > On Thu, Nov 29, 2012 at 4:35 PM, <j.glisse@xxxxxxxxx> wrote: >> So as a followup is 2 patch. The first one just stop trying to move >> object at each cs ioctl i believe it could be included in 3.7 as it >> improve performances (especialy with vram change from userspace). >> >> The second one implement a vram eviction policy. It's a simple one, >> buffer used for write operation are more important than buffer used >> for read operation. Buffer get evicted from vram only if they haven't >> been use in the last 50ms (so in the last few frames) and only if >> there is buffer that have been recently use and that could be move >> into vram. This is mostly were i believe discussion should be, >> what kind of heuristic would work better than tat. > > First off, I didn't review the patches, because I'm not as familiar > with the DRM. Just some comments. > > Isn't 50ms too little? You always need at least 20 fps for that to > make sense. I think 200ms would be more reasonable, but still that > isn't perfect either. Well it's an tunable, i did try several value btw 100ms and 500ms and 500ms gave the best result, i think it's mostly because there is still ping pong otherwise, ie one of the bo is big and it get evicted because for few frame is not use but at the same time other bo that move in are not that big and doesn't make much diff to be in vram or gtt, but then the big one suddenly is use again but this time its in gtt. It's mostly guessing through what my printk shows in vram in and vram out. Also there is quite few short lived bo and migrating any long lived bo out of vram hurts. > Another option would be to use something else than elapsed time, > something that's based on actual usage. > > This weekend, I'll try to make a Mesa patch that sends an end-of-frame > flag to the kernel through the CS ioctl. I think there would be at > most 2 end-of-frame flags received by the kernel each frame: one from > the GL app and the other one from the compositor. > > Marek I am not sure how much value it's, if you take time like 15ms and assume that the program run at 60hz you get a good approximation. I think that rather than use last time since used metric for eviction i should rather compute use frequency, it would smooth things out ie things might stay in vram tiny bit longer than strictly necessary but at the same time buffer with high frequency usage would move in first, with my current algo a buffer might get lucky and move in just because it was last use. But anyway we could probably also play with metric involving end of frame. Cheers, Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
