A simple alternative to GEM

dm.leontiev7 dm.leontiev7 at gmail.com
Fri Sep 27 11:47:26 PDT 2013


I'm new in linux dri development, so please please forgive me if I dont understand something. 

I'm working on my opensource gpu project. I've already implemented software simulator, and implementation in verilog is 40% complete. Right now I've only 2 problems: LLVM needs to be patched and DRI. Thats why I wrote this letter: DRI is too complicated for me and I think DRI can be safely simplified, and new features will be easily implementable.

In my opinion, DRI can be significantly simplified. Just get rid of "buffer" concept. I've read intel and amd docs. Modern GPUs have fully functional MMU on board. Radeons have multiple MMUs. Also GPUs have special registers which describe buffer types and buffer locations within gpu virtual address space. These registers are not related to memory protection.

So, memory is protected by GPU's MMU and we can safely allow usermode app to aim texture resource register to ANY valid location in address space associated with app's GPU context.

Also, as long as we control allocation of physical pages and page tables, we can allow usermode app to control it's GPU memory map. Implement the folllowing operations: create context, create memmap, alllocate physical pages from a specified pool, map the pages to a valid virtual address, release pages(with memmap invalidation), and execute any GPU command with a memmap-and there will be no need in GEM, TTM and other legacy. This approach is as simple(in lines of code) as a hammer. 

PBOs and VBOs can be transparently emulated in userspace library, so there will be no need to break api.

Btw, this approach enables a very interesring optmization: tile-based page flipping. This feature will be especially useful for partial window updates and resizing of windows in wayland: an app can dynamically reallocate it's buffer and there will be no need for full redraw and XMir driver hacks.


More information about the dri-devel mailing list