Hi, Dave,
Dave Airlie wrote:
> Hi,
>
> I've done a port of miniglx to a TTM-only system (no legacy buffers),
>
> It's in the miniglx-ttm-only branch of my personal mesa repo..
> http://gitweb.freedesktop.org/?p=users/airlied/mesa.git;a=shortlog;h=miniglx-ttm-only
>
>
Cool!
> It is just an example of how to use drmBOs to allocate the memory spaces
> and buffers, it isn't 100% stable but I can run manytex on it for a while
> before it crashes, it also requires hacks to the drm to remove the master
> only on the drawable ioctls (nothing to do with TTM just a miniglx
> limitaton due to laziness..) and there are couple of changes from Thomas
> to fix the user object lookup which hopefully he'll push soon to the drm..
>
> I'm probably allocating the front/back/depth wrongly I think it should
> probably use NO_MOVE instead of NO_EVICT and have the client side validate
> things on lock as in theory with rotation/resizing these buffers could
> change size.. I'll see if I can arrange that..
>
>
After some thinking, I think the best thing to do here is for the server
to do the following
when the front / back /depth buffers need to change
LOCK_HARDWARE()
drmBOValidate(buf, DRM_BO_MEM_LOCAL, DRM_BO_MASK_MEM |
DRM_BO_FLAG_NO_EVICT,
DRM_BO_HINT_DONT_FENCE); // Wait for buffer idle, unmark the
no_evict flag, and throw out the buffer to system memory.
drmBODestroy(buf); // Decrease refcount on buffer, but there are other
clients holding references so it won't be destroyed yet.
allocateNewBuffer();
updateSarea();
UNLOCK_HARDWARE()
The client will detect that there is a new buffer when checking the
sarea after a lock, and will free all references to
the old buffer without validating it. At the same time, the old buffer
won't take up precious vram / tt space when the new
buffer is allocated, and we will avoid fragmentation. However, there
will be a copy from vram / tt to local memory which is fast, but
undesirable.
Really the best thing to do here is to add a "Zombie" state to the
buffer, and add some code for that to DRM.
Only the buffer creator can mark the buffer as zombie, and then all
resources are freed. A zombie buffer may not be
validated, (then we can catch clients trying to use obsolete shared
buffers, and we avoid a copy of obsolete buffer data).
/Thomas
> I have to say the drmBO interface so far seems to act like I would expect
> them to and I wish we had them years ago :-)
>
> Dave.
>
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
