summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* 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]>
* mesa: use !! to simplify some _mesa_set_enable() calls in attrib.cBrian Paul2011-10-011-43/+25
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: use loop in pop_texture_group() to restore 4 combiner termsBrian Paul2011-10-011-24/+13
| | | | | | | There's four combiner terms (not 3) with GL_NV_texture_env_combine4. Use a loop to make the code a little more compact. Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Refactor hash_table_{find,remove} to share some codeIan Romanick2011-09-301-16/+16
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Document an odd side-effect of hash_table_insertIan Romanick2011-09-301-0/+5
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Remove unused field gl_program::VaryingIan Romanick2011-09-304-12/+0
| | | | | | | Lots of things set and copy this field around, but nothing uses it. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Use Add linker_error instead of fail_linkIan Romanick2011-09-301-14/+3
| | | | | | | See also 8aadd89. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* r600g: fix a compiler warningMarek Olšák2011-09-301-0/+1
|
* gallium/docs: update the documentation of capabilitiesMarek Olšák2011-09-301-73/+84
| | | | Still like 13 caps are undocumented.
* r600g: move all files from winsys/r600 into drivers/r600Marek Olšák2011-09-3021-93/+13
| | | | | | Be sure to reconfigure after this commit. Reviewed-by: Alex Deucher <[email protected]>
* winsys/radeon: move GEM domains out of the drivers into winsysMarek Olšák2011-09-3015-111/+82
| | | | | | | | | | | | | | | The drivers don't need to care about the domains. All they need to set are the bind and usage flags. This simplifies the winsys too. This also fixes on r600g: - fbo-depth-GL_DEPTH_COMPONENT32F-copypixels - fbo-depth-GL_DEPTH_COMPONENT16-copypixels - fbo-depth-GL_DEPTH_COMPONENT24-copypixels - fbo-depth-GL_DEPTH_COMPONENT32-copypixels - fbo-depth-GL_DEPTH24_STENCIL8-copypixels I can't explain it. Reviewed-by: Alex Deucher <[email protected]>
* winsys/radeon: remove a redundant parameter 'size' from buffer_from_handleMarek Olšák2011-09-304-10/+5
| | | | | | It's part of pb_buffer already. Reviewed-by: Alex Deucher <[email protected]>
* r600g: remove struct radeon (or what's left of it)Marek Olšák2011-09-308-96/+18
| | | | Reviewed-by: Alex Deucher <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 12:11:31 +0000