aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* mesa: move gl_client_array*[] from vbo_draw_func into gl_contextMarek Olšák2012-05-083-7/+5
| | | | | | | | | | | | | | | | | | In the future we'd like to treat vertex arrays as a state and not as a parameter to the draw function. This is the first step towards that goal. Part of the goal is to avoid array re-validation for every draw call. This commit adds: const struct gl_client_array **gl_context::Array::_DrawArrays. The pointer is changed in: * vbo_draw_method * vbo_rebase_prims - unused by gallium * vbo_split_prims - unused by gallium * st_RasterPos Reviewed-by: Brian Paul <[email protected]>
* i965/Gen7: Work around GPU hangs due to misaligned depth coordinate offsets.Paul Berry2012-05-072-0/+54
| | | | | | | | | | | | | | | | | | | | In i965 Gen7, Mesa has for a long time used the "depth coordinate offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to render to miplevels other than 0. Unfortunately, this doesn't work, because these offsets must be aligned to multiples of 8, and miplevels in the depth buffer are only guaranteed to be aligned to multiples of 4. When the offsets aren't aligned to a multiple of 8, the GPU sometimes hangs. As a temporary measure, to avoid GPU hangs, this patch smashes the 3 LSB's of "depth coordinate offset X/Y" to 0. This results in incorrect rendering to mipmapped depth textures, but that seems like a reasonable stopgap while we figure out a better solution. Avoids GPU hangs in piglit test "depthstencil-render-miplevels" at texture sizes that are not powers of 2. Reviewed-by: Chad Verace <[email protected]>
* i965/Gen6: Work around GPU hangs due to misaligned depth coordinate offsets.Paul Berry2012-05-072-0/+54
| | | | | | | | | | | | | | | | | | | | | | | In i965 Gen6, Mesa has for a long time used the "depth coordinate offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to render to miplevels other than 0. Unfortunately, this doesn't work, because these offsets must be aligned to multiples of 8, and miplevels in the depth buffer are only guaranteed to be aligned to multiples of 4. When the offsets aren't aligned to a multiple of 8, the GPU sometimes hangs. As a temporary measure, to avoid GPU hangs, this patch smashes the 3 LSB's of "depth coordinate offset X/Y" to 0. This results in incorrect rendering to mipmapped depth textures, but that seems like a reasonable stopgap while we figure out a better solution. (Note that we have only ever observed this GPU hang on Gen6 when HiZ is enabled, so another possible stopgap would be to disable HiZ). Avoids GPU hangs in piglit test "depthstencil-render-miplevels" at texture sizes that are not powers of 2. Reviewed-by: Chad Verace <[email protected]>
* i965: Fix mipmap offsets for HiZ and separate stencil buffers.Paul Berry2012-05-078-60/+319
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When rendering to a miplevel other than 0 within a color, depth, stencil, or HiZ buffer, we need to tell the GPU to render to an offset within the buffer, so that the data is written into the correct miplevel. We do this using a coarse offset (in pages), and a fine adjustment (the so-called "tile_x" and "tile_y" values, which are measured in pixels). We have always computed the coarse offset and fine adjustment using intel_renderbuffer_tile_offsets() function. This worked fine for color and combined depth/stencil buffers, but failed to work properly when HiZ and separate stencil were in use. It failed to work because there is only one set of fine adjustment controls shared by the HiZ, depth, and stencil buffers, so we need to choose tile_x and tile_y values that are compatible with the tiling of all three buffers, and then compute separate coarse offsets for each buffer. This patch fixes the HiZ and separate stencil case by replacing the call to intel_renderbuffer_tile_offsets() with calls to two functions: intel_region_get_tile_masks(), which determines how much of the adjustment can be performed using offsets and how much can be performed using tile_x and tile_y, and intel_region_get_aligned_offset(), which computes the coarse offset. intel_region_get_tile_offsets() is still used for color renderbuffers, so to avoid code duplication, I've re-worked it to use intel_region_get_tile_masks() and intel_region_get_aligned_offset(). On i965 Gen6, fixes piglit tests "texturing/depthstencil-render-miplevels 1024 X" where X is one of (depth, depth_and_stencil, depth_stencil_single_binding, depth_x, depth_x_and_stencil, stencil, stencil_and_depth, stencil_and_depth_x). On i965 Gen7, the variants of "texturing/depthstencil-render-miplevels" that contain a stencil buffer still fail, due to another problem: Gen7 seems to ignore the 3 LSB's of the tile_y adjustment (and possibly also tile_x). v2: Removed spurious comments. Added assertions to check preconditions of intel_region_get_aligned_offset(). Reviewed-by: Chad Versace <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* intel: Disable ARB_framebuffer_object in ES contextsChad Versace2012-05-071-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes ARB_framebuffer_object from the GLES1 and GLES2 extension lists in intel_extensions_es.c. Fixes a crash in the Android browser on Ice Cream Sandwich. The Android browser crashed because it did the following, which is legal in GLES2 but not in ARB_framebuffer_object. glGenFramebuffers(1, &fb); glBindFramebuffer(GL_FRAMEBUFFER, fb); // render render render... glDeleteFramebuffers(1, &fb); // go do other stuff... glBindFramebuffer(GL_FRAMEBUFFER, fb); // This bind unexpectedly failed, and the app panics. The semantics of glBindFramebuffer specified by ARB_framebuffer_object (a desktop GL extension) and GLES2 specs are incompatible. The ideal solution to fix this is to create separate API entry points for glBindFramebuffer, one for GL and the other for GLES2. But, until that work is complete, disabling ARB_framebuffer_object in GLES2 contexts safely fixes the problem. Likewise, the semantics of glBindFramebuffer in ARB_framebuffer_object and of glBindFramebufferOES in OES_framebuffer_object (a GLES1 extension) are incompatible. Even though the functions have different names, the semantic difference still results in a bug because both API calls are implemented by a single function, _mesa_BindFramebufferEXT, which handles the semantic difference incorrectly. Again, disabling ARB_framebuffer_object in GLES1 contexts safely fixes this problem. According to the ARB_framebuffer_object spec, the extension is an amalgamation of EXT_framebuffer_object EXT_framebuffer_blit EXT_packed_depth_stencil EXT_framebuffer_multisample By disabling this extension, however, no functionality is removed from GLES1 and GLES2 contexts because 1) the first three extensions are explicitly enabled in Intel's ES extension lists and 2) no functionality of the last extension is exposed in an ES context. Note: This is a candidate for the 8.0 branch. See-also: http://www.mail-archive.com/[email protected]/msg21006.html CC: Charles Johnson <[email protected]> CC: Sean Kelley <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: Remove pointless software fallback for glBitmap on Gen6.Kenneth Graunke2012-05-041-4/+0
| | | | | | | | | | We already have a meta path below that works just fine; no apparent regressions in oglconform. NOTE: This is a candidate for the 8.0 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46834 Reviewed-by: Chad Versace <[email protected]>
* i965/fs: Fix regression in comparison handling from ANDs change.Eric Anholt2012-05-042-0/+18
| | | | | | | I had fixed up the logic ops for delayed ANDing, but not equality comparisons on bools. Fixes new piglit fs-bool-less-compare-true. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48629
* i965: Add a comment about the state flag for sRGBEnabled.Eric Anholt2012-05-042-4/+10
| | | | I thought this might be _NEW_COLOR, but it isn't.
* intel: Return success when asked to allocate a 0-width/height renderbuffer.Eric Anholt2012-05-041-0/+3
| | | | | | | | | | | | | It seems silly that GL lets you allocate these given that they're framebuffer attachment incomplete, but the webgl conformance tests actually go looking to see if the getters on 0-width/height depth/stencil renderbuffers return good values. By failing out here, they all got smashed to 0, which turned out to be correct for all the getters they tested except for GL_RENDERBUFFER_INTERNAL_FORMAT. Now, by succeeding but not making a miptree, that one also returns the expected value. Acked-by: Kenneth Graunke <[email protected]>
* i965: Add support for GL_ARB_draw_buffers_blend.Eric Anholt2012-05-042-6/+10
| | | | | | Tested with piglit fbo-draw-buffers-blend and intel oglconform. Reviewed-by: Kenneth Graunke <[email protected]>
* gbm: Add gbm_bo_write entry pointKristian Høgsberg2012-05-032-2/+31
| | | | | | | | | | | | | | | | This new gbm entry point allows writing data into a gbm bo. The bo has to be created with the GBM_BO_USE_WRITE flag, and it's only required to work for GBM_BO_USE_CURSOR_64X64 bos. The gbm API is designed to be the glue layer between EGL and KMS, but there was never a mechanism initialize a buffer suitable for use with KMS hw cursors. The hw cursor bo is typically not compatible with anything EGL can render to, and thus there's no way to get data into such a bo. gbm_bo_write() fills that gap while staying out of the efficient cpu->gpu pixel transfer business. Reviewed-by: Ander Conselvan de Oliveira <[email protected]>
* dri/nv10-nv20: Add support for S3TCViktor Novotný2012-05-024-0/+28
| | | | | Signed-off-by: Viktor Novotný <[email protected]> Signed-off-by: Francisco Jerez <[email protected]>
* dri/nouveau: Add general support for compressed formats.Viktor Novotný2012-05-024-33/+138
| | | | | Signed-off-by: Viktor Novotný <[email protected]> Signed-off-by: Francisco Jerez <[email protected]>
* xlib: use _mesa_is_winsys/user_fbo() helpersBrian Paul2012-05-011-5/+6
| | | | Reviewed-by: Eric Anholt <[email protected]>
* intel: use _mesa_is_winsys/user_fbo() helpersBrian Paul2012-05-0116-32/+48
| | | | Reviewed-by: Eric Anholt <[email protected]>
* nouveau: use _mesa_is_winsys/user_fbo() helpersBrian Paul2012-05-013-3/+7
| | | | Reviewed-by: Eric Anholt <[email protected]>
* radeon: use _mesa_is_winsys/user_fbo() helpersBrian Paul2012-05-014-10/+14
| | | | Reviewed-by: Alex Deucher <[email protected]>
* i965: Support Android RGBX8888 format for EGL generated imagesSean V Kelley2012-04-302-0/+12
| | | | | | | | | | Enabled MESA_FORMAT_RGBX8888_REV for RGBX. Android software requires RGBX8888 format to be supported for software rendering. That requires EGL to be capable of generating images from this format. Signed-off-by: Sean V Kelley <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* intel: set dri_format field for all imagesAnder Conselvan de Oliveira2012-04-301-0/+18
| | | | | | Only images created with intel_create_image() had the field properly set. Set it also on intel_dup_image(), intel_create_image_from_name() and intel_create_image_from_renderbuffer().
* intel: properly return the image format on intel_query_imageAnder Conselvan de Oliveira2012-04-301-1/+2
|
* autoconf: pass -Wall to automakeDylan Noblesmith2012-04-292-6/+6
| | | | | | | And fix these warning that appear at autoreconf time: "`:='-style assignments are not portable" v2: Fix the recently-converted-to-automake r600.
* i965/fs: Fix FB writes that tried to use the non-existent m16 register.Kenneth Graunke2012-04-271-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | A little analysis shows that the worst-case value for "nr" is 17: - base_mrf = 2 ... 2 - header present (say gen == 5) ... 4 - aa_dest_stencil_reg (stencil test) ... 5 - SIMD16 mode: += 4 * reg_width ... 13 - source_depth_to_render_target ... 15 - dest_depth_reg ... 17 This resulted in us setting base_mrf to 2 and mlen to 15. In other words, we'd try to use m2..m16. But m16 doesn't exist pre-Gen6. Also, the instruction scheduler data structures use arrays of size 16, so this would cause us to access them out of bounds. While the debugger system routine may need m0 and m1, we don't use it today, so the simplest solution is just to move base_mrf back to 1. That way, our worst case message fits in m1..m15, which is legal. An alternative would be to fail on SIMD16 in this case, but that seems a bit unfortunate if there's no real need to reserve m0 and m1. Fixes new piglit test shaders/depth-test-and-write on Ironlake. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48218 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/vs: Fix texelFetchOffset()Eric Anholt2012-04-241-3/+23
| | | | | | It appears that when using 'ld' with the offset bits, address bounds checking happens before the offset is applied, so parts of the drawing in piglit texelFetchOffset() with a negative texcoord go black.
* i965/fs: Fix texelFetchOffset()Eric Anholt2012-04-241-6/+21
| | | | | | It appears that when using 'ld' with the offset bits, address bounds checking happens before the offset is applied, so parts of the drawing in piglit texelFetchOffset() with a negative texcoord go black.
* i965: Convert live interval computation to using live variable analysis.Eric Anholt2012-04-191-39/+26
| | | | | | | | | | | | | | | | | | | | Our previous live interval analysis just said that anything in a loop was live for the whole loop. If you had to spill a reg in a loop, then we would consider the unspilled value live across the loop too, so you never made progress by spilling. Eventually it would consider everything in the loop unspillable and fail out. With the new analysis, things completely deffed and used inside the loop won't be marked live across the loop, so even if you spill/unspill something that used to be live across the loop, you reduce register pressure. But you usually don't even have to spill any more, since our intervals are smaller than before. This fixes assertion failure trying to compile the shader for the "glyphy" text rasterier and piglit glsl-fs-unroll-explosion. Improves Unigine Tropics performance 1.3% +/- 0.2% (n=5), by allowing more shaders to be compiled in 16-wide mode.
* i965: Move the old live interval analysis code next to the new live vars code.Eric Anholt2012-04-192-122/+122
| | | | I'm about to replace the insides of this using the new analysis.
* i965: Add support for live variable analysis using dataflow analysis.Eric Anholt2012-04-193-0/+245
|
* i965: Add basic block generator.Eric Anholt2012-04-195-0/+392
| | | | | | This takes the fs_inst list generated by the visitor, and generates a list of basic blocks with edges between them. This is a building block for data-flow analysis.
* i965/fs: Suppress printing the whole loop in BRW_OPCODE_DO annotation.Eric Anholt2012-04-191-0/+2
|
* i965: Rename BRW_MAX_SURFACES to BRW_MAX_WM_SURFACES.Kenneth Graunke2012-04-182-4/+4
| | | | | | | | Now that we use separate binding tables for WM, VS, and GS, and have BRW_MAX_VS_SURFACES and BRW_MAX_GS_SURFACES macros, we really shouldn't have an unqualified BRW_MAX_SURFACES macro. It's confusing. Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Fix outdated comments about binding tables.Kenneth Graunke2012-04-181-12/+8
| | | | | | | | | They had a number of issues: - A paragraph states that we use a single binding table, but we don't. - We labelled the WM binding table diagram as SOL/WM. - The WM diagram had an "Only relevant to the WM" comment. Duh. Signed-off-by: Kenneth Graunke <[email protected]>
* nouveau: rework and simplify nv04/nv05 driver a bitBen Skeggs2012-04-148-300/+215
| | | | | | | | | | | | | | | TEXTURED_TRIANGLE and MULTITEX_TRIANGLE are both a bit special in that if you use any other graph object in the meantime they'll forget their state and spew a lovely METHOD_CNT error at you when you try to draw. The pre-newlib driver has a flush_notify() hook which does this state re-emit, and a number of random workarounds like extra flushes and state dirtying after various operations to solve this issue. I'm taking a slightly different approach to things instead, which has the nice side-effect of removing the divergent code-paths for ttri/mtri, the flush/dirty workarounds and the need for flush_notify. Also gives a few FPS boost in OA, yay.
* nouveau/vieux: switch to libdrm_nouveau-2.0Ben Skeggs2012-04-1446-1890/+1844
|
* i965: fix typoDylan Noblesmith2012-04-131-1/+1
| | | | | | | | | | | | | | | | | | Noticed by clang: brw_wm_surface_state.c:330:30: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] [MESA_FORMAT_Z24_S8] = 0, ^ brw_wm_surface_state.c:326:30: note: previous initialization is here [MESA_FORMAT_Z24_S8] = 0, ^ No functionality change, since the array is declared static so it was zero-initialized by default. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: When the kernel lacks the LLC check, assume it's present on gen >= 6.Eric Anholt2012-04-111-3/+7
| | | | | The param wasn't added until drm-intel-next for 3.4, so we were missing our various LLC fast-paths.
* intel: Drop backwards compat code for not having libdrm with the LLC check.Eric Anholt2012-04-111-4/+0
|
* i965/fs: Avoid generating extra AND instructions on bool logic ops.Eric Anholt2012-04-111-22/+14
| | | | | | | | | | | | | | | | | | | | | | | By making a bool fs_reg only have a defined low bit (matching CMP output), instead of being a full 0 or 1 value, we reduce the ANDs generated in logic chains like: if (v_texcoord.x < 0.0 || v_texcoord.x > texwidth || v_texcoord.y < 0.0 || v_texcoord.y > 1.0) discard; My concern originally when writing this code was that we would end up generating unnecessary ANDs on bool uniforms, so I put the ANDs right at the point of doing the CMPs that otherwise set only the low bit. However, in order to use a bool, we're generating some instruction anyway (e.g. moving it so as to produce a condition code update), and those instructions can often be turned into an AND at that point. It turns out in the shaders I have on hand, none of them regress in instruction count: Total instructions: 262649 -> 262545 39/2148 programs affected (1.8%) 14253 -> 14149 instructions in affected programs (0.7% reduction)
* i965/fs: Try to avoid generating extra MOVs to do saturates.Eric Anholt2012-04-113-12/+54
| | | | | | | | | | | | This change (before the previous two) produced a .23% +/- .11% performance improvement in Unigine Tropics at 1024x768 on IVB. Total instructions: 269270 -> 262649 614/2148 programs affected (28.6%) 179386 -> 172765 instructions in affected programs (3.7% reduction) v2: Move some of the logic of finding the instruction that produced the result of an expression tree to a helper.
* i965: Stop lying about cpp and height of a stencil buffer.Paul Berry2012-04-105-45/+66
| | | | | | | | | | | | | | | | | | | | | | | When using a separate stencil buffer, i965 requires that the pitch of the buffer (in the 3DSTATE_STENCIL_BUFFER command) be specified as 2x the actual pitch. Previously this was accomplished by doubling the "cpp" and "pitch" values stored in the intel_region data structure, and halving the height. However, this was confusing, and it led to a subtle (but benign) bug: since a stencil buffer is W-tiled, its true height must be aligned to a multiple of 64; we were accidentally aligning its faux height to a multiple of 64, causing memory to be wasted. Note that for window system stencil buffers, the DDX also doubles the cpp and pitch values. To facilitate fixing this DDX server bug in the future, we fix the cpp and pitch values we receive from the X server only if cpp has the "incorrect" value of 2. Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]> v2: Clarify comments about the DDX.
* i965: Add support for sampling texture buffer objects on gen7+.Eric Anholt2012-04-094-1/+71
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add real support for texturing/rendering with MESA_FORMAT_RGBA8888_REV.Eric Anholt2012-04-091-5/+1
| | | | | | | | | | | This was hacked in in one place for EGL image stuff, but the right thing to do was just to provide the mapping from the mesa format to the native hardware format, which includes render target support. This turns out to be required for GL_ARB_texture_buffer_object, which sees data in this layout. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen7: Fix the /* ignored */ comment on constant surface setup.Eric Anholt2012-04-091-1/+1
| | | | | | | It turns out this field *is* used, and it's the stride between samples from the buffer. Discovered during TBO debugging. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove vestiges of function call support from the old VS backend.Kenneth Graunke2012-04-094-188/+0
| | | | | | | | This never worked. brwProgramStringNotify also explicitly rejects programs that use CAL and RET. So there's no need for this to exist. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i915: set SPRITE_POINT_ENABLE bit correctlyYuanhan Liu2012-04-094-12/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When SPRITE_POINT_ENABLE bit is set, the texture coord would be replaced, and this is only needed when we called something like glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, GL_TRUE). And more, we currently handle varying inputs as texture coord, we would be careful when setting this bit and set it just when needed, or you will find the value of varying input is not right and changed. Thus we do set SPRITE_POINT_ENABLE bit only when all enabled tex coord units need do CoordReplace. Or fallback is needed to make sure the rendering is right. With handling the bit setup at i915_update_sprite_point_enable(), we don't need the relative code at i915Enable then. This patch would _really_ fix the webglc point-size.html test case and of course, not regress piglit point-sprite and glean-pointSprite testcase. NOTE: This is a candidate for stable release branches. v2: fallback just when all enabled tex coord units need do CoordReplace (Eric) v3: move the sprite point validate code at I915InvalidateState (Eric) v4: sprite point enable bit update based on _NEW_PROGRAM, too add relative _NEW-state comments to show what state is being used(Eric) Signed-off-by: Yuanhan Liu <[email protected]>
* i965: Actually upload sampler state pointers for the VS unit on Gen6.Kenneth Graunke2012-04-051-1/+1
| | | | | | | | | | | | | | We already program all the sampler state correctly, we just didn't give the GPU a pointer to it for the VS stage. Thus, any texturing other than texelFetch() wouldn't work. Fixes piglit test vs-textureLod-miplevels and 99 of oglconform's glsl-bif-tex subtests. NOTE: This is a candidate for the 8.0 branch. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* glsl: Demote 'type' from ir_instruction to ir_rvalue and ir_variable.Kenneth Graunke2012-04-021-1/+1
| | | | | | | | | | | | | Variables have types, expression trees have types, but statements don't. Rather than have a nonsensical field that stays NULL in the base class, just move it to where it makes sense. Fix up a few places that lazily used ir_instruction even though they actually knew the particular subclass. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/aub: Dump a final bitmap from DestroyContext.Kenneth Graunke2012-04-023-29/+41
| | | | | | | | | | | | | | | Certain applications don't call SwapBuffers before exiting. Yet, we'd really like to see a bitmap containing the final rendered image even if they choose never to present it. In particular, Piglit tests (at least with -auto -fbo) fall into this category. Many of them failed to dump any images at all. Dumping one final image at context destruction time seems to work. We may wish to pursue a more elegant solution later. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: add PCI IDs for Ivy Bridge GT2 server variantEugeni Dodonov2012-04-012-1/+4
| | | | | | | Those IDs are used by Bromolow. Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Eugeni Dodonov <[email protected]>
* intel: Add some PCI IDs for Haswell.Kenneth Graunke2012-03-302-2/+20
| | | | | | Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eugeni Dodonov <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Set "Shader Channel Select" fields in Haswell's SURFACE_STATE.Kenneth Graunke2012-03-303-1/+37
| | | | | | | | | | | | These can be used to implement EXT_texture_swizzle without baking state-dependent swizzle instructions into the shader and forcing recompiles. For now, just set them to pass-through mode, so everything continues to work as it did on Ivybridge. We can optimize this later. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 15:46:28 +0000