aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i915
Commit message (Collapse)AuthorAgeFilesLines
* i915: Fix 945 cube map layout for the small mipmaps along the bottom.Steinar H. Gunderson2009-05-151-2/+14
| | | | Bug #21691.
* i915: Only use the new 945 cube layout for compressed textures.Eric Anholt2009-05-151-1/+4
| | | | | | | | | The docs actually explain this, but not in a terribly clear manner. This nearly fixes the piglit cubemap testcase, except that something's going wrong with the nearest filtering at 2x2 sizes in the testcase. Looks good by visual inspection, though. Bug #21692
* i915: Fix driver after HW glGenerateMipmap commit.Eric Anholt2009-05-121-0/+1
|
* intel: Add a metaops version of glGenerateMipmapEXT/SGIS_generate_mipmaps.Eric Anholt2009-05-081-0/+1
| | | | | | | In addition to being HW accelerated, it avoids the incorrect (black) rendering of the mipmaps that SW was doing in fbo-generatemipmap. Improves the performance of the mipmap generation and drawing in fbo-generatemipmap by 30%.
* Merge branch 'const-buffer-changes'Brian Paul2009-05-011-1/+1
|\ | | | | | | | | | | | | | | Conflicts: src/mesa/drivers/dri/i965/brw_curbe.c src/mesa/drivers/dri/i965/brw_vs_emit.c src/mesa/drivers/dri/i965/brw_wm_glsl.c
| * i915: check the new _NEW_PROGRAM_CONSTANT flagBrian Paul2009-04-221-1/+1
| |
* | i915: fix fix for anisotropic filteringRoland Scheidegger2009-04-231-2/+7
| | | | | | | | forgot to commit the changes to actually support 4x aniso filtering...
* | intel: fix max anisotropy supportedRoland Scheidegger2009-04-222-0/+4
|/ | | | | | 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.
* Merge branch 'register-negate'Brian Paul2009-04-161-5/+5
|\
| * mesa: merge the prog_src_register::NegateBase and NegateAbs fieldsBrian Paul2009-04-141-5/+5
| | | | | | | | | | | | There's really no need for two negation fields. This came from the GL_NV_fragment_program extension. The new, unified Negate bitfield applies after the absolute value step.
* | i915: Remove dead i830TexEnv and i915TexEnv.Eric Anholt2009-04-165-182/+0
| | | | | | | | | | These LOD bias updates are covered by the texture state uploads in *_texstate.c now.
* | intel: Add support for argb1555, argb4444 FBOs and fix rgb565 fbo readpixels.Eric Anholt2009-04-162-11/+47
| | | | | | | | | | | | Also enable them all regardless of screen bpp, as 32 bpp what I've been testing against, and haven't been able to detect any screen bpp-specific troubles with them.
* | i915: Use DEBUG_WM (like 965) for printing the fragment program out.Eric Anholt2009-04-151-4/+2
|/ | | | | This is nice when paired with INTEL_DEBUG=batch for debugging what's going out to the hardware.
* dri: use BorderColor instead of _BorderChanBrian Paul2009-04-012-12/+24
|
* Fix DRI2 accelerated EXT_texture_from_pixmap with GL_RGB format.Eric Anholt2009-03-202-6/+15
| | | | | | | | | | | | | | This requires upgrading the interface so that the argument to glXBindTexImageEXT isn't just dropped on the floor. Note that this only fixes the accelerated path on Intel, as Mesa's texture format support is missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as a8r8gb8, but in this case we're not doing the upload so we can't really work around it that way). Fixes bugs with compositors trying to use shaders that use alpha channels, on windows without a valid alpha channel. Bug #19910 and likely others as well. Reviewed-by: Ian Romanick <[email protected]>
* i915: move declarations before codeBrian Paul2009-03-122-4/+4
|
* i965: add software fallback for conformant 3D textures and GL_CLAMPRobert Ellison2009-03-041-2/+2
| | | | | | | | | | | | | | | | | 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
* mesa: rename, reorder FRAG_RESULT_x tokensBrian Paul2009-02-281-2/+2
| | | | | | | s/FRAG_RESULT_DEPR/FRAG_RESULT_DEPTH/ s/FRAG_RESULT_COLR/FRAG_RESULT/COLOR/ Remove FRAG_RESULT_COLH (NV half-precision) output since we never used it. Next, we might merge the COLOR and DATA outputs (COLOR0, COLOR1, etc).
* intel: Clean up several 965 memory leaks on context destroy.Eric Anholt2009-02-172-0/+4
|
* i915: updated render to texture/fbo testBrian Paul2009-01-301-12/+3
|
* i915: Only call CalcViewport from DrawBuffers instead of Viewport.Eric Anholt2009-01-301-1/+2
| | | | | This saves an inadvertent round-trip to the X Server on DrawBuffers, which was hurting some metaops.
* Remove stale symlinks to intel/intel_depthstencil.cIan Romanick2009-01-301-1/+0
|
* intel: Fix up some extension string issuesIan Romanick2009-01-281-13/+0
| | | | | Move the remaining extension string enables to intel_extensions.c. Make sure that GL_NV_texture_env_combine4 is not enabled on i830.
* Make GL_ARB_draw_buffers mandatoryIan Romanick2009-01-282-0/+4
| | | | Signed-off-by: Ian Romanick <[email protected]>
* i915: rename some functionsBrian Paul2009-01-261-4/+4
|
* intel: replace i915/intel_state.c and i965/intel_state.c with shared fileBrian Paul2009-01-261-233/+1
|
* intel: whitespace changesBrian Paul2009-01-261-13/+13
|
* intel: move some driver functions aroundBrian Paul2009-01-262-64/+70
| | | | A step toward consolidating i915/intel_state.c and i965/intel_state.c
* intel: move intelInitExtensions() and related code into new intel_extensions.cBrian Paul2009-01-262-1/+3
|
* intel: move glClear-related code into new intel_clear.c fileBrian Paul2009-01-262-0/+2
|
* intel: Move swap-related functions from intel_buffers.c to new ↵Brian Paul2009-01-262-0/+2
| | | | intel_swapbuffers.c
* intel: remove/disable the "paired depth/stencil" codeBrian Paul2009-01-221-2/+1
| | | | | | We only allow combined depth+stencil renderbuffers so the complicated code for splitting and combining separate depth and stencil buffers is no longer needed.
* i915: Add decode for PS in batchbuffers.Eric Anholt2009-01-211-0/+4
|
* [intel] Remove remaining references to intel_wait_flips().Kristian Høgsberg2009-01-211-5/+1
| | | | Oops.
* mesa: Remove _Active and _UseTexEnvProgram flags from fragment programs.Eric Anholt2009-01-072-2/+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 <[email protected]>
* intel: disable ATI_texture_env_combine3 for i830( and related device).Xiang, Haihao2008-12-301-0/+1
| | | | Thanks to Eric for pointing it out.
* i915: separate the fog term from the specular color term.Xiang, Haihao2008-12-241-19/+3
| | | | | | | | Previously fog parameter and specular color are packed into the same dword. Note specular color should be packed in BGRA for device, so if fog parameter and specular color all are present, fog parameter will dirty the alpha term of specular color. This fixes rendering issue when playing 'Yo Frankie' on 915/945.
* i915: check WRAP_T instead of WRAP_R for cube map texture.Xiang, Haihao2008-12-181-1/+1
|
* i915: fix abort issue. (bug #19147)Xiang, Haihao2008-12-182-4/+24
|
* i915: fallback for cube map texture.Xiang, Haihao2008-12-111-0/+7
| | | | | | | The i915 (and related graphics cores) only support TEXCOORDMODE_CLAMP and TEXCOORDMODE_CUBE when using cube map texture coordinates, so fall back to software rendering for other modes to avoid potential gpu hang issue. This fixes scorched3d issue on 945GM(see bug 14539).
* intel: restore old vertex submit paths for i8xx hardware.Dave Airlie2008-12-022-4/+119
| | | | | | | 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.
* i915: Don't overwrite i915's Viewport function from generic code.Eric Anholt2008-11-211-0/+2
| | | | Instead, have i965 and i915 both call the generic function from their Viewport.
* intel: fix i830 comment + backwards VB offsets.airlied2008-11-201-1/+1
| | | | According to Keith the docs have these offsets the other way around
* intel: Don't keep intel->pClipRects, and instead just calculate it when needed.Eric Anholt2008-10-284-2/+73
| | | | | | | 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.
* i915: fix carsh in i830_emit_state. (bug #17766)Xiang, Haihao2008-10-211-1/+2
|
* i915: Texture instructions use r/t/oC/oD register as texture coordinate.Xiang, Haihao2008-10-131-0/+13
| | | | Fix http://bugs.freedesktop.org/show_bug.cgi?id=16287.
* i915: Accelerate depth textures with border color.Eric Anholt2008-10-081-4/+15
| | | | | The fallback was introduced to fix bug #16697, but made the test it was fixing run excessively long.
* i915: Refine the texture indirect lookup accounting.Eric Anholt2008-10-042-3/+25
| | | | | | | | | | | | | Without this, we would reject programs which sampled multiple times from registers defined in the same phase (block of instructions with the same texture indirection count), as each sample would count as a new phase beginning. Instead, keep track of which phases registers were written in, and only bump phase when we're reading from one generated in this phase. On the other hand, we failed to count oC or oD texture samples as being new phases. Bug #17865.
* Unify ARB_depth_texture and SGIX_depth_textureIan Romanick2008-10-011-2/+0
| | | | | | | 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.
* intel: Fix a number of memory leaks on context destroy.Eric Anholt2008-09-262-0/+14
|