summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* mesa: add glformats integer type/format detection routinesJordan Justen2012-07-2113-94/+295
| | | | | | | | | | | | _mesa_is_integer_format is moved to formats.c and renamed as _mesa_is_enum_format_integer. _mesa_is_format_unsigned, _mesa_is_type_integer, _mesa_is_type_unsigned, and _mesa_is_enum_format_or_type_integer are added. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* Remove unused _mesa_memset16Matt Turner2012-07-212-16/+0
| | | | | | | Unused since commit fd104a845. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* Remove _mesa_inv_sqrtf in favor of 1/SQRTFMatt Turner2012-07-214-117/+4
| | | | | | | | Except for a couple of explicit uses, _mesa_inv_sqrtf was disabled since its addition in 2003 (see f9b1e524). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* Remove _mesa_sqrt* in favor of plain sqrtMatt Turner2012-07-213-117/+1
| | | | | | | | | | Temporarily disabled since 2003 (see 386578c5b). This saves us from calling sqrt() 128 times to generate the sqrttab in one_time_init(). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* Use INV_SQRT instead of 1/SQRTFMatt Turner2012-07-212-3/+3
| | | | | Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i830: Fix stack corruptionChad Versace2012-07-201-1/+1
| | | | | | | | | | | | | | | Found by compiler warning: i830_texstate.c:131:28: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess] memset(state, 0, sizeof(state)); ~~~~~ ^~~~~ On 64-bit systems, memset here would write an extra 4 bytes. Note: This is a candidate for the stable branches. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa: disable MSVC global optimization in pack.cJosé Fonseca2012-07-201-0/+13
| | | | | | | | To reduce excessive compilation time in release mode. NOTE: This is a candidate for the 8.0 branch. Tested-by: Brian Paul <[email protected]>
* mesa: whitespace fixes in pbo.cBrian Paul2012-07-201-14/+14
|
* mesa: update texstore.c commentBrian Paul2012-07-201-3/+2
|
* i965/gen7: Increase the WM threads to hardware limits.Eric Anholt2012-07-201-1/+1
| | | | | | | | | | | | This thread count is only supposed to be enabled when "WIZ Hashing Disable in GT_MODE register enabled." I've always been confused whether that means the bit in the register should be 1 or 0. For my IVB GT2's register 0x7008 value of 0x0, this appears to work fine. Improves l4d2 performance at 640x480 by 0.88 +/- 0.11% (n=88). Improves performance with rasterization at 1280x1024 by 1.45% +/- 0.36% (n=6). Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Implement the UBO-specific pnames of glGetActiveUniformsiv.Eric Anholt2012-07-201-2/+13
| | | | Reviewed-by: Ian Romanick <[email protected]>
* mesa: Add implementation of glGetUniformBlockIndex().Eric Anholt2012-07-201-0/+27
| | | | | | | | | Now that we finally have a list of uniform blocks in the linked shader program, we can tell what their indices are. Fixes piglit GL_ARB_uniform_buffer_object/getuniformblockindex. Reviewed-by: Ian Romanick <[email protected]>
* mesa: Add support for glGetActiveUniformsiv on non-UBO pnames.Eric Anholt2012-07-203-0/+70
| | | | | | | We'll need to propagate the UBO fields to the uniform storage records before we can handle the other pnames. Reviewed-by: Ian Romanick <[email protected]>
* mesa: Add support for glGetUniformIndices().Eric Anholt2012-07-201-0/+35
| | | | | | | | | This is a single entrypoint that maps from a series of names to the indices of those names within the active uniforms list. Each index is like glGetUniformLocation()'s return value, except that it doesn't encode an array offset. Reviewed-by: Ian Romanick <[email protected]>
* mesa: Move the _mesa_uniform_merge_location_offset to glGetUniformLocation().Eric Anholt2012-07-204-16/+28
| | | | | | | With the upcoming GL_ARB_uniform_buffer_object changes, the only other caller that will want the cooked value is state_tracker. Reviewed-by: Ian Romanick <[email protected]>
* glsl: Merge the lists of uniform blocks into the linked shader program.Eric Anholt2012-07-202-0/+40
| | | | | | This attempts error-checking, but the layout isn't done yet. Reviewed-by: Ian Romanick <[email protected]>
* glsl: Translate the AST for uniform blocks into some IR structures.Eric Anholt2012-07-201-0/+18
| | | | | | | | | | We're going to need this structure to cross-validate the uniform blocks between shader stages, since unused ir_variables might get dropped. It's also the place we store the RowMajor qualifier, which is not part of the GLSL type (since that would cause a bunch of type equality checks to fail). Reviewed-by: Ian Romanick <[email protected]>
* i965/blorp: Use IMS layout when texturing from depth/stencil surfaces.Paul Berry2012-07-201-23/+43
| | | | | | | | | | | | | | Previously, on Gen7, when texturing from a depth or stencil surface, the blorp engine would configure the 3D pipeline as though the input surface was non-multisampled, and perform the necessary coordinate transformations in the fragment shader to account for the IMS layout. This meant outputting a lot of extra fragment shader code, and it raised some uncertainty about how to deal with very large surfaces. This patch modifies blorp to configure the 3D pipeline properly for IMS layout when reading from depth and stencil surfaces. Reviewed-by: Anuj Phogat <[email protected]>
* i965/blorp: Loosen assertions in compute_msaa_layout_for_pipeline.Paul Berry2012-07-201-7/+2
| | | | | | | | Previously, on Gen7, compute_msaa_layout_for_pipeline() would verify that IMS layout is not used. However, now that we configure SURFACE_STATE correctly for IMS surfaces, IMS layout is available. Reviewed-by: Anuj Phogat <[email protected]>
* i965/blorp: Configure SURFACE_STATE correctly for IMS surfaces.Paul Berry2012-07-203-6/+14
| | | | | | | | | | | | | This patch modifies gen7_set_surface_num_multisamples() to set up the SURFACE_STATE appropriately for texturing from IMS format MSAA surfaces (which are only used on Gen7 for depth and stencil buffers). Since the function now sets more than just the number of multisamples, it's been renamed to gen7_set_surface_msaa(). This will make it possible to remove some kludginess from the blorp engine. Reviewed-by: Anuj Phogat <[email protected]>
* i965/blorp: Optimize manual_blend() for compressed multisampled surfaces.Paul Berry2012-07-201-0/+23
| | | | | | | | | | When downsampling a compressed multisampled surface, we can take a shortcut to downsample any pixels that were completely covered by a single primitive. In this case, the first color value we fetch is the correct final color for the downsampled pixel, so we can skip the rest of the blending operation. Reviewed-by: Anuj Phogat <[email protected]>
* i965/blorp: Fix integer downsampling on Gen7.Paul Berry2012-07-202-11/+55
| | | | | | | | | | | | | | | | When downsampling an integer-format buffer on Gen7, we need to use the "avg" instruction rather than the "add" instruction, to ensure that we don't overflow the range of 32-bit integers. Also, we need to use the proper register type (BRW_REGISTER_TYPE_D or BRW_REGISTER_TYPE_UD) for intermediate color data and for writing to the render target. Note: this patch causes blorp to use the proper register type for all operations (downsampling, upsampling, and ordinary blits). Strictly speaking, this is only necessary for downsampling, because the other operations exclusively use MOV instructions on the color data. But it's simpler to use the proper register type in all cases. Reviewed-by: Anuj Phogat <[email protected]>
* i965/blorp: Modify manual_blend() to avoid unnecessary loss of precision.Paul Berry2012-07-201-27/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When downsampling from an MSAA image to a single-sampled image, it is inevitable that some loss of numerical precision will occur, since we have to use 32-bit floating point registers to hold the intermediate results while blending. However, it seems reasonable to expect that when all samples corresponding to a given pixel have the exact same color value, there will be no loss of precision. Previously, we averaged samples as follows: blend = (((sample[0] + sample[1]) + sample[2]) + sample[3]) / 4 This had the potential to lose numerical precision when all samples have the same color value, since ((sample[0] + sample[1]) + sample[2]) may not be precisely representable as a 32-bit float, even if the individual samples are. This patch changes the formula to: blend = ((sample[0] + sample[1]) + (sample[2] + sample[3])) / 4 This avoids any loss of precision in the event that all samples are the same, by ensuring that each addition operation adds two equal values. As a side benefit, this puts the formula in the form we will need in order to implement correct blending of integer formats. Reviewed-by: Anuj Phogat <[email protected]>
* i965: Add support for AVG instruction.Paul Berry2012-07-202-0/+23
| | | | | | | | | | | | | From the Ivy Bridge PRM, Vol4 Part3 p152: "The avg instruction performs component-wise integer average of src0 and src1 and stores the results in dst. An integer average uses integer upward rounding. It is equivalent to increment one to the addition of src0 and src1 and then apply an arithmetic right shift to this intermediate value." Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965: Replace fs_visitor::kill_emitted with gl_fragment_program::UsesKill.Paul Berry2012-07-202-4/+1
| | | | | | | The kill_emitted variable was duplicating the functionality of gl_fragment_program::UsesKill. There's no need for both. Reviewed-by: Eric Anholt <[email protected]>
* mesa: Set gl_fragment_program::UsesKill in do_set_program_inouts.Paul Berry2012-07-203-33/+0
| | | | | | | | | | | | | | | | | | | | | Previously, the code for setting this flag for GLSL programs was duplicated in three places: brw_link_shader(), glsl_to_tgsi_visitor, and ir_to_mesa_visitor. In addition to the unnecessary duplication, there was a performance problem on i965: brw_link_shader() set the flag before doing its final round of optimizations, which meant that if the optimizations managed to eliminate all the discard operations, the flag would still be set, resulting (at least in theory) in slower performance. This patch consolidates all of the code that sets UsesKill for GLSL programs into do_set_program_inouts(), which already is doing a similar job for UsesDFdy, and which occurs after i965's final round of optimizations. Non-GLSL programs (ARB programs and the state tracker's glBitmap program) are unaffected. Reviewed-by: Eric Anholt <[email protected]>
* i965: Avoid unnecessary recompiles for shaders that don't use dFdy().Paul Berry2012-07-194-14/+10
| | | | | | | | | | | | The i965 back-end needs to compile dFdy() differently for FBOs and window system framebuffers, because Y coordinates are flipped between the two (see commit 82d2596: i965: Compute dFdy() correctly for FBOs). This patch avoids unnecessarily recompiling shaders that don't use dFdy(), by only setting render_to_fbo in the wm program key if the shader actually uses dFdy(). Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Set UsesDFdy appropriately for assembly programs.Paul Berry2012-07-193-0/+4
| | | | | | Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Add UsesDFdy to struct gl_fragment_program.Paul Berry2012-07-192-0/+3
| | | | | | | | | | | | The i965 back-end needs to compile dFdy() differently for FBOs and window system framebuffers, because Y coordinates are flipped between the two (see commit 82d2596: i965: Compute dFdy() correctly for FBOs). This boolean will allow it to avoid unnecessarily recompiling shaders that don't use dFdy(). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* drirc: Add disable_blend_func_extended workaround for Unigine OilRush.Kenneth Graunke2012-07-191-0/+6
| | | | | | | | | | The previous commit implemented the workaround, cited a bug report about OilRush, but actually only enabled the workaround for the demos. Turn it on for OilRush too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50291 Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Add a driconf option to disable GL_ARB_blend_func_extended.Kenneth Graunke2012-07-194-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unigine Heaven (at least) has a bug where it incorrectly uses the GL_ARB_blend_func_extended extension. Dual source blending allows two color outputs per render target; individual shader outputs can be assigned to be either the first or second blending input by setting the 'index' via one of two methods: - An API call: glBindFragDataLocationIndexed() - The GLSL 'layout' qualifier provided by GL_ARB_explicit_attrib_location Both of these only work on user defined fragment shader outputs; it's an error to use either on built-in outputs like gl_FragData. Unigine uses gl_FragData and gl_FragColor exclusively, and doesn't even attempt to use either method to set index == 1. However, it does set the blending function to SRC1 enums, which requires a fragment shader output with index == 1 or else rendering is undefined. In other words, enabling ARB_blend_func_extended causes Unigine to render incorrectly, resulting in an apparent regression, even though our driver code (as far as I can tell) is perfectly fine. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50291 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: remove stale commentBrian Paul2012-07-181-1/+0
|
* mesa: use gl_program cast wrappersBrian Paul2012-07-186-49/+37
| | | | | | | In a few cases, remove unneeded casts. And fix a few other const-correctness issues. Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: add some gl_program cast wrappersBrian Paul2012-07-181-0/+42
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Make register spill/unspill only do the regs for that instruction.Eric Anholt2012-07-181-33/+33
| | | | | | | | | | | | | | | | | | Previously, if we were spilling the result of a texture call, we would store all 4 regs, then for each use of one of those regs as the source of an instruction, we would unspill all 4 regs even though only one was needed. In both lightsmark and l4d2 with my current graphics config, the shaders that produce spilling do so on split GRFs, so this doesn't help them out. However, in a capture of the l4d2 shaders with a different snapshot and playing the game instead of using a demo, it reduced one shader from 2817 instructions to 2179, due to choosing a now-cheaper texture result to spill instead of piles of texcoords. v2: Fix comment noted by Ken, and fix the if condition associated with it for the current state of what constitutes a partial write of the destination. Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* i965/fs.h: Refactor tests for instructions modifying a register.Eric Anholt2012-07-184-34/+16
| | | | | | | | | | There's one instance of a potential behavior change: propagate_constants may now propagate into a part of a vgrf after a different part of it was overwritten by a send that returns multiple registers. I don't think we ever generate IR that meets that condition, but it's something to note if we bisect behavior change to this. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Replace usage is_tex() with regs_written() checks.Eric Anholt2012-07-181-9/+9
| | | | | | | | | | In these places, we care about any sort of send that hits more than one reg, not just textures. We don't yet have anything else returning more than one reg, so there's no change. v2: Use mlen instead of is_tex() for the is-it-a-send check. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Rename virtual_grf_next to virtual_grf_count.Eric Anholt2012-07-186-22/+21
| | | | | | | "count" is a more useful name, since most of the time we're using it for looping over the variables. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Move a block out of a loop in live variables setup.Eric Anholt2012-07-181-4/+5
| | | | | | This was accidentally copy-and-pasted inside. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/msaa: Disable alpha-to-{coverage, one} when drawbuffer zero is in ↵Anuj Phogat2012-07-181-7/+21
| | | | | | | | | | | | | | | | | | | integer format OpenGL specification 3.3 (page 196), section 4.1.3 says: If drawbuffer zero is not NONE and the buffer it references has an integer format, the SAMPLE_ALPHA_TO_COVERAGE and SAMPLE_ALPHA_TO_ONE operations are skipped." This should work properly even if there are other draw buffers that are not in integer format. This patch makes following piglit tests pass on mesa: int-draw-buffers-alpha-to-coverage int-draw-buffers-alpha-to-one Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Anuj Phogat <[email protected]>
* msaa: Generate proper error for operations prohibited on MSAA buffers.Paul Berry2012-07-172-3/+3
| | | | | | | | | | | | | | | | | | | | | From the GL 3.0 spec, section 4.3.3, in the documentation for CopyPixels(): "An INVALID_OPERATION error will be generated if the object bound to READ_FRAMEBUFFER_BINDING is framebuffer complete and the value of SAMPLE_BUFFERS is greater than zero." The same applies to CopyTexImage...() and CopyTexSubImage...() functions, since they are defined in terms of CopyPixels(). Previously we were generating an INVALID_FRAMEBUFFER_OPERATION error in these cases. Fixes piglit tests "EXT_framebuffer_multisample/negative-{copypixels,copyteximage}". Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add a comment explaining why we early return on matching BO names.Eric Anholt2012-07-171-0/+4
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Drop other checks for old loader version.Eric Anholt2012-07-171-38/+26
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Replace the non-getBuffersWithFormat compat path with an error message.Eric Anholt2012-07-172-21/+8
| | | | | | | | | | It's been broken (using NULL getBuffersWithFormat() instead of getBuffers()) due to a copy and paste error for a year now. GetBuffersWithFormat has been around since 2009, so I don't feel any guilt in not supporting it. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Remove dead intel_framebuffer_has_hiz().Eric Anholt2012-07-172-13/+0
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Convert to using private depth/stencil buffers (v2)Eric Anholt2012-07-173-652/+39
| | | | | | | | | | | | | | | | | This means that GLX buffer sharing of these no longer works. On the other hand, just *look* at this code reduction. v2: - [chad] Fix intelCreateBuffer for gen < 6. When the branch for !screen->hw_has_separate_stencil was taken, intel_create_private_renderbuffer was incorrectly not used. - [chad] Remove all code in intel_process_dri2_buffer for processing depth, stencil, and hiz buffers. That code is now dead. CC: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add a function for creating a private window system buffer.Eric Anholt2012-07-172-2/+20
| | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: include inttypes.h to get uint8_t typeBrian Paul2012-07-161-0/+1
| | | | To fix MSVC build.
* Fix building mesa with assembly enabled since a112ca5dJon TURNEY2012-07-161-2/+3
| | | | | | | | | | | | a112ca5d rather crassly smashed all the compiler flags together into AM_CFLAGS. Separate them out the way they were before, putting pre-processor flags into AM_CPPFLAGS, so assembly source gets preprocessed with the correct pre-processor flags as well. Also, remove unneeded CFLAGS from AM_CFLAGS, and CXXFLAGS from AM_CXXFLAGS Signed-off-by: Jon TURNEY <[email protected]> Tested-by: Brian Paul <[email protected]>
* intel: Fix build broken by ETC1 patchChad Versace2012-07-161-0/+12
| | | | | | | I suck at resolving merge conflicts and broke the build in a5a34b1. This patch adds the missing field intel_mipmap_tree::wraps_etc1. Signed-off-by: Chad Versace <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 08:23:04 +0000