Age | Commit message (Collapse) | Author |
|
Move the remaining extension string enables to intel_extensions.c.
Make sure that GL_NV_texture_env_combine4 is not enabled on i830.
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
|
|
If the texture swizzle is not XYZW (no-op) add an extra MOV instruction
after the TEX instruction to rearrange the components.
|
|
|
|
|
|
A step toward consolidating i915/intel_state.c and i965/intel_state.c
|
|
|
|
intel_meta_set_passthrough_transform(), intel_meta_restore_transform()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
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.
|
|
When we're rendering to textures we have to invert the viewport transformation.
This helper cleans up that test and can be used elsewhere...
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
As for glBitmap, it needs to be an NDC coord in [-1,1].
|
|
When we use the do_blit_bitmap() function, it seems the fragment Z is always
1.0. If depth testing is on, that means that bitmap fragments are often
occluded by other rendering. So, the bitmap doesn't appear even if
rasterpos.Z==0.
The fix is to use the intel_texture_bitmap() path when depth testing is on.
Also, fix the incorrect Z coordinate. It needs to be an NDC value in [-1,1].
|