aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri
Commit message (Collapse)AuthorAgeFilesLines
* mesa: get rid of imageOffsets arrays in texstore codeBrian Paul2011-10-053-11/+18
| | | | | | | | | | | These were used to find the start of a 3D image slice (or 2D array texture slice) given a base address. Instead, use a simple array of address of image slices instead. This is a step toward getting rid of the gl_texture_image::ImageOffsets field. Reviewed-by: Eric Anholt <[email protected]>
* i965 Gen6: Implement gl_ClipVertex.Paul Berry2011-10-055-8/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements proper support for gl_ClipVertex by causing the new VS backend to populate the clip distance VUE slots using VERT_RESULT_CLIP_VERTEX when appropriate, and by using the untransformed clip planes in ctx->Transform.EyeUserPlane rather than the transformed clip planes in ctx->Transform._ClipUserPlane when a GLSL-based vertex shader is in use. When not using a GLSL-based vertex shader, we use ctx->Transform._ClipUserPlane (which is what we used prior to this patch). This ensures that clipping is still performed correctly for fixed function and ARB vertex programs. A new function, brw_select_clip_planes() is used to determine whether to use _ClipUserPlane or EyeUserPlane, so that the logic for making this decision is shared between the new and old vertex shaders. Fixes the following Piglit tests on i965 Gen6: - vs-clip-vertex-const-accept - vs-clip-vertex-const-reject - vs-clip-vertex-different-from-position - vs-clip-vertex-equal-to-position - vs-clip-vertex-homogeneity - vs-clip-based-on-position - vs-clip-based-on-position-homogeneity - clip-plane-transformation clipvert_pos - clip-plane-transformation pos_clipvert - clip-plane-transformation pos Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* r200/r300/r600: remove dangling radeon_tex_getimage.c symlinks.Paul Berry2011-10-043-3/+0
| | | | | | | | | | | | Commit d1fda903 (radeon: Drop mapping we were doing around glGetTexImage()) removed the common Radeon source file radeon_tex_getimage.c, and pulled it out of the r200, r300, r600, and radeon makefiles. But it left behind the symlinks that were being used to share that file among the four directories. This patch removes the dangling symlinks. Reviewed-by: Brian Paul <[email protected]>
* mesa: Remove ARB_draw_buffers extension enable flagIan Romanick2011-10-042-2/+0
| | | | | | | | | | | | | All drivers in Mesa have supported this extension for eons. This extension is an optional features in desktop OpenGL (via GL_ARB_draw_buffers) and OpenGL ES 2.x (via GL_NV_draw_buffers). The extension is not usable in OpenGL ES 1.x. There is no glDrawBuffers* entry point in OpenGL ES 1.x contexts, and glGet*v generate errors when MAX_DRAW_BUFFERS or DRAW_BUFFERi is queried. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* configure: replace pkg-config calls with $(PKG_CONFIG) in the makefiles.Stéphane Marchesin2011-10-041-1/+1
| | | | | | | Us poor souls who cross compile mesa want to be able to specify which pkg-config to pick, or at least just change one place. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* nouveau: remove unused code, unused varBrian Paul2011-10-031-29/+0
|
* i915: don't include texstore.hBrian Paul2011-10-031-1/+0
|
* i965: remove unneeded includes of texstore.hBrian Paul2011-10-033-3/+0
|
* i965: Add support for GL_EXT_texture_array and GL_MESA_texture_array.Eric Anholt2011-10-039-5/+43
|
* intel: Add a safety check for mapping 1D texture arrays.Eric Anholt2011-10-031-0/+4
| | | | So easy to screw up with the crazy way GL manages them.
* intel: Add debug output to intel_map_texture_image.Eric Anholt2011-10-031-1/+7
|
* intel: Add a helper function for getting miptree size from a texture image.Eric Anholt2011-10-038-35/+80
| | | | | With 1D array textures, we no longer agree between the GL information about width/height/depth of a texture and how we lay out a miptree.
* i965: Refactor out the cube map setup for general texture array setup.Eric Anholt2011-10-031-29/+37
| | | | This is just moving the code out with s/6/slices/.
* intel: Consolidate texture validation copy code, and reuse it correctly.Eric Anholt2011-10-036-193/+106
| | | | | | | | The path for ->Data was failing to be called for the FBO draw offset fallback, and also had mismatched compressed texture support code. This drops the intel_prepare_render() in the blit path. We aren't copying to/from a GL_FRONT buffer, so it doesn't matter.
* 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 15:04:52 +0000