| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
Makefile
src/gallium/drivers/softpipe/sp_screen.c
src/mesa/main/version.h
|
|
To maintain correctness, the server will copy the real front-buffer to
a newly allocated fake front-buffer in DRI2GetBuffersWithFormat.
However, if the DRI2GetBuffersWithFormat is triggered by glViewport,
this will copy stale data into the new buffer. Fix this by flushing
the current fake front-buffer to the real front-buffer in
intel_viewport.
Fixes bug #22288.
|
|
(cherry picked from commit d4a42b0ce6455d03be70aa56aacd779be193aca4)
|
|
|
|
|
|
Initialize all driver function hooks before calling _mesa_initialize_context(),
and handle all buffer objects in intel_buffer_object().
Fixes assertion failure when running glxinfo.
|
|
The early Z stuff is supposed to be unsafe without some more work in the
enable/disable path (in particular, how do we want to get it disabled on
the way out to the X Server?), but at the moment is 6% in OA.
|
|
|
|
This is about a 30% performance win in OA with high settings on my GM45,
and experiments with 915GM indicate that it'll be around a 20% win there.
Currently, 915-class hardware is seriously hurt by the fact that we use
fence regs to control the tiling even for 3D instructions that could live
without them, so we spend a bunch of time waiting on previous rendering in
order to pull fences off. Thus, the texture_tiling driconf option defaults
off there for now.
|
|
Limit the maximum renderbuffer size to 8192 on i965 and to 2048 on
earlier hardware.
|
|
|
|
Fixes segfault in context tear-down when glClear was never called.
|
|
Conflicts:
src/mesa/main/arrayobj.c
src/mesa/main/arrayobj.h
src/mesa/main/context.c
|
|
gl_array_object encapsulates a set of vertex arrays (see the
GL_APPLE_vertex_array_object extension).
Create a private gl_array_object for drawing the quad for intel_clear_tris()
so we don't have to worry about the user's vertex array state.
This fixes the no-op glClear bug #21638 and removes the need to call
_mesa_PushClientAttrib() and _mesa_PopClientAttrib().
|
|
|
|
A temporary change to the intelMakeCurrent() function to make
it work with frame buffer objects causes the static regions
associated with the context (the front_region, back_region,
and depth_region) to take on an additional reference, with
no corresponding release. This causes a memory leak if a
program repeatedly creates and destroys contexts.
The fix is the corresponding hack, to unreference these
regions when the context is deleted, but only if the
framebuffer objects are still present and the same
regions are still referenced within.
Both sets of code have comment blocks referring to each
other.
|
|
|
|
|
|
|
|
This interface gives the driver two important features. First, it can
allocate the (fake) front-buffer only when needed. Second, it can
tell the buffer allocator the format of buffers being allocated. This
enables support for back-buffer and depth-buffer with different bits
per pixel.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
|
|
i915 actually supports up to 4 (according to header file - not tested),
i965 up to 16 (code already handled this but slightly broken), so don't use 2
for all chips, even though angular dependency is very high.
|
|
Fixes segfaults when rendering to front buffer.
|
|
Handle the loader returning a fake front-buffer. Since the driver
never specifically requests a fake front-buffer, the driver assumes
that it will never receive both a fake and a real front-buffer.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
|
|
Track two flags: whether or not front-buffer rendering is currently
enabled and whether or not front-buffer rendering has been enabled
since the last glFlush. If the second flag is set, the front-buffer
is flushed via a loader call back. If the first flag is cleared, the
second flag is cleared at this time.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kristian Høgsberg <krh@redhat.com>
|
|
This gets us the savings for driver-internal viewport calls that
dd1c68f15123a889a3ce9d2afe724e272d163e32 was attempting, without relying
on Xlib internals or clients handling X events.
|
|
This can improve debugging with INTEL_DEBUG=batch,sync by giving smaller
batchbuffers.
|
|
I keep wanting to hack this knob in as a one-time thing, so it seemed useful
to have all the time.
|
|
The i965 hardware cannot do GL_CLAMP behavior on textures; an earlier
commit forced a software fallback if strict conformance was required
(i.e. the INTEL_STRICT_CONFORMANCE environment variable was set) and
2D textures were used, but it was somewhat flawed - it could trigger
the software fallback even if 2D textures weren't enabled, as long
as one texture unit was enabled.
This fixes that, and adds software fallback for GL_CLAMP behavior with
1D and 3D textures.
It also adds support for a particular setting of the INTEL_STRICT_CONFORMANCE
environment variable, which forces software fallbacks to be taken *all*
the time. This is helpful with debugging. The value is:
export INTEL_STRICT_CONFORMANCE=2
|
|
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
|
|
Everything other than "make sure the last rendering ends up visible on the
screen" doesn't need that behavior.
|
|
|
|
|
|
|
|
|
|
intel_swapbuffers.c
|
|
|
|
|
|
intelMakeCurrent is called before intelWindowMoved (in fact, it calls
it), so calculation of the correct vblank crtc has not happened yet.
Fix this by making a function that fixes up a set of vblank flags and
call if from both functions.
|
|
|
|
Simply a matter of choosing the right surface/vertex format for GLubyte/GL_BGRA arrays.
|
|
|
|
|
|
This functionality is required by GL_ARB_framebuffer_object.
For now, implement it in terms of glCopyPixels(). This will need to be
revisted though.
|
|
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.
|
