| Age | Commit message (Collapse) | Author |
|---|
|
The upstream linux kernel headers and libdrm kernel headers disagree on the
tag name for the sarea struct: _drm_i915_sarea vs drm_i915_sarea. They
both typedef it to drm_i915_sarea_t though, so just use that.
|
|
|
|
Thanks to Eric for pointing it out.
|
|
|
|
This is part of the deprecated pageflipping infrastructure.
|
|
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).
|
