A simple alternative to GEM

A simple alternative to GEM

[dm.leontiev7]

Hello

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.

Regards,
Dmitry

Re: A simple alternative to GEM

[Christian König]

Hi Dmitry,

I can't speak for the Intel hardware, but you have a very basic 
misunderstanding of how the AMD GPU MMU works.

The MMU just hides the real address of the buffer, so that switching 
between different clients just becomes switching between different page 
tables. But the memory for backing the buffer must still be allocated 
mostly linearly.

Memory that is meant to be scanned out must be allocated linear not 
matter what.

Buffers that are used tilled have a very strict alignment restriction 
for their base address. This alignment restriction divides the memory 
into several segments and you must make sure that allocating each 
segment doesn't swizzles its physical memory address. Otherwise you 
would end up accessing the wrong bank/channel of VRAM which of course is 
very counter productive for fast memory access. Basically it gives you a 
whole bunch of new requirements for your memory allocation.

A different story is backing buffers with anonymous system memory. I was 
told that Jerome just recently did a very interesting talk at XDC about 
it (didn't have time to look at it myself).

Regards,
Christian.

Am 27.09.2013 20:47, schrieb dm.leontiev7:
> Hello
>
> 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.
>
> Regards,
> Dmitry
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: A simple alternative to GEM

[Rob Clark]

On Fri, Sep 27, 2013 at 3:08 PM, Christian König
<deathsimple@vodafone.de> wrote:
>
> A different story is backing buffers with anonymous system memory. I was
> told that Jerome just recently did a very interesting talk at XDC about it
> (didn't have time to look at it myself).


note that this requires a gpu which can page fault (and more
importantly, resume after cpu intervenes on page fault).. which I
think means modern(ish) radeon or nv..

BR,
-R