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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
