> Thats fine as long as you don't want to do acceleration or object > migration between GTT > and VRAM type memory. Now I expect when you give out this advice you Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'. It's all effectively in the GART with the 'stolen' pages preloaded into the translation tables by the BIOS at vga init time. It has fake VRAM type memory but thats really an illusion (although one the driver seems to like to keep up). The GEM changes do mean you can plug the existing allocator in the VIA driver into GEM directly. Whether that would be a good idea or not given the other things you then need to do I don't know - but it does seem to be me to be a stepping stone in the right direction that is much easier to make ? I'm fairly sure the real problem is that we have no way to treat stolen pages as generic kernel memory. The ideal case would be to simply put that memory back into the kernel memory pools. I did a little poking at this but it makes suspend/resume horribly exciting and while some hardware puts it at civilised bus addresses (end of 'real' memory usually) not everyone seems to do it that way. You can migrate the physical pages under a GEM object as well - in fact it happens every time pages get swapped out and back in. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
