> Merge branch 'i915-unification'
>
> This branch replaces the DRM pool interface used by i915tex with a
> "dri_bufmgr"
> interface in dri/common which may be set up to use either TTM or
> traditional
> static memory management according to what is available. The i915tex TTM
> code now requires an updated DDX which provides proper buffer objects for
> the
> static front/back/depth, instead of using fake buffers. The driver is now
> built as i915_dri.so, and should replace the old i915 driver shortly.
Eric,
I'm interested to understand how you have made this work -- I've taken a
quick look at the code and have some comments.
The big one (and it is a big one) is that you seem to have misunderstood
the limitations of the fake buffer manager, and are operating as if it
could be dropped in as a functionally-equivalent replacement to the TTM
manager behind a suitable interface.
Unfortunately this isn't correct, mainly because the fake manager does
not guarantee that it will maintain the contents of texture buffers
after updates by the GPU, ie. there is no path in the fake buffer
manager for tracking changes to texture/fbo contents in video ram, and
no mechanism for updating the backing store with those changes prior to
eviction.
This means for instance that textures updated with CopyTexSubImage by
blitting from the framebuffer (see intel_tex_copy.c) will potentially
lose their updated contents when they are evicted asynchronously later
on, and will revert to whatever was in backing store. Note that the
i965 driver does not provide an accelerated CopyTexSubImage path or
FBO's for this reason.
The i915tex code makes use of this property of the TTM manager in
several places (texture uploads, fbos, pixel path, etc). The guarantees
provided by the TTM manager are one reason why the i915tex driver has
functionality that we haven't been able to provide in any driver
previously.
It seems like if you want to integrate the two memory managers in this
way, you still need some sort of mechanism for coping with asynchronous
clobbering of texture memory, or to turn off paths that rely on the
memory not getting clobbered.
Please correct me if I'm wrong, but I've looked for changes in the
driver that would show you've done this and can't see anything obvious.
It seems like you'd either have to:
1) Hold the hardware lock and do a glFinish() after every rendering
targeting a non-static bufffer, and once complete, back-copy the new
buffer contents to backing store (!!). This would be very slow for
these operations.
2) Figure out what memory manager you are using and, if it is the fake
one, disable any paths in the driver that rely on the assumption of
persistent video-ram buffers, and provide alternatives. This would
effectively mean switching between i915tex and i965 versions of
CopyTexSubImage, texture uploads, etc, and turning off extensions like
FBO's for the fake manager.
#2 could probably be made to work, but obviously won't be as clean an
abstraction of the differences between managers as you'd been hoping for.
Let me know if you intend taking this on. In the meantime I don't see
that the old i915 driver can go away until this gets fixed.
Keith
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
