As 965-fbo has been getting stabilized, I decided to go ahead and merge the 965-ttm branch. I chose to do a squash merge since there was a bunch of very noisy history as I flailed about trying to get it to work. I cherry-picked out what I could to get it down to what I think is just the change required to switch buffer managers. The details of how I got there be found in the 965-ttm branch of mesa, if schadenfreude is your sort of thing.
As you'll see if you try it out, 965-ttm does result in a major
performance regression. You can set INTEL_NO_TTM=1 in the environment
to disable TTM mode and use classic userspace buffer management, which
recovers some of the performance. Some sample timings (bigger is
better):
old 965-ttm-classic 965-ttm-ttm
openarena 134 43.7 6.2
ipers 544000 152000 9300
There are a bunch of performance improvements in the works which should
help bring things back up to what they used to be, and if we're not
wrong then at the end we should actually see performance improvements
using ttm on 965, like we have on 915.
- Re-add no_fence_subdata
I removed this performance hack from dri_bufmgr_fake because I didn't
really need it for 915, and I haven't readded it yet for 965. It would
bring back a chunk of the performance lost form old to 965-ttm-classic.
Only needed for userspace suballocator. (~anholt/mesa
965-ttm-subdata-hack)
- Re-alloc the state pool
Even with the above, when we wrap around in our userspace suballocator,
we have to wait for sync before we can start writing state at the start
of the buffer again. The code didn't do this before, and we can make it
not do it again. (~anholt/mesa 965-ttm-pool-realloc)
- Re-add disable_backing_store to more places
The 965 driver used to disable backing store on more buffers than after
the merge, and we could bring that back. These were disabled because
the dri_bufmgr interface doesn't have the equivalent of bmBufferData
(release buffer memory and allocate new memory in the same buffer object
with the same state), so some minor adjustments are necessary to ensure
that the backing store disable remains on the relevant buffers.
Additionally, there are locking complexities for doing this to the
batchbuffer again with that code being shared with 915, since 915 and
965's locking around batchbuffer emit paths are different (I'm hoping to
change this).
- Rework state caching
Right now we allocate state buffers out of a userspace suballocator.
The problem is that these allocators are relatively small, and when we
exceed their limits we have to throw them away and recalculate all of
our state. Instead, we could make our state cache be a hash table of
actual buffer objects rather than layering a buffer manager on a buffer
manager, and we would avoid the no_fence_subdata hack and improve our
cache hit rate. A version of this that I decided to throw out
(~anholt/mesa 965-state-caching) was a modest performance improvement,
and we can do better than that.
- TTM relocation caching
Primarily valuable on top of state caching rework, this was posted by
keithp recently. Avoids redundant relocation writes to buffers and the
associated fence waits. Should bring ttm performance to at or above
classic performance.
- Move buffer manager structures back to context instead of screen
The motivation of moving it to the screen was that for classic mode, you
could avoid the eviction process on context switch within a single
process. It turns out that the pthread mutexes used for refcounting
other structure protection are accounting for about 10% of a CPU in my
testing, and we could avoid it by abandoning this unimplemented
optimization for classic mode. However, we may be able to avoid this if
we can get libGL to not link against libpthread on platforms with thread
stubs.
--
Eric Anholt [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
_______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
