| Age | Commit message (Collapse) | Author |
|---|
|
Instead, have i965 and i915 both call the generic function from their Viewport.
|
|
This avoids issues with dereferencing stale cliprects around intel_draw_buffer
time. Additionally, take advantage of cliprects staying constant for FBOs and
DRI2, and emit cliprects in the batchbuffer instead of having to flush batch
each time they change.
|
|
|
|
|
|
Move GL_ARB_texture_non_power_of_two and GL_ATI_separate_stencil
from the generic extension list to the 965-specific list. Neither
extension is supported on i830-class hardware, and
GL_ATI_separate_stencil is not supported on i915-class hardare.
GL_ARB_texture_non_power_of_two is supported on i915-class hardare and
is already in the i915-specific list.
|
|
The ARB extension is a superset of the older SGIX extension. Any
hardware that can support the SGIX version can also support the ARB
version. In Mesa, any driver that supports one also supports the
other. This unification just simplifies some bits of code.
|
|
- Sort extensions by ARB, then EXT, then vendor by name
- Remove redundant (only one of GL_{ARB,EXT,NV}_texture_rectangle) or
duplicate extension strings
|
|
|
|
Brought over from gallium-0.2 branch.
|
|
Makefile.template
|
|
Caused server crashes on second context creation since
7e0bbdcf033981282978554c2e68ce48b55aa291.
Bug #17600.
|
|
Otherwise, we would use the pitch as width of the texture, and compiz would
render the pitch padding on the right hand side.
|
|
|
|
|
|
|
|
|
|
Mesa requires that we be able to share objects between contexts, which means
that the objects need to be created by the same bufmgr, and the bufmgr
internally requires pthread protection for thread safety.
Rely on the bufmgr having appropriate locking.
|
|
This interface has to be re-written to not be dumb and to work
for multiple apps.
|
|
(Reverts a change to work around the problem on 965).
|
|
|
|
|
|
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
|
|
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
(bug #16852, #16853)
|
|
|
|
Conflicts:
src/mesa/drivers/dri/common/dri_bufmgr.c
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
Bump the driver date and insert the string "GEM". When running tests,
this make it much easier to know that the right driver is being used.
|
|
Enable support for ARB_texture_env_crossbar in the master extension
list instead of in every single device-specific list.
|
|
|
|
|
|
We have something similar in the X Server that covers X Server rendering, this
is the equivalent here for rendering to the front buffer. If we cared about
avoiding this at glFlush time, we could only do this when some actual
frontbuffer rendering had occurred.
Bug #16392.
|
|
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.
|
|
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.
|
|
|
|
|
|
This lets GEM use pwrite, for an additional 4% or so speedup.
|
|
|
|
|
|
The no_rast fallback was getting partially overwritten by later TNL init,
resulting in a segfault when things were in a mixed-up state.
|
|
|
|
We don't need an MI_FLUSH there, because everything that's been flushed in the
batch will eventually hit the hardware.
|
|
The right solution would probably be keeping a list of regions which have been
rendered to.
|
|
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.
|
|
Accessing tiled surfaces without using the fence registers requires that
software deal with the address swizzling itself.
|
|
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).
|
|
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.
|
|
965 after merging intel_context.c from i915 and i965. fix bug# 15152.
|
|
|
|
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.
|
