Ian Romanick wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Keith Whitwell wrote:
To clarify, a naive (unoptimized) usage pattern would be:
LOCK_HARDWARE()
bboffset = ValidateBuffer( i915->backbuffer )
vboffset = ValidateBuffer( i915->vertex_buffer )
tex0offset = ValidateBuffer( i915->tex_buffer[0] )
if (!bboffset || !vboffset || !texoffset)
FALLBACK_PATH()
else {
emit_state_packets();
emit_3d_prim();
SetFence()
}
UNLOCK_HARDWARE()
There is a problem with this design. You really need to validate a set
of buffers rather than one buffer at a time. Imagine the case where
those 3 buffers will exactly fill all of memory. Placing the first
buffer incorrectly will make it impossible to place the other buffers
without invalidating the first.
Yes, I gloss over this a little. The intention is that Validate buffers can
fail once and the process is required to start again - giving the manager a
chance to start from scratch -- it's a little kludgey. Alternately you could of
course wrap that kludginess up in a single function which the driver passes a
list of buffers.
Other than that, this is pretty similar to what anholt, keithp, and I
came up with a few weeks ago. I just haven't started banging away at it
yet. I found it very easy to be distracted from coding projects over
the holiday. :) I believe that we used the name "CommiteBuffers"
instead of "ValidateBuffer", but the idea is the same.
Oh... Sorry I missed out that conversation... Should I have been listening
somewhere?
I've also come around to just putting everything in the kernel. I've
been convinced (finally) that the perceived benefits of having the
actual allocator in user mode (avoiding some trips into the kernel,
having the allocation policy in user mode) don't outweigh the problems
that it creates.
I do a little bit to avoid kernel trips with the conditions where an offset from
ValidateBuffer can be reused. In steady-state rendering, there should be no
need to call into the kernel at all.
In the event of defragmentation of the address space, buffers
validated previously within a Locked region may become invalid and
validation of buffers will have to restart. I'll gloss over that for
now.
I'm not 100% sure what you mean by this. Are you saying that you'd have
to loop on the ValidateBuffer calls until some steady state is achieved?
In the worst case, that loop would never terminate. :(
This is all about the single buffer parameter vs. a list. I think you've
convinced me that a list is a better api.
If you know at CommitBuffers which buffers are needed, you can try to
trivially commit the buffers (i.e., don't shuffle buffers or kick
anything out). If that fails, you shuffle buffers and kick buffers out
of memory until there is a free block large enough to hold all of the
required buffers. Then repeat the trivial commit (it *must* succeed at
this point).
That's exactly it.
Keith
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
