| Age | Commit message (Collapse) | Author |
|---|
|
Add DRI2 direct rendering support to libGL and add DRI2 client side
protocol code. Extend the GLX 1.3 create drawable functions in
glx_pbuffer.c to call into the DRI driver when possible.
Introduce __DRIconfig, opaque struct that represents a DRI driver
configuration. Get's rid of the open coded __GLcontextModes in the
DRI driver interface and the context modes create and destroy
functions that the loader was requires to provide. glcore.h is no
longer part of the DRI driver interface. The DRI config is GL binding
agnostic, that is, not specific to GLX, EGL or other bindings.
The core API is now also an extension, and the driver exports a list
of extensions as the symbol __driDriverExtensions, which the loader
must dlsym() for. The list of extension will always include the DRI
core extension, which allows creating and manipulating DRI screens,
drawables and contexts. The DRI legacy extension, when available,
provides alternative entry points for creating the DRI objects that
work with the XF86DRI infrastructure.
Change DRI2 client code to not use drm drawables or contexts. We
never used drm_drawable_t's and the only use for drm_context_t was as
a unique identifier when taking the lock. We now just allocate a
unique lock ID out of the DRILock sarea block. Once we get rid of the
lock entirely, we can drop this hack.
Change the interface between dri_util.c and the drivers, so that the
drivers now export the DriverAPI struct as driDriverAPI instead of the
InitScreen entry point. This lets us avoid dlsym()'ing for the DRI2
init screen function to see if DRI2 is supported by the driver.
|
|
Failure to consistently do so resulted in mismatched aligned versus
unaligned alloc/free.
|
|
965 after merging intel_context.c from i915 and i965. fix bug# 15152.
|
|
It was harmless, as the only time we need to clear PRESUMED_OFFSET, the
variable had been initialized already.
|
|
|
|
|
|
|
|
a texture when calling TexImage with pixels set to NULL pointer.
|
|
call with zero width/height/depth matches GL spec.
|
|
DEPTH_STENCIL texture. (bug#14952).
|
|
|
|
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.
|
|
|
|
|
|
|
