| 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.
|
|
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].
|
|
There was a note in state.c about _Active deserving to die, and there were
potential issues with it due to i965 forgetting to set _UseTexEnvProgram.
Removing both simplifies things.
Reviewed-by: Brian Paul <brianp@vmware.com>
|
|
The DrawPixels path was missing glViewport care, so blender's toolbar icons
would go to the wrong places.
Bug #19118.
|
|
This lets us avoid software fallbacks when clients forget to turn some state
off (engine demo) or just do crazy things to test conformance (OGLC).
This should probably be brought into mesa generic code so other drivers can
make use of it.
Bug #19016.
|
|
Thanks to Eric for pointing it out.
|
|
|
|
|
|
This is part of the deprecated pageflipping infrastructure.
|
|
Bug #19139.
|
|
|
|
|
|
|
|
glCopyTexSubImage already gets the (correct) clipping for us, so it doesn't
need the path. While moving the clipping out, replace the code with the mesa
path to do the same job.
|
|
|
|
Fixes double-frees of some regions, once from the renderbuffer code and
once from the miptree itself.
Bug #19062
|
|
|
|
|
|
|
|
This leads to problems when the batchbuffer is flushed, but the bitmap
data could not fit into it.
|
|
Fixes a segfault in oglconform fbo.c test.
|
|
The images aren't mapped at this point, so we want the generic Mesa path for
GenerateMipmapEXT that does the mapping/unmapping for us. Ideally Mesa would
just call it for us.
|
|
This was another opportunity to either get clipped to screen size or not get
clipped enough and draw outside of object boundaries.
|
|
Bug #18914. Fixes fbo_firecube hang due to drawing outside the FBO bounds.
Thanks to Pierre Willenbrock for debugging the issue.
|
|
|
|
Intel docs state that only 830/845 have VBOs, 855/865 don't. So
lets just not use them on i8xx at all.
This restores the old pre-vbo code and uses it on all 8xx hw.
|
|
There were hacks in EmitCopyBlit before to adjust offsets so that y=0 after
the offsets had been adjusted for a negative pitch. It appears that those
hacks were due to an unclear and surprising aspect of the hardware: inverting
the pitch results in the blit into the specified rectangle being inverted,
without the user needing to adjust y and base offset.
Tested with piglit copytexsubimage test on 915GM and GM965. Should fix
serious performance issues with ETQW and other applications.
|
|
The blit bitmap code already handles scissoring. This is a 15-100% speedup on
blender benchmark.blend thanks to avoiding fallbacks. Bug #17951.
|
|
Instead, have i965 and i915 both call the generic function from their Viewport.
|
|
According to Keith the docs have these offsets the other way around
|
|
|
|
|
|
This ensures all batchbuffers have a same cliprect mode after calling
_intel_batchbuffer_flush even if there aren't invalid commands in the
current batch buffer. (fix bug#18362).
|
|
The mobile and desktop chipsets are the same, and having them separate is
more typing and more chances to screw up.
|
|
|
|
GL_COLOR_INDEX mode is just like other normal formats (that is, not
depth/stencil) and is uploaded fine by TexImage.
|
|
|
|
|
|
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.
|
|
Previously, we were trying to pass a name to the GEM GET_TILING_IOCTL,
which needs a handle, and failing. None of our buffers were tiled yet, but
they will be at some point with DRI2 and UXA.
|
|
(thanks Eric).
|
