| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
The previous default these days served mostly to cause artifical problems with
GLX compositing managers like compiz (see e.g.
http://bugs.freedesktop.org/show_bug.cgi?id=10501).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
__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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
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 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.
|
| | |
|
| |
|
|
|
|
| |
Drop a bunch of unused arguments from intel_create_renderbuffer() and
introduce intel_renderbuffer_set_region() to set the region for
a renderbuffer.
|
| | |
|
| |
|
|
|
| |
To do so, merge the remainnig necessary code from the buffers, blit, span, and
screen code to shared, and replace it with those.
|
| | |
|
| |
|
|
|
|
|
|
| |
Putting the bufmgr in the screen is not thread-safe since the emit_reloc
changes. It also led to a significant performance hit from pthread usage
for the attempted thread-safety (up to 12% of a cpu spent on refcounting
protection in single-threaded 965). The motivation had been to allow
multi-context bufmgr sharing in classic mode, but it wasn't worth the cost.
|
| |
|
|
|
| |
This requires that regions grow a marker of whether they are tiled or not,
because fence (surface) registers are ignored by the 965 2D engine.
|
| | |
|
| |
|
|
|
|
| |
This was replaced in previous releases of xserver/dri/libGL by reporting the
damage to the frontbuffer so that the server and driver could handle it
appropriately.
|
| | |
|
| |
|
