| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Hopefully this will be one of the last cherry-picks.
(cherry picked from commit ca246dd186f9590f6d67038832faceb522138c20)
|
|
(cherry picked from commit df70d3049a396af3601d2a1747770635a74120bb)
|
|
The comment disagreed with the code, and nicely drew my eyes to what was
going wrong.
Bug #21774 (blender)
Bug #21788 (readpix)
(cherry picked from master, commit fd65418f600874b05f902b622078b40bc1abb24a)
|
|
This fixes jerkiness in doom3 and other apps since the kernel change to
throttle less absurdly, which led to a thundering herd of frames.
Because this is a rather minimal fix, there is at least one downside: If
the whole scene completes in one batchbuffer, we'll end up stalling the GPU.
Thanks to Michel Dänzer for suggesting using glFlush to signal frame end
instead of going to all the effort of adding a new DRI2 extension.
(cherry picked from master, commit 0828579a658af01a64b5e699175dc9bbbedcd685)
|
|
(cherry picked from commit ddef7dc87b2001fbe117ee5f24a0c645ee95a03c)
|
|
|
|
This fixes a segfault seen with piglit's fdo20701 test.
|
|
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)
|
|
Fixes segfault in context tear-down when glClear was never called.
|
|
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().
|
|
|
|
|
|
|
|
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.
|
|
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.
|
