aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965
Commit message (Collapse)AuthorAgeFilesLines
* i965: Make brw_set_saturate() use stdbool.Eric Anholt2012-08-082-3/+3
| | | | | | There was a chance for brw_wm_emit.c to screw up and pass (1 << 4) instead of 1, which would get converted to 0 when stored. Instead, use stdbool which converts nonzero to true/1 like we want.
* i965: Use 64-bit writes for occlusion queries.Kenneth Graunke2012-08-081-2/+3
| | | | | | | | | | | | | | | The hardware seems to use the length of the PIPE_CONTROL command to indicate whether the write is 64-bits or 32-bits. Which makes sense for immediate writes. Daniel discovered this by writing a pattern into the query object bo and noticing that the high 32-bits were left intact, even on those pipe control writes that seemingly worked. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Refactor depth count write PIPE_CONTROLs into a helper function.Kenneth Graunke2012-08-081-68/+43
| | | | | | | | | | This consolidates the complexity in one place, which is important because it's about to get even more complicated. Signed-off-by: Kenneth Graunke <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Emit a CS stall before timestamp writes.Kenneth Graunke2012-08-081-0/+14
| | | | | | | | | | This implements one of the Sandybridge PIPE_CONTROL workarounds. It doesn't appear to be required for Ivybridge. Signed-off-by: Kenneth Graunke <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Use 64-bit writes for timestamp queries.Kenneth Graunke2012-08-081-2/+3
| | | | | | | | | | | | | | | The hardware seems to use the length of the PIPE_CONTROL command to indicate whether the write is 64-bits or 32-bits. Which makes sense for immediate writes. Daniel discovered this by writing a pattern into the query object bo and noticing that the high 32-bits were left intact, even on those pipe control writes that seemingly worked. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Refactor timestamp write PIPE_CONTROLs into a helper function.Kenneth Graunke2012-08-081-50/+30
| | | | | | | | | This consolidates the complexity in one place, which is important because it's about to get even more complicated. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Make the length for PIPE_CONTROL explicit.Kenneth Graunke2012-08-082-11/+11
| | | | | | | | | | | | | | | | PIPE_CONTROL has variable length, depending upon generation and whether we want to do 32-bit or 64-bit data writes. Make it explicit, rather than hiding a length of 4 in the #define for _3DSTATE_PIPE_CONTROL. Generated by s/3DSTATE_PIPE_CONTROL/3DSTATE_PIPE_CONTROL | (4 - 2)/g. This is equivalent since the #define used to have | 2 in it. A grep through the sources shows that all instances have been converted, so it's safe to remove the | 2 from the #define. Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Add support for loading uniform buffer variables as pull constants.Eric Anholt2012-08-072-2/+55
| | | | | | | | Unlike the FS side in the previous commit, this does variable indexing just fine, using the same code as we used for other variable-indexed pull constants. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Add support for loading uniform buffer variables as pull constants.Eric Anholt2012-08-073-1/+50
| | | | | | | | Variable array indexing isn't finished, because the lowering pass turns it all into conditional moves of constant index accesses so I can't test it. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: Add a surface index to VS_OPCODE_PULL_CONSTANT instructions.Eric Anholt2012-08-073-10/+17
| | | | | | | Similar to the previous commit for the fragment shader, now we have a buffer index and an offset. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Communicate the pull constant block read parameters through fs_regs.Eric Anholt2012-08-073-6/+20
| | | | | | | | | | | I wanted to add the surface index as a variable value for UBO support, and a reg seemed like the obvious way to go. This exposes more of the information to CSE, which we'll probably want to apply to pull constant loads for UBOs eventually (you might access 4 floats in a row, each of which would produce an oword block read of the same block). Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Bind UBOs as surfaces like we do for pull constants.Eric Anholt2012-08-076-3/+110
| | | | | | v2: Comment fix, drop extraneous parens (review by Kenneth) Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add an offset argument to constant buffer setup.Eric Anholt2012-08-074-6/+10
| | | | | | We'll use this for UBO surfaces. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Add a "ubo_load" expression type for fetches from UBOs.Eric Anholt2012-08-073-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drivers will probably want to be able to take UBO references in a shader like: uniform ubo1 { float a; float b; float c; float d; } void main() { gl_FragColor = vec4(a, b, c, d); } and generate a single aligned vec4 load out of the UBO. For intel, this involves recognizing the shared offset of the aligned loads and CSEing them out. Obviously that involves breaking things down to loads from an offset from a particular UBO first. Thus, the driver doesn't want to see variable_ref(ir_variable("a")), and even more so does it not want to see array_ref(record_ref(variable_ref(ir_variable("a")), "field1"), variable_ref(ir_variable("i"))). where a.field1[i] is a row_major matrix. Instead, we're going to make a lowering pass to break UBO references down to expressions that are obvious to codegen, and amenable to merging through CSE. v2: Fix some partial thoughts in the ir_binop comment (review by Kenneth) Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Fix compiler warnings from winsys msaa.Eric Anholt2012-08-071-2/+0
|
* i965: Mark needed downsamples for msaa winsys buffersChad Versace2012-08-072-6/+16
| | | | | | | | | | | | | Add function intel_renderbuffer_set_needs_downsample. It is a no-op except on multisample winsys buffers shared with DRI2. Mark the needed downsamples with the new function at two locations: - Immediately after drawing is complete. - After blitting. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965: Add function brw_blorp_blit_miptreesChad Versace2012-08-072-4/+37
| | | | | | | | | | Define a function, brw_blorp_blit_miptrees, that simply wraps brw_blorp_blit_params + brw_blorp_exec with C calling conventions. This enables intel_miptree.c, in a following commit, to perform blits with blorp for the purpose of downsampling multisample miptrees. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* i965: Allocate dummy slots for point sprites before computing VUE map.Kenneth Graunke2012-08-061-2/+2
| | | | | | | | | | | | | | Commit f0cecd43d6b6d moved the VUE map computation to be only once, at VS compile time. However, it did so in slightly the wrong place: it made the one call to brw_vue_compute_map happen right before the allocation of dummy slots for replaced point sprite coordinates, causing a different VUE map to be generated (at least on Ironlake). Fixes a regression in Piglit's point-sprite test on Ironlake. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46489 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Don't clobber sampler message MRFs with subexpressions.Kenneth Graunke2012-08-061-17/+42
| | | | | | | | | | | | See the preceding commit for a description of the problem. NOTE: This is a candidate for stable release branches. v2: Use a separate dPdx variable rather than reusing the lod src_reg. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52129 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Don't clobber sampler message MRFs with subexpressions.Kenneth Graunke2012-08-062-70/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider a texture call such as: textureLod(s, coordinate, log2(...)) First, we begin setting up the sampler message by loading the texture coordinates into MRFs, starting with m2. Then, we realize we need the LOD, and go to compute it with: ir->lod_info.lod->accept(this); On Gen4-5, this will generate a SEND instruction to compute log2(), loading the operand into m2, and clobbering our texcoord. Similar issues exist on Gen6+. For example, nested texture calls: textureLod(s1, c1, texture(s2, c2).x) Any texturing call where evaluating the subexpression trees for LOD or shadow comparitor would generate SEND instructions could potentially break. In some cases (like register spilling), we get lucky and avoid the issue by using non-overlapping MRF regions. But we shouldn't count on that. Fixes four Piglit test regressions on Gen4-5: - glsl-fs-shadow2DGradARB-{01,04,07,cumulative} NOTE: This is a candidate for stable release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52129 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Factor out texcoord setup into a helper function.Kenneth Graunke2012-08-062-11/+28
| | | | | | | | | With the textureRect support and GL_CLAMP workarounds, it's grown sufficiently that it deserves its own function. Separating it out makes the original function much more readable. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/fs: Move message header and texture offset setup to generate_tex().Kenneth Graunke2012-08-063-21/+27
| | | | | | | | | | | | Setting the texture offset bits in the message header involves very specific hardware register descriptions. As such, I feel it's better suited for the lower level "generate" layer that has direct access to the weird register layouts, rather than at the fs_inst abstraction layer. This also parallels the approach I took in the VS backend. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Move DepthMode to texture objectPauli Nieminen2012-08-013-3/+3
| | | | | | | | | | | | | | | | | | | | | | | GL_DEPTH_TEXTURE_MODE isn't meant to be part of sampler state based on compatibility profile specifications. OpenGL specification 4.1 compatibility 20100725 3.9.2: "... The values accepted in the pname parameter are TEXTURE_WRAP_S, TEXTURE_WRAP_T, TEXTURE_WRAP_R, TEXTURE_MIN_- FILTER, TEXTURE_MAG_FILTER, TEXTURE_BORDER_COLOR, TEXTURE_MIN_- LOD, TEXTURE_MAX_LOD, TEXTURE_LOD_BIAS, TEXTURE_COMPARE_MODE, and TEXTURE_COMPARE_FUNC. Texture state listed in table 6.25 but not listed here and in the sampler state in table 6.26 is not part of the sampler state, and remains in the texture object." The list of states is in Table 6.24 "Textures (state per texture object)" instead of 6.25 mentioned in the specification text. Same can be found from 3.3 compatibility specification. Signed-off-by: Pauli Nieminen <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/msaa: Treat GL_SAMPLES=1 as equivalent to GL_SAMPLES=0.Paul Berry2012-08-0110-19/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | EXT_framebuffer_multisample is a required subpart of ARB_framebuffer_object, which means that we must support it even on platforms that don't support MSAA. Fortunately EXT_framebuffer_multisample allows for this by allowing GL_MAX_SAMPLES to be set to 1. This leads to a tricky quirk in the GL spec: since GlRenderbufferStorageMultisamples() accepts any value for its "samples" parameter up to and including GL_MAX_SAMPLES, that means that on platforms that don't support MSAA, GL_SAMPLES is allowed to be set to either 0 or 1. On platforms that do support MSAA, GL_SAMPLES=1 is not used; 0 means no MSAA, and 2 or higher means MSAA. In other words, GL_SAMPLES needs to be interpreted as follows: =0 no MSAA (possible on all platforms) =1 no MSAA (only possible on platforms where MSAA unsupported) >1 MSAA (only possible on platforms where MSAA supported) This patch modifies all MSAA-related code to choose between multisampling and single-sampling based on the condition (GL_SAMPLES > 1) instead of (GL_SAMPLES > 0) so that GL_SAMPLES=1 will be treated as "no MSAA". Note that since GL_SAMPLES=1 implies GL_SAMPLE_BUFFERS=1, we can no longer use GL_SAMPLE_BUFFERS to distinguish between MSAA and non-MSAA rendering. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Add support for GL_SKIP_DECODE_EXT on other SRGB formats.Eric Anholt2012-07-311-8/+3
| | | | | | | | | | | Fixes some failures in getteximage-formats. v2: Remove stray include, and drop extra test for encoding == GL_SRGB -- _mesa_get_srgb_format_linear() returns the same format if it wasn't SRGB. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48120 Reviewed-by: Kenneth Graunke <[email protected]> (v1) NOTE: This is a candidate for the 8.0 branch.
* i965: Support MESA_FORMAT_SIGNED_RGBA_16.Kenneth Graunke2012-07-301-1/+1
| | | | | | | | | | | | | | | | The hardware supports this format with no known quirks, so we may as well enable it. Alpha blending is not supported until Sandybridge, but as far as I can tell, OpenGL doesn't require alpha blending on SNORM formats. Plus, we already expose R8G8B8A8_SNORM which has a similar restriction. Fixes 6 piglit texwrap-2D-*SNORM* cases, gl-3.1/required-sized-texture-formats, and 10 oglconform snorm-textures subcases Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7: Reduce GT1 WM thread count according to updated BSpec.Eric Anholt2012-07-271-1/+1
| | | | | | Acked-by: Kenneth Graunke <[email protected]> https://bugs.freedesktop.org/show_bug.cgi?id=52382
* i965: Fix typo in shader channel select field name.Kenneth Graunke2012-07-273-20/+20
| | | | | | "chanel" isn't very searchable. I can type, honest! Signed-off-by: Kenneth Graunke <[email protected]>
* intel: increase wm thread number to 80 on gen6 GT2Zou Nan hai2012-07-271-5/+1
| | | | | | | | | | | | | It seems reset is not required for setting the max_wm_threads to 80 on gen6 GT2. Increases performance in the Counter-Strike: Source video stress test by 7.18% (n=5). Signed-off-by: Zou Nan hai <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Tested-by: Matt Turner <[email protected]> Acked-by: Eric Anholt <[email protected]>
* i965/msaa: use ROUND_DOWN_TO macro.Paul Berry2012-07-261-6/+6
| | | | | | | | No functional change. This patch modifies brw_blorp_blit.cpp to use the ROUND_DOWN_TO macro instead of open-coded bit manipulations, for clarity. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Use sendc for all render target writes on Gen6+.Paul Berry2012-07-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The sendc instruction causes the fragment shader thread to wait for any dependent threads (i.e. threads rendering to overlapping pixels) to complete before sending the message. We need to use sendc on the first render target write in order to guarantee that fragment shader outputs are written to the render target in the correct order. Previously, we only used the "sendc" instruction when writing to binding table index 0. This did the right thing for fragment shaders, because our fragment shader back-ends always issue their first render target write to binding table index 0. However, it did the wrong thing for blorp, which performs its render target writes to binding table index 1. A more robust solution is to use sendc for all render target writes. This should not produce any performance penalty, since after the first sendc, all of the dependent threads will have completed. For more information about sendc, see the Ivy Bridge PRM, Vol4 Part3 p218 (sendc - Conditional Send Message), and p54 (TDR Registers). Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/msaa: Remove TODO comments that are no longer relevant.Paul Berry2012-07-262-3/+2
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Make more consistent use of _mesa_is_{user,winsys}_fbo()Paul Berry2012-07-261-2/+3
| | | | | | | | | | A lot of code was still differentiating between between winsys and user fbos by testing the fbo's name against zero. This converts everything in the i915 and 965 drivers over to use _mesa_is_user_fbo() and _mesa_is_winsys_fbo(). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove unused param conversion code.Eric Anholt2012-07-257-80/+3
| | | | | | | | Ever since ctx->NativeIntegers was set, the conversion flag has been PARAM_NO_CONVERT. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/msaa: Switch on 8x MSAA for Gen7.Paul Berry2012-07-241-1/+3
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/msaa: Remove assertion in 3DSTATE_SAMPLE_MASK to allow 8x MSAA.Paul Berry2012-07-241-3/+0
| | | | | | | | The code to emit 3DSTATE_SAMPLE_MASK was already correct for 8x MSAA--this patch just removes an assertion that would have prevented it from being used for 8x MSAA. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/msaa: Adjust 3DSTATE_MULTISAMPLE packet for 8x MSAA.Paul Berry2012-07-241-6/+64
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Encode and decode IMS format for 8x MSAA correctly.Paul Berry2012-07-241-39/+107
| | | | | | | | This patch updates the blorp functions encode_msaa() and decode_msaa() to properly handle the encoding of IMS MSAA buffers when num_samples=8. Acked-by: Kenneth Graunke <[email protected]>
* i965/blorp: Compute sample number correctly for 8x MSAA.Paul Berry2012-07-241-13/+42
| | | | | | | | | | When operating in persample dispatch mode, the blorp engine would previously assume that subspan N always represented sample N (this is correct assuming 4x MSAA and a 16-wide dispatch). In order to support 8x MSAA, we must compute which sample is associated with each subspan, using the "Starting Sample Pair Index" field in the thread payload. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Properly adjust primitive size for 8x MSAA.Paul Berry2012-07-241-4/+17
| | | | | | | | | | | | | | When rendering to an IMS MSAA surface on Gen7, blorp sets up the rendering pipeline as though it were rendering to a single-sampled surface; accordingly it must adjust the size of the primitive it sends down the pipeline to account for the interleaving of samples in an IMS surface. This patch modifies the size adjustment code to properly handle 8x MSAA, which makes room for the extra samples by using an interleaving pattern that is twice as wide as 4x MSAA. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/blorp: Parameterize manual_blend() by num_samples.Paul Berry2012-07-241-8/+5
| | | | | | | | | | | | This patch adds a num_samples argument to the blorp function manual_blend(), allowing it to be told how many samples need to be blended together. Previously it assumed 4x MSAA, since that was all we supported. We also bump up LOG2_MAX_BLEND_SAMPLES from 2 to 3, so that manual_blend() will be able to handle 8x MSAA. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/msaa: Remove comment about falsely claiming to support MSAA.Paul Berry2012-07-241-5/+0
| | | | | | Gen6+ hardware now supports MSAA properly. Reviewed-by: Chad Versace <[email protected]>
* i965/blorp: Handle DrawBuffers properly.Paul Berry2012-07-241-7/+10
| | | | | | | | | | | | When the client program uses glDrawBuffer() or glDrawBuffers() to select more than one color buffer for drawing into, and then performs a blit, we need to blit into every single enabled draw buffer. +2 oglconforms. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50407 Reviewed-by: Chad Versace <[email protected]>
* i965/blorp: Rearrange order of blit validation and preparation steps.Paul Berry2012-07-241-55/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch rearranges the order of steps performed by a blorp blit from this: - Sync up state of window system buffers. - Find buffers. - Find miptrees. - Make sure buffer formats match. - Handle mirroring. - Make sure width and height match. - Handle clipping/scissoring. - Account for window system origin conventions. - Do depth resolves, if applicable. - Do the blit. - Record the need for a future HiZ resolve, if applicable. To this: - Sync up state of window system buffers. - Handle mirroring. - Make sure width and height match. - Handle clipping/scissoring. - Account for window system origin conventions. - Find buffers. - Make sure buffer formats match. - Find miptrees. - Do depth resolves, if applicable. - Do the blit. - Record the need for a future HiZ resolve, if applicable. The steps are the same, but they are now performed in an order that will make it possible to implement correct DrawBuffers support. Note that the last four steps are now in a separate function (do_blorp_blit), since they will need to be executed repeatedly when DrawBuffers support is added. Reviewed-by: Chad Versace <[email protected]>
* i965/blorp: Don't fall back to swrast when miptrees absent.Paul Berry2012-07-241-6/+2
| | | | | | | | | | | | | Previously, the blorp engine would fall back to swrast if the source or destination of a blit had no associated miptree. This was unnecessary, since _mesa_BlitFramebufferEXT() already takes care of making the blit silently succeed if there are no buffers bound, so the fallback paths could never actually happen in practice. Removing these fallback paths will simplify the implementation of correct DrawBuffers support in blorp. Reviewed-by: Chad Versace <[email protected]>
* i965/blorp: Fixup scissoring of blits to window system buffers.Paul Berry2012-07-241-12/+16
| | | | | | | | | | | | | This patch modifies the order of operations in the blorp engine so that clipping and scissoring are performed before adjusting the coordinates to account for the difference in origin convention between window system buffers and framebuffer objects. Previously, we would do clipping and scissoring after adjusting for origin conventions, so we would get scissoring wrong in window system buffers. Fixes Piglit test "fbo-scissor-blit window". Reviewed-by: Chad Versace <[email protected]>
* i965/blorp: Simplify check that src/dst width/height match.Paul Berry2012-07-241-4/+2
| | | | | | | | | | | When checking that the source and destination dimensions match, we don't need to store the width and height in variables; doing so just risks confusion since right after the check, we do clipping and scissoring, which may alter the width and height. No functional change. Reviewed-by: Chad Versace <[email protected]>
* i965/msaa: Work around problems with null render targets on Gen6.Paul Berry2012-07-242-4/+49
| | | | | | | | | | | | | | | On Gen6, multisampled null render targets don't seem to work properly--they cause the GPU to hang. So, as a workaround, we render into a dummy color buffer. Fortunately this situation (multisampled rendering without a color buffer) is rare, and we don't have to waste too much memory, because we can give the workaround buffer a very small pitch. Fixes piglit test "EXT_framebuffer_multisample/no-color {2,4} depth-computed *" on Gen6. Reviewed-by: Chad Versace <[email protected]>
* i965: Set width, height, and tiling properly for null render targets.Paul Berry2012-07-242-2/+60
| | | | | | | | | | The HW docs say that the width and height of null render targets need to match the width and height of the corresponding depth and/or stencil buffers, and that they need to be marked as Y-tiled. Although leaving these values at 0 doesn't seem to cause any ill effects, it seems wise to follow the documented requirements. Reviewed-by: Chad Versace <[email protected]>
* i965/msaa: Control multisampling behaviour via the visual.Paul Berry2012-07-245-17/+7
| | | | | | | | | | | | | Previously, we used the number of samples in draw buffer 0 to determine whether to set up the 3D pipeline for multisampling. Using the visual is cleaner, and has the benefit of working properly when there is no color buffer. Fixes all piglit tests "EXT_framebuffer_multisample/no-color" on Gen7. On Gen6, the "depth-computed" variants of these tests still fail; this will be addresed in a later patch. Reviewed-by: Chad Versace <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-16 01:39:27 +0000