summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri
Commit message (Collapse)AuthorAgeFilesLines
* intel: Clean up the function chain for mapping texture images for swrast.Eric Anholt2011-10-033-113/+65
| | | | | | Too many separate functions each called from one location (in different files). This code should all die soon when swrast starts using MapTextureImage.
* intel: Make PBO TexImage use AllocTextureImageBuffer like non-PBO does.Eric Anholt2011-10-032-54/+21
| | | | | Now that whole block that also lives in AllocTextureImageBuffer can go away.
* intel: Rely on Mesa core for glTexImage storage.Eric Anholt2011-10-031-52/+4
| | | | Reviewed-by: Brian Paul <[email protected]>
* intel: Allocate s8z24 separate renderbuffers from AllocTextureImageBuffer().Eric Anholt2011-10-033-1/+9
| | | | | | Before, we were only allocating these from our TexImage, so if the texture image was set up in any other way (non-accelerated glGenerateMipmaps()), they'd be missing or wrong.
* intel: Add an AllocTextureImageBuffer() implementation using miptrees.Eric Anholt2011-10-033-1/+50
| | | | | Now we can rely on Mesa core for uploads of data without introducing an extra copy at validate time.
* mesa: Convert _mesa_generate_mipmap to MapTexImage()-based access.Brian Paul2011-10-033-88/+2
| | | | | | | | | | | Now that we can zero-copy generate the mipmaps into brand new glTexImage()-generated storage using MapTextureImage(), we no longer need to allocate image->Data in mipmap generate. This requires deleting the drivers' old overrides of the miptree tracking after calling _mesa_generate_mipmap at the same time, or the drivers promptly lose our newly-generated data. Reviewed-by: Eric Anholt <[email protected]>
* i965: Stop lowering integer division to multiply and reciprocal.Kenneth Graunke2011-10-021-1/+0
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Tested-by: Ian Romanick <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Reverse the operands for INT DIV prior to Gen6.Kenneth Graunke2011-10-022-4/+30
| | | | | | | | | Apparently on Gen4 and 5, the denominator comes first. Signed-off-by: Kenneth Graunke <[email protected]> Tested-by: Ian Romanick <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Implement integer quotient and remainder math operations.Kenneth Graunke2011-10-023-4/+24
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Tested-by: Ian Romanick <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Implement integer quotient and remainder math operations.Kenneth Graunke2011-10-027-4/+32
| | | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Tested-by: Ian Romanick <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Set the signed/unsigned type bit in Gen4/5 math messages.Kenneth Graunke2011-10-021-1/+1
| | | | | | | | | It never mattered before since we only did floating point math. Signed-off-by: Kenneth Graunke <[email protected]> Tested-by: Ian Romanick <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix message and response length calculations for INT DIV.Kenneth Graunke2011-10-021-10/+28
| | | | | | | | | | | | | | | | | | Both POW and INT DIV need a message length of 2; previously, we only checked for POW. Also, BRW_MATH_FUNCTION_INT_DIV_QUOTIENT_AND_REMAINDER has a response length of 2; previously, we only checked for SINCOS. We don't use this message, but in case we ever decide to, we may as well fix it now. While we're at it, just move these computations into brw_set_math_message, since they're entirely based on the function. This fixes it for both brw_math and the old backend's brw_math_16. Signed-off-by: Kenneth Graunke <[email protected]> Tested-by: Ian Romanick <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Fix assertions about register types for INT DIV in brw_math.Kenneth Graunke2011-10-021-4/+11
| | | | | | | | | | BRW_MATH_FUNCTION_REMAINDER was missing. Also, it seems worthwhile to assert that INT DIV's arguments are signed/unsigned integers. Signed-off-by: Kenneth Graunke <[email protected]> Tested-by: Ian Romanick <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Make sure to upload the data for a collection of Stride == 0 arrays.Eric Anholt2011-10-011-1/+18
| | | | | | | | Commit d631c19db47181129811080bfa772b210d762d4d avoided this problem by forcing the driver to get the min/max index, but that commit was broken, so just fix the driver problem (confusion between "do I need to upload any data?" and "do I need the index bounds in order to upload any data?").
* i965/vs: Fix swizzle related assertionIan Romanick2011-10-011-1/+2
| | | | | | | | | | | | | | | | | As innocuous as it seemed, ebca47a basically broke the world (e.g., >200 piglit regressions). In vec4_visitor::emit_block_move, src->swizzle was expected to be BRW_SWIZZLE_NOOP before setting it to a swizzle that would replicate the existing channels of the source type to a vec4 (e.g., .xyyy for a vec2). The original assertion seems to have been a little bogus. In addition to being BRW_SWIZZLE_NOOP, src->swizzle might already be a swizzle that would replicate the existing channels of the source type to a vec4. In other words, it might already have the value that we're about to assign to it. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* r600: include version.h for _mesa_override_glsl_version() prototypeBrian Paul2011-10-011-0/+1
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i915: out-of-bounds write in calc_live_regs()Chris Wilson2011-09-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From a Coverity defect report. src/mesa/drivers/dri/i915/i915_fragprog.c 301 /* 302 * TODO: consider moving this into core 303 */ 304 static bool calc_live_regs( struct i915_fragment_program *p ) 305 { 306 const struct gl_fragment_program *program = &p->FragProg; 307 GLuint regsUsed = 0xffff0000; -> 308 uint8_t live_components[16] = { 0, }; 309 GLint i; 310 311 for (i = program->Base.NumInstructions - 1; i >= 0; i--) { 312 struct prog_instruction *inst = &program->Base.Instructions[i]; 313 int opArgs = _mesa_num_inst_src_regs(inst->Opcode); 314 int a; 315 316 /* Register is written to: unmark as live for this and preceeding ops */ 317 if (inst->DstReg.File == PROGRAM_TEMPORARY) { -> 318 if (inst->DstReg.Index > 16) 319 return false; 320 -> 321 live_components[inst->DstReg.Index] &= ~inst->DstReg.WriteMask; 322 if (live_components[inst->DstReg.Index] == 0) 323 regsUsed &= ~(1 << inst->DstReg.Index); 324 } 325 326 for (a = 0; a < opArgs; a++) { 327 /* Register is read from: mark as live for this and preceeding ops */ 328 if (inst->SrcReg[a].File == PROGRAM_TEMPORARY) { 329 unsigned c; 330 331 if (inst->SrcReg[a].Index > 16) 332 return false; 333 334 regsUsed |= 1 << inst->SrcReg[a].Index; 335 336 for (c = 0; c < 4; c++) { 337 const unsigned field = GET_SWZ(inst->SrcReg[a].Swizzle, c); 338 339 if (field <= SWIZZLE_W) 340 live_components[inst->SrcReg[a].Index] |= (1U << field); 341 } 342 } 343 } 344 345 p->usedRegs[i] = regsUsed; 346 } Reported-by: Vinson Lee <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40022 Signed-off-by: Chris Wilson <[email protected]>
* i965: Assign instead of compare inside assertChris Wilson2011-09-301-1/+1
| | | | | | | | | | | | | | | | | | This is from a Coverity defect report. src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp 1314 void 1315 vec4_visitor::emit_block_move(dst_reg *dst, src_reg *src, 1316 const struct glsl_type *type, bool predicated) ... 1351 /* Do we need to worry about swizzling a swizzle? */ ->1352 assert(src->swizzle = BRW_SWIZZLE_NOOP); 1353 src->swizzle = swizzle_for_size(type->vector_elements); Reported-by: Vinson Lee <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40158 Signed-off-by: Chris Wilson <[email protected]>
* i965/gen6: Fix assign instead of compare in assertChris Wilson2011-09-301-1/+1
| | | | | | | | | | | | | | | | | | This is from a Coverity defect report. src/mesa/drivers/dri/i965/brw_vec4_emit.cpp 268 static void 269 check_gen6_math_src_arg(struct brw_reg src) 270 { 271 /* Source swizzles are ignored. */ 272 assert(!src.abs); 273 assert(!src.negate); -> 274 assert(src.dw1.bits.swizzle = BRW_SWIZZLE_XYZW); 275 } Reported-by: Vinson Lee <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40214 Signed-off-by: Chris Wilson <[email protected]>
* intel: include version.h to get _mesa_override_glsl_version() prototypeBrian Paul2011-09-291-0/+1
|
* mesa: Remove ARB_texture_mirrored_repeat extension enable flagIan Romanick2011-09-298-8/+0
| | | | | | | | | | | | | All drivers remaining in Mesa support this extension. This extension is either required or optional features in desktop OpenGL, OpenGL ES 1.x, and OpenGL ES 2.x. This extension was previously not supported on mach64, mga, and savage (Savage3D and other pre-Savage4). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Remove EXT_blend_subtract extension enable flagIan Romanick2011-09-298-8/+0
| | | | | | | | | | | | | All drivers remaining in Mesa support this extension. This extension is either required or optional features in desktop OpenGL, OpenGL ES 1.x, and OpenGL ES 2.x. This extension was previously not supported on i810, mach64, mga, savage, sis, and tdfx (Voodoo Banshee and Voodoo3). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Remove EXT_stencil_wrap extension enable flagIan Romanick2011-09-298-8/+0
| | | | | | | | | | | | All drivers remaining in Mesa support this extension. This extension is either required or optional features in desktop OpenGL, OpenGL ES 1.x, and OpenGL ES 2.x. This extension was previously not supported on mach64. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Remove EXT_texture_lod_bias extension enable flagIan Romanick2011-09-296-6/+0
| | | | | | | | | | | | All drivers remaining in Mesa support this extension. This extension is either required or optional features in desktop OpenGL, OpenGL ES 1.x, and OpenGL ES 2.x. This extension was previously not supported on mach64, mga, or r128. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Remove EXT_texture_env_combine extension enable flagIan Romanick2011-09-296-6/+0
| | | | | | | | | | | | | | | | | | | | | All drivers remaining in Mesa support this extension. This extension is either required or optional features in desktop OpenGL, OpenGL ES 1.x, and OpenGL ES 2.x. The existing support is already partially broken in Mesa (e.g., querying GL_TEXTURE_ENV_MODE in OpenGL ES 2.x). This patch does not change the situation in any way. It looks like the only hardware supported by Mesa that cannot do ARB_texture_env_combine is pre-NV10 NVIDA chips. It appears that these chips cannot do the GL_SUBTRACT mode. Based on looking at older copies of nvOpenGLspecs.pdf found on the net, NVIDIA never supported ARB_texture_env_combine on those chips either. This extension was previously not supported on mach64, mga (G200), r128, savage, sis, and tdfx (Voodoo Banshee and Voodoo3). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Remove EXT_texture_env_add extension enable flagIan Romanick2011-09-296-6/+0
| | | | | | | | | | | | | | | | All drivers remaining in Mesa support this extension. This extension is either required or optional features in desktop OpenGL, OpenGL ES 1.x, and OpenGL ES 2.x. The existing support is already partially broken in Mesa (e.g., querying GL_TEXTURE_ENV_MODE in OpenGL ES 2.x). This patch does not change the situation in any way. This extension was previously not supported on mach64, mga (G200), savage (Savage3D and other pre-Savage4), sis, and tdfx (Voodoo Banshee). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Remove ARB_multitexture extension enable flagIan Romanick2011-09-298-8/+0
| | | | | | | | | | | | | | | All drivers remaining in Mesa support this extension. This extension is either required or optional features in desktop OpenGL, OpenGL ES 1.x, and OpenGL ES 2.x. The existing support is already partially broken in Mesa (e.g., querying GL_CLIENT_ACTIVE_TEXTURE in OpenGL ES 2.x). This patch does not change the situation in any way. This extension was previously not supported on i810, mga (G200), or tdfx (Voodoo Banshee). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: Add support for bit-shift operations.Eric Anholt2011-09-281-1/+7
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Add support for bit-shift operations.Eric Anholt2011-09-281-1/+7
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: don't intepolate clip distances on pre-GEN6.Paul Berry2011-09-281-2/+8
| | | | | | | | | | | | | On pre-GEN6 chips, the VUE slots set aside for clip distance aren't actually used, so there is no reason for the clipper to waste time interpolating them. When commit 62bad54727690bff5ed42a74272e7822fd36cdb6 changed the enum value used to represent these VUE slots, that caused the clipper to start interpolating them as an accidental side effect. This patch reverts to the old clipper behavior. Reviewed-by: Kenneth Graunke <[email protected]>
* i965 new VS: Fix bugs in pre-GEN6 psiz/flags computationPaul Berry2011-09-281-5/+5
| | | | | | | | | | | | | | | | | | This patch corrects two errors in the computation of the psiz/flags VUE slot on pre-GEN5 when using the new VS backend: - The clip flags (which should be stored in the w component of the first VUE slot) were being accidentally duplicated in all other components of that VUE slot, causing partially clipped triangles to sometimes disappear completely. - The OR instruction wasn't being stored in "inst", causing the BRW_PREDICATE_NORMAL flag to be applied to the wrong instruction. This patch fixes regressions in clipping behavior when using shaders on GEN4-5. Reviewed-by: Kenneth Graunke <[email protected]>
* i965 new VS: Fix src_reg(uint32_t) constructor.Paul Berry2011-09-281-1/+1
| | | | | | | | | This constructor was storing its argument in the wrong field of the "imm" enum, resulting in it being converted to a float when it should have remained an unsigned integer. This was preventing clipping from working properly on pre-GEN6. Reviewed-by: Kenneth Graunke <[email protected]>
* i965 new VS: don't share clip plane constants in pre-GEN6Paul Berry2011-09-286-43/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | In pre-GEN6, when using clip planes, both the vertex shader and the clipper need access to the client-supplied clip planes, since the vertex shader needs them to set the clip flags, and the clipper needs them to determine where to insert new vertices. With the old VS backend, we used a clever optimization to avoid placing duplicate copies of these planes in the CURBE: we used the same block of memory for both the clipper and vertex shader constants, with the clip planes at the front of it, and then we instructed the clipper to read just the initial part of this block containing the clip planes. This optimization was tricky, of dubious value, and not completely working in the new VS backend, so I've removed it. Now, when using the new VS backend, separate parts of the CURBE are used for the clipper and the vertex shader. Note that this doesn't affect the number of push constants available to the vertex shader, it simply causes the CURBE to occupy a few more bytes of URB memory. The old VS backend is unaffected. GEN6+, which does clipping entirely in hardware, is also unaffected. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Fix a hardcoded user clip plane count.Paul Berry2011-09-281-1/+1
| | | | | | | | | Now that i965 supports 8 clip planes instead of 6, the size of the brw_vs_compile::userplane array needs to be increased to 8. Changed the array size to MAX_CLIP_PLANES so that if the number changes again in the future, this array size won't be missed. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: allow for nonconsecutive elements of gl_ClipDistance to be enabled.Paul Berry2011-09-283-4/+38
| | | | | | | | | | | | | | | | | | | | | | When using user-defined clipping planes, the i965 driver compacts the array of clipping planes so that disabled clipping planes do not appear in it--this saves precious push constant space and makes it easier to generate the pre-GEN6 clip program. As a result, when enabling clipping planes in GEN6+ hardware, we always enable clipping planes 0 through n-1 (where n is the number of clipping planes enabled), regardless of which clipping planes the user actually requested. However, we can't do this when using gl_ClipDistance, because it would be prohibitively complex to compact the gl_ClipDistance array inside the user-supplied vertex shader. So, when enabling clipping planes in GEN6+ hardware, if gl_ClipDistance is in use, we need to pass the user-supplied enable flags directly through to the hardware rather than just enabling the first n planes. Fixes Piglit test vs-clip-distance-enables. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Use 4 bits to store nr_userclip in brw_clip.h.Paul Berry2011-09-281-2/+1
| | | | | | | | | | | | | | | Since the i965 driver supports 8 clipping planes now, we need 4 bits to store the number of user clipping planes, not 3. In theory this isn't strictly necessary, since brw_clip.h is only used on pre-GEN6, and pre-GEN6 only advertises support for 6 clipping planes, but it seems wise to err on the safe side. In the process I removed the pad0 element of struct brw_clip_prog_key--it doesn't seem necessary because the compiler automatically inserts padding if needed. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Remove unused function get_glsl_version()Chad Versace2011-09-281-16/+0
| | | | | | | | It was replaced by _mesa_override_glsl_version(). Reviewed-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa: Allow overriding GLSL version with environment variableChad Versace2011-09-282-1/+3
| | | | | | | | | | | | | | Override the context's GLSL version if the environment variable MESA_GLSL_VERSION_OVERRIDE is set. Valid values for MESA_GLSL_VERSION_OVERRIDE are integers, such as "130". MESA_GLSL_VERSION_OVERRIDE has the same behavior as INTEL_GLSL_VERSION, except that it applies to all drivers, not just Intel's. Since the former supercedes the latter, this patch disables the latter. Reviewed-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965: Allow SIMD16 color writes on Ivybridge.Kenneth Graunke2011-09-281-1/+1
| | | | | | | Again, the check was needlessly specific: this works fine on Gen7. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Allow SIMD16 with control flow on Ivybridge.Kenneth Graunke2011-09-281-1/+1
| | | | | | | | The check was designed to forbid it on old generations (Gen5/Ironlake), not on new ones. It just works on Gen7/Ivybridge. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Fix compiler warnings from the depth stall flush commit.Eric Anholt2011-09-271-0/+1
|
* radeon: Drop mapping we were doing around glGetTexImage().Eric Anholt2011-09-277-86/+0
| | | | It's handled by MapTextureImage() now.
* nouveau: Drop mapping we were doing around glGetTexImage().Eric Anholt2011-09-271-14/+0
| | | | It's handled by MapTextureImage() now.
* intel: Drop our custom glGetTexImage() code.Eric Anholt2011-09-272-63/+7
| | | | | | | | | The mesa core code uses MapTextureImage() like we need now. v2: Drop mapping around _mesa_generate_mipmap for compressed, since the whole path ends up going through MapTextureImage(), and the meta decompression code ended up causing us to lose track of the region that was originally mapped and assertion fail.
* mesa: Convert GetCompressedTexImage to using MapTextureImage().Brian Paul2011-09-274-83/+15
| | | | | | | This changes drivers to not map the texture on their own before calling _mesa_get_compressed_teximage(). Tested-by: Brian Paul <[email protected]>
* i965/vs: Fix access beyond array bounds for non-GRF operands.Eric Anholt2011-09-261-3/+3
| | | | | Caught by valgrind. I never saw a segfault from it (probably because it's hard to have much more of any other file than GRF).
* intel: Rename region->buffer to region->bo, and remove accessor function.Eric Anholt2011-09-2619-96/+73
| | | | | | | We call all the other drm_intel_bo pointers in intel/*.h "bo", so this one was rather out of place. Acked-by: Kenneth Graunke <[email protected]>
* intel: Drop stale comment about CopyTexSubImage.Eric Anholt2011-09-261-4/+0
| | | | | | | We get called for TexImage higher up, and in a relatively normal way (pixels == NULL is common for FBO setup). Acked-by: Kenneth Graunke <[email protected]>
* intel: Rely on AllocTextureImageBuffer for our teximage fallbacks.Eric Anholt2011-09-261-19/+5
| | | | | | | It will do a more reliable job at getting the image size for _mesa_texstore right than us. Acked-by: Kenneth Graunke <[email protected]>
* intel: Rely on mesa core for compressed texture image uploading.Eric Anholt2011-09-261-58/+20
| | | | | | | | | There's nothing in our normal texture path we need for this. We don't PBO upload blit it. We don't need to worry about flushing because MapTextureImage handles it. hiz scattergather doesn't apply, but MTI handles it too. Acked-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-20 22:27:26 +0000