| Age | Commit message (Collapse) | Author |
|---|
|
This fixes a problem where texturing from the same Pixmap more than
once per batchbuffer would hang the DRI driver. We just use the region
associated with the front left renderbuffer of the __DRIdrawable for
texturing, which avoids creating different regions for the same BO.
This change also make GLX_EXT_texture_from_pixmap work for direct
rendering, since tracking the __DRIdrawable -> BO handle now uses
the standard DRI2 event buffer. Of course, DRI2 direct rendering
doesn't exist yet.
Finally, this commit bumps the DRI interface version again, accounting
for the change in the DRI_TEX_BUFFER extension and the change in
commit 0bba0e5be7a4a7275dad1edc34bdcc134ea1f424 to pass in the
event buffer head index on drawable creation.
|
|
__dri2ParseEvents() would determine the kind of event, but then call
UpdateBuffer() in either case, and UpdateBuffer() would then have to
figure that out again to dispatch to HandleBufferAttach() or
HandleDrawableConfig(). Pretty pointless.
|
|
Makes a lot more sense, since the screen is always implicit in the
DRI drawable, but it may not be possible to track down a context from
just a drawable.
|
|
Fixes #14799.
|
|
|
|
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.
|
