summaryrefslogtreecommitdiff
path: root/src/mesa/drivers/dri/intel/intel_context.c
AgeCommit message (Collapse)Author
2008-07-01intel-gem: Move bit 6 x tiling swizzle to a driconf option, and add new mode.Eric Anholt
It turns out that it's not just deviceID dependent, and there's some additional undefined factor that determines the bit 6 swizzling. It's now controllable with swizzle_mode=[012] until we get a response on how to automatically detect.
2008-06-26intel: Replace sprinkled intel_batchbuffer_flush with MI_FLUSH or nothing.Eric Anholt
Most of these were to ensure that caches got synchronized between 2d (or meta) rendering and later use of the target as a source, such as for texture miptree setup. Those are replaced with intel_batchbuffer_emit_mi_flush(), which just drops an MI_FLUSH. Most of the remainder were to ensure that REFERENCES_CLIPRECTS batchbuffers got flushed before the lock was dropped. Those are now replaced by automatically flushing those when dropping the lock.
2008-06-24Merge commit 'origin/master' into drm-gemEric Anholt
2008-06-24intel: Same pixel function init for everyone now.Eric Anholt
2008-06-23i915: Accumulate the VB into a local buffer and subdata it in.Eric Anholt
This lets GEM use pwrite, for an additional 4% or so speedup.
2008-06-18Merge commit 'origin/master' into drm-gemEric Anholt
2008-06-18i965: add support for Intel 4 series chipsetsXiang, Haihao
2008-06-17[intel] Fix no_rast option on non-965.Eric Anholt
The no_rast fallback was getting partially overwritten by later TNL init, resulting in a segfault when things were in a mixed-up state.
2008-06-03[intel] Convert drivers to using libdrm bufmgr code.Eric Anholt
2008-05-23Remove stale comment about glFlush().Eric Anholt
We don't need an MI_FLUSH there, because everything that's been flushed in the batch will eventually hit the hardware.
2008-05-22Add back a mostly-correct glFinish for GEM and fake.Eric Anholt
The right solution would probably be keeping a list of regions which have been rendered to.
2008-05-07GEM: Make dri_emit_reloc take GEM domain flags instead of TTM flags.Eric Anholt
The GEM flags are much more descriptive for what we need. Since this makes bufmgr_fake rather device-specific, move it to the intel common directory. We've wanted to do device-specific stuff to it before.
2008-05-06[intel-GEM] Add tiling support to swrast.Keith Packard
Accessing tiled surfaces without using the fence registers requires that software deal with the address swizzling itself.
2008-05-02[intel] Fix build for GEM. TTM is now disabled, and fencing is gone.Eric Anholt
Fencing was used in two places: ensuring that we didn't get too many frames ahead of ourselves, and glFinish. glFinish will be satisfied by waiting on buffers like we would do for CPU access on them. The "don't get too far ahead" is now the responsibility of the execution manager (kernel).
2008-03-31DRI interface changes and DRI2 direct rendering support.Kristian Høgsberg
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.
2008-03-25intel: fix the issue "VBO: Cannot allocate memory for a BO" onXiang, Haihao
965 after merging intel_context.c from i915 and i965. fix bug# 15152.
2008-03-19 [i915] arb point sprite only support in i965Zou Nan hai
2008-03-09DRI2: Pass the context instead of the screen to __dri2ParseEvents().Kristian Høgsberg
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.
2008-03-07[intel] Only enable GL_EXT_texture_sRGB on i965.Kristian Høgsberg
Fixes #14799.
2008-03-05[intel] Add a driconf option to cache freed buffer objects for reuse.Eric Anholt
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.
2008-02-29Use __DRIextension mechanism providing loader functionality to the driver.Kristian Høgsberg
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.
2008-02-29Reduce the versioning madness required to create a DRI2 screen.Kristian Høgsberg
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.
2008-02-29intel: Set the lock flag early to avoid deadlock.Kristian Høgsberg
Another regression from the intel_context.c merge.
2008-02-27intel: Always use intelInitExtensions() for initializing extensions.Kristian Høgsberg
2008-02-25intel: Only enable GL_ARB_occlusion_query on i965.Kristian Høgsberg
2008-02-22intel: Merge intel_context.c from i915 and i965.Kristian Høgsberg
2008-02-22Merge {i915,i965}/intel_context.h as intel/intel_context.hKristian Høgsberg