aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965
Commit message (Collapse)AuthorAgeFilesLines
* i965: Add support for ir_unop_f2u to i965 backend.Paul Berry2012-06-153-0/+3
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Implement source clipping.Paul Berry2012-06-151-3/+11
| | | | | | | | | | | | | | | | | This patch modifies blorp blits (which are used for MSAA) to properly account for clipping of source coordinates. Previously, if we detected the possibility of source clipping, we would fall back to the blit meta-op, which doesn't support MSAA and is very slow for depth and stencil buffers. Fixes piglit tests "EXT_framebuffer_multisample/clip-and-scissor-blit" on i965/Gen6+. Also substantially speeds up the Humble Bundle V game "Psychonauts" on Gen6+ (without this patch, the game's depth buffer blits use the slow blit meta-op). Reviewed-by: Carl Worth <[email protected]>
* i965: Add forgotten bitcast operations in brw_fs_channel_expressions.Kenneth Graunke2012-06-071-0/+4
| | | | Signed-off-by: Kenneth Graunke <[email protected]>
* i965/blorp: allow all buffer formats provided src and dst match.Paul Berry2012-06-071-25/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, blits using the "blorp" mechanism only worked for 8-bit RGBA color buffers, 24-bit depth buffers, and 8 bit stencil buffers. This was not enough, because the blorp mechanism must be used for blitting whenever MSAA is in use. This patch allows all formats to be used, provided the source and destination formats match. So far I have confirmed that the following formats work properly with MSAA: - GL_RGB - GL_RGBA - GL_ALPHA - GL_ALPHA4 - GL_ALPHA8 - GL_R3_G3_B2 - GL_RGB4 - GL_RGB5 - GL_RGB8 - GL_RGB10 - GL_RGB12 - GL_RGB16 - GL_RGBA2 - GL_RGBA4 - GL_RGB5_A1 - GL_RGBA8 - GL_RGB10_A2 - GL_RGBA12 - GL_RGBA16 Fixes piglit tests "EXT_framebuffer_multisample/formats {2,4}" on Sandy Bridge and Ivy Bridge. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Implement logic for additional buffer formats.Paul Berry2012-06-073-7/+37
| | | | | | | | | | | | | Previously the blorp engine only supported RGBA8 color buffers and 24-bit depth buffers. This patch adds support for any color buffer format that is supported as a render target, and for 16-bit and 32-bit depth buffers. This required threading the brw_context struct through into brw_blorp_surface_info::set() so that it can consult the brw->render_target_format array. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: De-virtualize brw_blorp_{mip,surface}_info::set() function.Paul Berry2012-06-071-4/+4
| | | | | | | | | | Even though brw_blorp_surface_info is derived from brw_blorp_mip_info, this function doesn't need to be virtual, because it is never accessed through a base class pointer. Making the function non-virtual will allow it to take additional parameters in the brw_blorp_surface_info case. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Refactor surface format determination.Paul Berry2012-06-074-10/+10
| | | | | | | | | | | This patch moves the responsibility for deciding on the format of the source and destination surfaces from the gen{6,7}_blorp_emit_surface_state() functions to brw_blorp_surface_info::set(), which is shared between Gen6 and Gen7. This will make it possible to add support for more surface formats without code duplication. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Enable the GL_ARB_shader_bit_encode extension.Kenneth Graunke2012-06-072-0/+24
| | | | Signed-off-by: Kenneth Graunke <[email protected]>
* i965/fs: Fix user-defined FS outputs with less than four components.Kenneth Graunke2012-06-052-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OpenGL allows you to declare user-defined fragment shader outputs with less than four components: out ivec2 color; This makes sense if you're rendering to an RG format render target. Previously, we assumed that all color outputs had four components (like the built-in gl_FragColor/gl_FragData variables). This caused us to call emit_color_write for invalid indices, incrementing the output virtual GRF's reg_offset beyond the size of the register. This caused cascading failures: split_virtual_grfs would allocate new size-1 registers based on the virtual GRF size, but then proceed to rewrite the out-of-bounds accesses assuming that it had allocated enough new (contiguously numbered) registers. This resulted in instructions that accessed size-1 GRFs which register numbers beyond virtual_grf_next (i.e. registers that were never allocated). Finally, this manifested as live variable analysis and instruction scheduling accessing their temporary array with an out of bounds index (as they're all sized based on virtual_grf_next), and the program would segfault. It looks like the hardware's Render Target Write message requires you to send four components, even for RT formats such as RG or RGB. This patch continues to use all four MRFs, but doesn't bother to fill any data for the last few, which should be unused. +2 oglconforms. NOTE: This is a candidate for stable release branches. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Fix texelFetchOffset() on pre-Gen7.Kenneth Graunke2012-06-051-2/+2
| | | | | | | | | | | Commit 4650aea7a536ddce120576fadb91845076e8e37a fixed texelFetchOffset() on Ivybridge, but didn't update the Ironlake/Sandybridge code. +18 piglits on Sandybridge. NOTE: This and 4650aea7a536ddce are both candidates for stable branches. Signed-off-by: Kenneth Graunke <[email protected]>
* i965/fs: Fix texelFetchOffset() on pre-Gen7.Kenneth Graunke2012-06-051-12/+28
| | | | | | | | | | | Commit f41ecade7b458c02d504158b522acb2231585040 fixed texelFetchOffset() on Ivybridge, but didn't update the Ironlake/Sandybridge code. +15 piglits on Sandybridge. NOTE: This and f41ecade7b458 are both candidates for stable branches. Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Implement texture buffer objects on Gen6.Kenneth Graunke2012-06-022-0/+61
| | | | | | | | | | | Commit a07cf3397e332388d3599c83e50ac45511972890 added support for TBOs on Gen7, but missed Gen6. Passes piglit -t texture_buffer and oglconform's buffermapping basic.read.texture tests. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/blorp: Implement destination clipping and scissoringPaul Berry2012-05-291-5/+67
| | | | | This patch implements clipping and scissoring of the destination rect for blits that use the blorp engine (e.g. MSAA blits).
* i965/msaa: Enable 4x MSAA on Gen7.Paul Berry2012-05-251-8/+4
| | | | | | | | | | | | | | | | | | Basic 4x MSAA support now works on Gen7. This patch enables it. As with Gen6, MSAA support is still fairly preliminary. In particular, the following are not yet supported: - 8x oversampling (Gen7 has hardware support for this, but we do not yet expose it). - Fully general blits between MSAA and non-MSAA buffers. - Formats other than RGBA8, DEPTH24, and STENCIL8. - Centrold interpolation. - Coverage parameters (glSampleCoverage, GL_SAMPLE_ALPHA_TO_COVERAGE, GL_SAMPLE_ALPHA_TO_ONE, GL_SAMPLE_COVERAGE, GL_SAMPLE_COVERAGE_VALUE, GL_SAMPLE_COVERAGE_INVERT). Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/msaa: Implement manual blending operation for Gen7.Paul Berry2012-05-251-23/+67
| | | | | | | | | | | | | | | On Gen6, the blending necessary to blit an MSAA surface to a non-MSAA surface could be accomplished with a single texturing operation. On Gen7, the WM program must fetch each sample and blend them together manually. From the Bspec (Shared Functions/Messages/Initiating Message/Message Types/sample): [DevIVB+]:Number of Multisamples on the associated surface must be MULTISAMPLECOUNT_1. This patch implements the manual blend operation. Acked-by: Kenneth Graunke <[email protected]>
* i965/msaa: Modify blorp code to account for Gen7 MSAA layouts.Paul Berry2012-05-253-68/+151
| | | | | | | | | | | | | | | | | | | Since blorp uses color textures and render targets to do all its work (even when blitting stencil and depth data), it always has to configure the Gen7 GPU to use the new "sliced" MSAA layout. However, when blitting stencil or depth data, the actual MSAA layout is interleaved (as in Gen6). Therefore, blorp has to do extra coordinate transformation work to account for the interleaving manually. This patch causes blorp to perform the necessary extra coordinate transformations. It also modifies the blorp SURFACE_STATE setup code for Gen7, so that it does not try to correct the surface width and height to account for MSAA, since "sliced" MSAA layout doesn't affect the surface width or height. Acked-by: Kenneth Graunke <[email protected]>
* i965/msaa: Validate Gen7 surface state constraints.Paul Berry2012-05-253-3/+109
| | | | | | | | | When a Gen7 SURFACE_STATE is configured for MSAA, a number of additional constaints come in to play. This patch adds a function gen7_check_surface_setup() which verifies that all of those constraints are met. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/msaa: Properly handle sliced layout for Gen7.Paul Berry2012-05-256-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | | Starting in Gen7, there are two possible layouts for MSAA surfaces: - Interleaved, in which additional samples are accommodated by scaling up the width and height of the surface. This is the only layout available in Gen6. On Gen7 it is used for depth and stencil surfaces only. - Sliced, in which the surface is stored as a 2D array, with array slice n containing all pixel data for sample n. On Gen7 this layout is used for color surfaces. The "Sliced" layout has an additional requirement: it must be used in ARYSPC_LOD0 mode, which means that the surface doesn't leave any extra room between array slices for miplevels other than 0. This patch modifies the surface allocation functions to use the correct layout when allocating MSAA surfaces in Gen7, and to set the array offsets properly when using ARYSPC_LOD0 mode. It also modifies the code that populates SURFACE_STATE structures to ensure that ARYSPC_LOD0 mode is selected in the appropriate circumstances. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/msaa: Add defines for Gen7.Paul Berry2012-05-251-0/+5
| | | | | | Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Enable blorp blits on Gen7.Paul Berry2012-05-252-2/+4
| | | | | | | | | | | | | Gen7 support for blorp (blits using the render bath) now works for non-MSAA purposes. This patch enables it. Since blorp operations re-use the logic for HiZ ops, this required adding a case to the switch statement in gen7_blorp_emit_wm_config(), to allow for the case where no HiZ op is being performed. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Implement proper texel fetch messages for Gen7.Paul Berry2012-05-252-2/+31
| | | | | | | | | | | | | | | | | On Gen6, texel fetch is always accomplished using the SAMPLE_LD message, which accepts arguments (u, v, r, lod, si). On Gen7, there are two* texel fetch messages: SAMPLE_LD for non-MSAA surfaces, taking arguments (u, lod, v), and SAMPLE_LD2DSS for MSAA surfaces, taking arguments (si, u, v). *Technically, there are other texel fetch messages, but they are used for "compressed" MSAA surfaces, which we don't yet support. This patch adds the proper message types and argument orderings for Gen7. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Use 16 pixel dispatch on Gen7.Paul Berry2012-05-251-1/+9
| | | | | | | | | | | | | | | | | Gen7 hardware requires us to enable at least one WM dispatch mode, even if there is no program being dispatched to. When this code was only used for HiZ operations (which don't use a WM program), we used 32-pixel dispatch, because it didn't matter. But blit programs are compiled for 16-pixel dispatch. So just enable 16-wide dispatch unconditionally. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> v2: Enable 16-wide dispatch unconditionally rather than add the unnecessary complication of using 32-wide dispatch when there is no WM program.
* i965/blorp: Allocate space for push constants on Gen7.Paul Berry2012-05-253-30/+28
| | | | | | | | | | | | | | | | | | On Gen7, push constants for shader programs are stored in the URB, so blorp code needs to set aside space for them. This was previously unnecessary because blorp code was based on HiZ operations, which don't require any shaders. This patch adds a call from gen7_blorp_exec() to gen7_allocate_push_constants(), to ensure that push constants are assigned the correct location in the URB. It also extracts a new function gen7_emit_urb_state() from gen7_upload_urb(), which is re-used by gen7_blorp_emit_urb_config() to ensure that the URB regions used by all the pipeline stages leave room for the push constants. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Set the dynamic state upper bound.Paul Berry2012-05-251-1/+6
| | | | | | | | | | | We know from previous bug fixes (commits c25e5300cba7628b58df93ead14ebc3cc32f338c and b2ace06cbbbb1021e2d7ace12a985c6406821939) that texture border color doesn't work if the dynamic state upper bound is set to 0. Although the blorp engine doesn't make use of texture borders, it seems like we ought to err on the safe side and set this value properly. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Factor gen6_blorp_emit_batch_head into separate functions.Paul Berry2012-05-253-34/+49
| | | | | | | | | | | | This patch separates out the portions of gen6_blorp_emit_batch_head() that emit 3DSTATE_MULTISAMPLE, 3DSTATE_SAMPLE_MASK, and STATE_BASE_ADDRESS. This paves the way for making the blorp code work on Gen7, where additional command packets (3DSTATE_PUSH_CONSTANT_ALLOC_VS and 3DSTATE_PUSH_CONSTANT_ALLOC_PS) need to be emitted before 3DSTATE_MULTISAMPLE. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Use MSDISPMODE_PERSAMPLE rendering when necessaryPaul Berry2012-05-254-27/+87
| | | | | | | | | | | | | | This patch modifies the "blorp" WM program so that it can be run in MSDISPMODE_PERSAMPLE (which means that every single sample of a multisampled render target is dispatched to the WM program, not just every pixel). Previously we were using the ugly hack of configuring multisampled destination surfaces as single-sampled, and generating sample indices other than zero by swizzling the pixel coordinates in the WM program. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/blorp: Emit sample index in SAMPLE_LD message when necessaryPaul Berry2012-05-252-21/+36
| | | | | | | | | | | | | This patch modifies the function brw_blorp_blit_program::texel_fetch() to emit the SI (sample index) argument to the SAMPLE_LD message when reading from a sample index other than zero. Previously we were using the ugly hack of configuring multisampled source surfaces as single-sampled, and accessing sample indices other than zero by swizzling the texture coordinates in the WM program. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Generalize sampling code in preparation for Gen7Paul Berry2012-05-251-26/+61
| | | | | | | | | | | | | | | | This patch generalizes the function brw_blorp_blit_program::texture_lookup() so that it prepares the arguments to the sampler message based on a caller-provided array rather than assuming the argument order is always (u, v). This paves the way for the messages we will need to use in Gen7, which use argument orders (u, lod, v) and (si, u, v) (si=sample index). It will also will allow us to read from arbitrary sample indices on Gen6, by supplying the arguments (u, v, r, lod, si) to the SAMPLE_LD message instead of just (u, v). Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Gut the separate OpenGL ES extension enabling.Kenneth Graunke2012-05-232-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | We should just set the bits of functionality that we support; the GL/ES1/ES2 flags in extensions.c will take care of advertising the appropriate extensions for the current API. This enables the GL_EXT_texture_compression_dxt1 extension on ES1/ES2 when libtxc_dxtn is installed or the force_s3tc driconf option is set. The main extension code set this up properly, but the ES-specific code failed to do so. Otherwise, the extension strings reported by es1_info, es2_info, and glxinfo all remain the same. This patch manually disables the ARB_framebuffer_object bit on ES to preserve the behavior of 1c0f5d8324c4db2720247989ddc4a45315b55a85. v2: Rebase, fix the i915 Makefile, and unconditionally set the OES_draw_texture bit as core Mesa will only apply it to ES1 now. Tested-by: Daniel Charles <[email protected]> [v1] Reviewed-by: Chad Versace <[email protected]> [v1] Signed-off-by: Kenneth Graunke <[email protected]>
* i965: use cut index to handle primitive restart when possibleJordan Justen2012-05-231-1/+80
| | | | | | | | | | | | | If the primitive restart index and the primitive type can be handled by the cut index feature, then use the hardware to handle the primitive restart feature. The VBO module's software handling of primitive restart is used as a fall back. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: add flag to enable cut_indexJordan Justen2012-05-234-1/+12
| | | | | | | | | When brw->prim_restart.enable_cut_index is set, the cut index will be enabled when uploading index_buffer commands. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: create code path to handle primitive restart in hardwareJordan Justen2012-05-236-0/+108
| | | | | | | | | | | | | | For newer hardware we disable the VBO module's software handling of primitive restart. We now handle primitive restarts in brw_handle_primitive_restart. The initial version of brw_handle_primitive_restart simply calls vbo_sw_primitive_restart, and therefore still uses the VBO module software primitive restart support. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/gen6+: Add support for GL_ARB_blend_func_extended.Eric Anholt2012-05-2312-8/+111
| | | | | | | v2: Add support for gen6, and don't turn it on if blending is disabled. (fixes GPU hang), and note it in docs/GL3.txt Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen6+: Add support for fast depth clears.Eric Anholt2012-05-237-12/+145
| | | | | | | | | | Improves citybench high-res performance 3.0% +- 0.4%, n=10. Improves Lightsmark 1024x768 performance 0.74% +/- 0.20% (n=78). No significant difference on openarena (n=5, didn't fast clear) or nexuiz (n=3). Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/gen6: Add CC viewport state setup to blorp code.Eric Anholt2012-05-231-0/+26
| | | | | | | | While it doesn't have the same warning in the simulator as in gen7, let's emit it out of paranoia. We wouldn't want our resolves of some previous clear to get clamped to some current clamping value. Suggested-by: pretty much everyone
* i965/gen7: Add CC viewport setup to blorp code.Eric Anholt2012-05-231-0/+21
| | | | | | | | | | | | | | | When doing fast clears, a fulsim warning said that the batch was being emitted without the viewport set up. While the fast clear pass I was looking at doesn't use the clear value, the later resolves which also didn't set up the vieport would trigger the same. It's not obvious from the error message whether it meant "fast clear value gets clamped to something you haven't defined" or "fast clear value doesn't get clamped, and I saw it was out of the current (uninitialized) range, and you probably wanted it clamped to that (uninitialized) range". Be paranoid and assume the first case. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Drop a layer of indirection in doing HiZ resolves.Eric Anholt2012-05-235-81/+0
| | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Add an interface for doing hiz ops from C code.Eric Anholt2012-05-232-15/+12
| | | | | | | | This required moving gen6_hiz_op, and I put it in intel_resolve_map.h for the next commit. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Rename the clear function for this driver.Eric Anholt2012-05-231-2/+2
| | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Simplify the remaining clear logic by relying on the meta clear.Eric Anholt2012-05-231-47/+11
| | | | | | | | The GLSL clear path doesn't need any buffer presence checks, since those are already handled in the normal drawing path code. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Switch blit color clears to tri clears on gen4/5.Eric Anholt2012-05-231-28/+2
| | | | | | | | | | | | | | Our understanding is that the 3D engine is supposed to be faster anyway. We used to have more overhead in our tri clear path than we do today, which would have led to this choice. But given that we almost always see a depth clear along with a color clear, the path was hardly exercised anyway. Also, the color mask logic was broken in the presence of GL_EXT_draw_buffers2's per-buffer colormask. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Remove dead logic for non-tri depth/stencil clears.Eric Anholt2012-05-231-26/+2
| | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: We always have GLSL, so always use it for tri clears.Eric Anholt2012-05-231-4/+1
| | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* intel: Fork the intel_clear.c file between i915 and i965.Eric Anholt2012-05-233-2/+204
| | | | | | | | This logic is wasted on i965 when we want to just always do GLSL tri clears. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Completely annotate the batch bo when aub dumping.Paul Berry2012-05-224-26/+112
| | | | | | | | | | | | | | | | | | | Previously, when the environment variable INTEL_DEBUG=aub was set, mesa would simply instruct DRM to start dumping data to an .aub file, but we would not provide DRM with any information about the format of the data in various buffers. As a result, a lot of the data in the generate .aub file would be unannotated, making further data analysis difficult. This patch causes the entire contents of each batch buffer to be annotated using the data in brw->state_batch_list (which was previously used only to annotate the output of INTEL_DEBUG=bat). This includes data that was allocated by brw_state_batch, such as binding tables, surface and sampler states, depth/stencil state, and so on. The new annotation mechanism requires DRM version 2.4.34. Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Fix up swizzle for dereference_array of matrices.Eric Anholt2012-05-171-2/+2
| | | | | | | | | Fixes assertion failure in piglit: vs-mat2-struct-assignment.shader_test vs-mat2-array-assignment.shader_test Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/fs: Do more register coalescing by using the interference graph.Eric Anholt2012-05-172-0/+62
| | | | | | | | | | | | | | By using the live variables code for determining interference, we can handle coalescing in the presence of control flow, which the other register coalescing path couldn't. Total instructions: 207184 -> 206990 74/1246 programs affected (5.9%) 33993 -> 33799 instructions in affected programs (0.6% reduction) There is a newerth shader that loses out, because of some extra MOVs that now get their dead-code nature obscured by coalescing. This should be fixed by doing better at dead code elimination.
* i965/blorp: Move exec() out of brw_blorp_params.Paul Berry2012-05-153-6/+9
| | | | | | | | | No functional change. This patch replaces the brw_blorp_params::exec() method with a global function brw_blorp_exec() that performs the operation described by the params data structure. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen6: Initial implementation of MSAA.Paul Berry2012-05-1518-103/+581
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables MSAA for Gen6, by modifying intel_mipmap_tree to understand multisampled buffers, adapting the rendering pipeline setup to enable multisampled rendering, and adding multisample resolve operations to brw_blorp_blit.cpp. Some preparation work is also included for Gen7, but it is not yet enabled. MSAA support is still fairly preliminary. In particular, the following are not yet supported: - Fully general blits between MSAA and non-MSAA buffers. - Formats other than RGBA8, DEPTH24, and STENCIL8. - Centroid interpolation. - Coverage parameters (glSampleCoverage, GL_SAMPLE_ALPHA_TO_COVERAGE, GL_SAMPLE_ALPHA_TO_ONE, GL_SAMPLE_COVERAGE, GL_SAMPLE_COVERAGE_VALUE, GL_SAMPLE_COVERAGE_INVERT). Fixes piglit tests "EXT_framebuffer_multisample/accuracy" on i965/Gen6. v2: - In intel_alloc_renderbuffer_storage(), quantize the requested number of samples to the next higher sample count supported by the hardware. This ensures that a query of GL_SAMPLES will return the correct value. It also ensures that MSAA is fully disabled on Gen7 for now (since Gen7 MSAA support doesn't work yet). - When reading from a non-MSAA surface, ensure that s_is_zero is true so that we won't try to read from a nonexistent sample.
* i965/gen6+: Add code to perform blits on the render path ("blorp").Paul Berry2012-05-157-27/+1721
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch expands the "blorp" component to be able to perform blits as well as HiZ resolves. The new blitting code is located in brw_blorp_blit.cpp. This includes the necessary fragment shader code to look up pixels in the source buffer (which is configured as a texture) and output them to the destination buffer (which is configured as the render target). Most of the time the fragment shader code is simple and straightforward, since it merely has to apply a coordinate offset, read from the texture, and write to the render target. However, in the case of blitting stencil buffers, things are more complicated, since the GPU stores stencil data using W tiling, and W tiling is not supported for textures or render targets. So, we set up the stencil buffers as Y tiled, and emit fragment shader code that adjusts the coordinates to account for the difference between W and Y tiling. Furthermore, since a rectangular region in W tiling does not necessarily correspond to a rectangular region in Y tiling, we widen the rectangle primitive to the nearest tile boundary and have the fragment shader "kill" any pixels that don't fall inside the actual desired destination rectangle. All of this is a necessary prerequisite for implementing MSAA, since we'll need to be able to blit between multisample color, depth, and stencil buffers and their non-multisampled counterparts, and none of the existing blitting mechanisms support multisampling. In addition, the new blitting code should speed up operations where we previously fell back to software rasterization, such as blitting of stencil buffers. The current fallback sequence is: first we try to do a blit using the hardware blitting engine. If that fails we try to do a blit using the render path. If that also fails then we do the blit using a meta-op (which may or may not fall back to software rasterization). Note that blitting using the render path has some limitations at the moment: it only supports a few formats, and it doesn't support clipping or scissoring. These limitations will be addressed in future patch series. v2: - Add the code that configures the WM program to gen{6,7}_emit_wm_config() and gen7_emit_ps_config() rather than creating separate ...enable() functions. - Call intel_prepare_render before determining which miptrees we are blitting from/to, because it may cause miptrees to be reallocated. - Allow the blit to mirror X and/or Y coordinates. - Disable blorp blits on Gen7 for now, since they aren't working yet.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-04 17:07:27 +0000