summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* configure: replace pkg-config calls with $(PKG_CONFIG) in the makefiles.Stéphane Marchesin2011-10-0434-57/+58
| | | | | | | 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]>
* st/glx: Set the drawable attribute on xmesa_buffer creation.Stephen White2011-10-041-1/+1
| | | | Otherwise we'll be unable to use our pbuffers.
* r300g: fix rendering with a non-zero index bias in draw_elements_immediateMarek Olšák2011-10-041-1/+3
| | | | NOTE: This is a candidate for the stable branches.
* docs: Update references to README filesGuillem Jover2011-10-041-10/+2
| | | | | Signed-off-by: Guillem Jover <[email protected]> Signed-off-by: Brian Paul <[email protected]>
* Remove remnants of legacy glide supportGuillem Jover2011-10-045-47/+0
| | | | | Signed-off-by: Guillem Jover <[email protected]> Signed-off-by: Brian Paul <[email protected]>
* Ignore all shared objectsGuillem Jover2011-10-041-0/+1
| | | | | Signed-off-by: Guillem Jover <[email protected]> Signed-off-by: Brian Paul <[email protected]>
* r600g: fix parsing TGSI declarationsMarek Olšák2011-10-041-2/+2
| | | | It was a lucky coincidence that it worked.
* 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
|
* swrast: fix delayed texel buffer allocation regressionBrian Paul2011-10-031-20/+20
| | | | | | | | Commit 617cdcd4c7b1cffb584c829c35bdf9c9bf04627b delayed the texel buffer allocation until texture_combine() is called. But the texel buffer is needed sooner in _swrast_texture_span() at line 649. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41433
* mesa: fix warning (MSVC error) about void pointer arithmeticBrian Paul2011-10-031-1/+1
|
* 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/.
* mesa: Reuse existing make_2d_mipmap for 2D array generation.Eric Anholt2011-10-031-99/+5
| | | | Reviewed-by: Brian Paul <[email protected]>
* mesa: Make the uncompressed sw mipmap gen path do a Map per 1D array slice.Eric Anholt2011-10-031-44/+17
| | | | | | This also fixes what was probably a bug in 1D arrays with border. Reviewed-by: Brian Paul <[email protected]>
* mesa: When storing texture data for a 1D array, map each slice separately.Eric Anholt2011-10-031-16/+52
| | | | Reviewed-by: Brian Paul <[email protected]>
* swrast: When asked to map a slice of a 1D array, give back that slice.Eric Anholt2011-10-031-0/+7
| | | | | | | | | Until now, we've been treating 1D arrays as a single slice, and each array slice is actually just a row of the 2D texture. While swrast still stores them this way, hardware drivers think that 1D arrays have actual separate slices not stored as contiguous rows. Reviewed-by: Brian Paul <[email protected]>
* 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-036-416/+153
| | | | | | | | | | | 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]>
* ir_to_mesa: Don't assertion fail on integer modulus.Kenneth Graunke2011-10-021-1/+4
| | | | | | | | | | | Drivers implementing GLSL 1.30 want to do integer modulus, and until we can stop generating code via ir_to_mesa, it's easier to make it silently generate rubbish code. Multiply will do. 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]>
* r300/compiler: Fix error in OMOD optimizationTom Stellard2011-10-021-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | Classic compiler mistake. In the example below, the OMOD optimization was combining instructions 4 and 10, but since there was an instruction (#8) in between them that wrote to the same registers as instruction 10, instruction 11 was reading the wrong value. Example of the mistake: Before OMOD: 4: MAD temp[0].y, temp[3]._y__, const[0]._x__, const[0]._y__; ... 8: ADD temp[2].x, temp[1].x___, -temp[4].x___; ... 10: MUL temp[2].x, const[1].y___, temp[0].y___; 11: FRC temp[5].x, temp[2].x___; After OMOD: 4: MAD temp[2].x / 8, temp[3]._y__, const[0]._x__, const[0]._y__; ... 8: ADD temp[2].x, temp[1].x___, -temp[4].x___; ... 11: FRC temp[5].x, temp[2].x___; https://bugs.freedesktop.org/show_bug.cgi?id=41367
* r300/compiler: Rewrite source swizzles when using OMODTom Stellard2011-10-021-1/+6
|
* r300/compiler: Fix rc_normal_rewrite_writemask()Tom Stellard2011-10-021-5/+4
| | | | This function had not been updated to use conversion swizzles.
* r300/compiler: Use consistent src swizzles for transcendent instructionsTom Stellard2011-10-025-6/+33
| | | | | | | | | | | | | | | Source swizzles for transcendent instructions were being stored in the X channel regardless of what channel the instruction was writing. This was causing problems for some helper functions that were expecting source swizzles to occupy channels corresponding to the instruction's writemask. This commit makes transcendent instructions follow the same convention as normal instructions for representing source swizzles. Previous behavior: LG2 temp[0].y, input[0].x___; Current behavior: LG2 temp[0].y, input[0]._x__;
* mesa: Respect GL_RASTERIZER_DISCARD for various meta-type operations.Eric Anholt2011-10-013-5/+25
| | | | | | | | | | | | | | | | From the EXT_transform_feedback spec: Primitives can be optionally discarded before rasterization by calling Enable and Disable with RASTERIZER_DISCARD_EXT. When enabled, primitives are discared right before the rasterization stage, but after the optional transform feedback stage. When disabled, primitives are passed through to the rasterization stage to be processed normally. RASTERIZER_DISCARD_EXT applies to the DrawPixels, CopyPixels, Bitmap, Clear and Accum commands as well. And the GL 3.2 spec says it applies to ClearBuffer* as well. Reviewed-by: Brian Paul <[email protected]>
* mesa: Add missing glGetIntegerv() support for ARB_color_buffer_float tokens.Eric Anholt2011-10-011-0/+6
| | | | | | | Fixes piglit ARB_color_buffer_float/api-get Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* Revert "vbo: Don't discount stride == 0 for testing all varyings in VBOs."Eric Anholt2011-10-011-1/+2
| | | | | | | | | | | | | | | | | This reverts commit d631c19db47181129811080bfa772b210d762d4d. The commit was broken, and ended up returning false all the time because nobody in the world binds every single possible vertex array. On further reflection, we don't want to discount stride == 0: This function is just used for deciding to calculate whether to compute the bonuds on the index, and there's no sense in computing index bounds when stride == 0. For the separate question of "how much data do I upload for this vertex element?", the i965 driver was fixed to upload the data. Fixes a regression of about 2x in 3DMMES, and most importantly, makes Hammerfight playable.
* 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?").
* mesa: Delay s_texcombine.c memory allocation until it's used.Eric Anholt2011-10-012-11/+20
| | | | | | Generally we're using fragment programs in all our drivers, so wasting 4MB for code that's never called is pretty lame. Reduces i965 memory allocation for a short shader program from 21,932,128B to 17,737,816B.
* tnl: Delay results allocation until we actually need them.Eric Anholt2011-10-011-7/+5
| | | | | | Decreases i965 peak memory allocation for a trivial shader program from 23,483,048B to 21,932,128B, since we never actually use tnl for rendering.
* 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]>
* mesa: number of combiner terms to pop depends on GL_NV_texture_env_combine4Brian Paul2011-10-011-1/+2
| | | | | | | | | | If GL_NV_texture_env_combine4 is not supported, setting the fourth combiner term would generate a GL error. Of course, I noticed this right after committing the previous patch to use a loop in the first place. <sigh> Note that GL_EXT_texture_env_combine is always supported so the first three combiner terms are always accepted.
* mesa: s/INLINE/inline/Brian Paul2011-10-0173-274/+274
| | | | | | | INLINE is still seen in some files (some generated files, etc) but this is a good start. Acked-by: Kenneth Graunke <[email protected]>
* r600: include version.h for _mesa_override_glsl_version() prototypeBrian Paul2011-10-011-0/+1
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-16 09:26:43 +0000