| Age | Commit message (Collapse) | Author |
|---|
|
This is defaulted off as it has potentially large memory costs for a modest
performance gain. Ideally we will improve DRM performance to the point where
this optimization is not worth the memory cost in any case, or find some
middle ground in caching only limited numbers of certain buffers. For now,
this provides a modest 4% improvement in openarena on GM965 and 10% in openarena
on GM945.
|
|
|
|
Instead of passing in a fixed struct, the loader now passes in a list
of __DRIextension structs, to advertise the functionality it can provide
to the driver. Each extension is individually versioned and can be
extended or phased out as the interface develops.
|
|
Right now the DRI2 screen constructor takes 3 different versions:
DRI, DDX and DRM. This is mostly useless, though:
DRI: The DRI driver doesn't actually care about the DRI protocol,
it only talks to the loader, which in turn speaks DRI protocol. Thus,
the DRI protocol version is of not interest to the DRI driver, but it
needs to know what functionality the loader provides. At this point
that's reflected in the __DRIinterfaceMethods struct and the
internal_version integer.
DDX: The DDX version number is essentially used to track extensions
to the SAREA. With DRI2 the SAREA consists of a number of versioned,
self-describing blocks, so the DDX version is no longer interesting.
DRM: We have the fd, lets just ask the kernel ourselves.
|
|
Another regression from the intel_context.c merge.
|
|
Otherwise, we would assertion error when doing the final unreference of the
buffer with an outstanding map (catching the memory leak).
|
|
|
|
|
|
|
|
Dont stop on fence creation errors.
|
|
They're changed by the intel driver implementation and thus not const.
Fixes compilation warning.
|
|
The DriverAPI is internal to the DRI drivers and GetDrawableMSC
obsoletes GetMSC. Also, since the DRI driver interface has not yet
been released, just drop the getMSC function from the DRI interface
instead using the ABI preserving version mechanism.
Finally, using void pointer privates in the DRI interface is not allowed,
always pass the actual types around (__DRIdrawable in this case) to
enhance type safety and readability of the code.
|
|
|
|
|
|
image offset is already considered when map, add it again in
StoreImage may lead to wrong result and crash.
|
|
|
|
|
|
|
|
Otherwise, we would go wildly out of bounds if passed -1 (no renderbuffer), such
as while doing LOCK_HARDWARE with glDrawBuffer(GL_NONE).
|
|
Otherwise, glDrawBuffer(GL_NONE); glDrawPixels() results in a segfault when
we try to emit the color buffer state during setup.
|
|
The IS_945 case was left to fall through to the 830 case, along with the
not-recognized-at-all case, making that dead code.
|
|
|
|
|
|
|
|
|
|
Currently only implemented for intel hw.
|
|
|
|
It wasn't being initialized at screen setup, so we were getting stub
entrypoints even though it was exposed as enabled. Fixes arbocclude mesa demo.
|
|
The 965 path wasn't setting pClipRects for batch submission since it didn't
want kernel cliprect handling before. The 915 path also grew the INTEL_NO_HW=1
option for testing just driver overhead.
|
|
It's not worth the extra effort to avoid a free/malloc, and we'd rather
auto-size the reloc data buffer at some point so we don't need to have
max_relocs.
|
|
Harmless since we don't yet have any bits above 31 for flags.
|
|
|
|
|
|
|
|
The failure mode that was a available was:
reloc 1 -> target_buf
exec: PRESUMED_OFFSET wrong, buffer migrates, r1 entry updated.
reloc 2 -> target_buf
exec: suppose buffer migrates again. PRESUMED_OFFSET wrong. r2 entry updated.
reloc 1 -> target_buf
exec: suppose buffer doesn't migrate. PRESUMED_OFFSET right. no relocations
performed. r1 has stale pointer at original location.
Failures were reported with OGLconform's VBO test and SPECviewperf90, though
I haven't confirmed that this fixes it.
|
|
In addition to potentially binding when it was about to be mapped anyway,
failure to use CACHED_MAPPED means eating a full wbinvd on validate. Thanks to
airlied for catching this.
|
|
This reverts commit e2cb905bc6e23eaafaeeb2abdc9480e70959ee3f.
It was a reversion of an optimization hidden as otherwise.
pre_target_buf_handle was always NULL, so the optimization was never enabled,
rather than fixing the important optimization (resulting in 25-50% performance
loss).
|
|
|
|
this fix bad texture issue in some games(UT and quake).
|
|
buffer is used for a relocatee in the former relocation process
then another target buffer is used for this relocatee at the same
offset in the current relocation process.
|
|
|
|
|
|
|
|
|
|
The screen wide info such as pitch and cpp are obsoleted by the FBO
changes, so clean up the last few references to those, except for
setting up the legacy screen regions.
|
|
Around 10% of a CPU was being wasted to create the linked list which we
threw out immediately after passing it to the kernel.
|
|
|
|
The fix for pageflipping with cliprects ended up causing a batch flush at
an inopportune time, which is fixed by moving it up.
Additionally, the recovery code for handling batch wraps at bad times is
replaced by just checking for the space up front, and using a no_batch_wrap
assert like on 965 to make sure that we weren't wrong about how much space that
was.
|
|
|
|
Workaround for recursive batchbuffer flushing: If the window is
moved, we can get into a case where we try to flush during a
flush. What happens is that when we try to grab the lock for
the first flush, we detect that the window moved which then
causes another flush (from the intel_draw_buffer() call in
intelUpdatePageFlipping()). To work around this we reset the
batchbuffer tail pointer before trying to get the lock. This
prevent the nested buffer flush, but a better fix would be to
avoid that in the first place.
|
