| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
intel_swapbuffers.c
|
|
|
|
|
|
|
|
|
|
Fix the last merge fix, had the blocks ordered incorrectly.
|
|
Bah, applied the patches in the wrong order, not Owain's fault...
|
|
On Mobile chipsets, we often enable PipeB instead of PipeA, but the test
in here was insufficient, falling back to pipe A if the area
intersection returned zero. Therefore, in the case where a window went
off to the top of the left of the screen, it would freeze, waiting on
the wrong vblank.
Fix this mess by checking the sarea for a crtc being zero sized, and in
that case always default to the other one.
|
|
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.
|
|
At this point, GL_EXT_stencil_two_side should probably be disabled.
It may be worth leaving it enabled because it has GLX protocol while
GL_ATI_separate_stencil does not. I'll leave it to one of the r300
maintainers to make the call.
|
|
|
|
|
|
Track separate back-face stencil state for OpenGL 2.0 /
GL_ATI_separate_stencil and GL_EXT_stencil_two_side. This allows all
three to be enabled in a driver. One set of state is set via the 2.0
or ATI functions and is used when STENCIL_TEST_TWO_SIDE_EXT is
disabled. The other is set by StencilFunc and StencilOp when the
active stencil face is set to BACK. The GL_EXT_stencil_two_side spec has
more details.
http://opengl.org/registry/specs/EXT/stencil_two_side.txt
|
|
|
|
|
|
This functionality is required by GL_ARB_framebuffer_object.
For now, implement it in terms of glCopyPixels(). This will need to be
revisted though.
|
|
We only allow combined depth+stencil renderbuffers so the complicated code
for splitting and combining separate depth and stencil buffers is no longer
needed.
|
|
|
|
The preceeding call to intel_draw_buffer() does that.
|
|
Take advantage of the GL_FRAMEBUFFER_UNSUPPORTED feature to disallow separate
depth and stencil renderbuffers; only allow combined depth/stencil buffers.
Next up: remove/simplify a bunch of the depth/stencil renderbuffer code.
Also: restore the previously disabled GL_DEPTH_COMPONENT16 case
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Oops.
|
|
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.
|
|
It's been broken and deprecated for a while, so it's time to die. This has the
wonderful benefit of cleaning up the code a fair amount; making it marginally
less twisty.
I'm unsure if the for loops in IntelWindowMoved are still needed.
|
|
Dri drivers often may validate first a write drawable and then a read
drawable ("readable"). However, the hardware lock may be unlocked when
validating the readable, causing the write drawable status to be stale.
Drivers should use this macro instead when validating two drawables.
|
|
Since we use an inverted viewport transformation for render to texture, that
inverts front/back polygon orientation.
Now glCullFace(GL_FRONT / GL_BACK) works correctly.
|
|
When we're rendering to textures we have to invert the viewport transformation.
This helper cleans up that test and can be used elsewhere...
|
|
|
|
See bug 17929.
Fog doesn't actually work, but the often complained about warning is
silenced.
|
|
OpenGL allows mixing and matching depth and stencil renderbuffers in
framebuffer objects while the hardware really only supports interleaved
depth/stencil buffers. This makes for some tricky buffer management.
An extra wrinkle is the situation where the user allocates a 16bpp depth
texture or renderbuffer then tries to render to it along with a stencil
buffer. We'd have to promote the 16bpp Z values to 24-bit Z values and
mix in the stencil values to setup the depth/stencil renderbuffer.
There's no support for that now, so always allocate 32bpp depth textures/
renderbuffers for now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
