> This driver has a slightly different design than other KMS drivers, but > future server chips will probably share similiar setup. As these GPUs commonly > have low video RAM, it doesn't make sense to put the kms console in VRAM > always. This driver places the kms console into system RAM, and does dirty What happens to mmap of the framebuffer in this case ? > updates to a copy in video RAM. When userspace sets a new scanout buffer, > it forcefully evicts the video RAM console, and X can create a framebuffer > that can use all of of video RAM. If the framebuffer memory points either at the real display or a TTM backing object depending upon where the framebuffer in question is currently living then you'd get - working mmap (at the expected speed) - the ability to page out the console buffer rather than burn 8MB or more of main memory with fixed mappings (and precious vmalloc space on 32bit at that) with GEM at least. It seems to me you'd just need to flip the framebuffer base and also for the mmap to evict the object so that it faults back at the new mappinging. The rest is a copy in and out. Either way I don't quite understand why the sysram is not GEM backed so that you can just unpin it when not displaying the framebuffer and let the kernel page it out ? Alan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
