summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/gen7_misc_state.c
Commit message (Collapse)AuthorAgeFilesLines
* i965: Track that the stencil data was updated when renderingJordan Justen2016-08-261-0/+1
| | | | | | Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
* i965: Assert that a depth_mt exists when using HiZ.Matt Turner2016-05-251-0/+1
| | | | | Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
* i965: Make all atoms to track BRW_NEW_BLORP by defaultKenneth Graunke2016-04-231-1/+2
| | | | Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com
* i965: Rename intel_emit* to reflect their new location in brw_pipe_controlChris Wilson2015-06-241-1/+1
| | | | | Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965/gen7: Don't rely directly on the hiz miptree structureJordan Justen2015-03-091-3/+4
| | | | | | | | | | | We are still allocating a miptree for hiz, but we only use fields from intel_miptree_aux_buffer. This will allow us to switch over to not allocating a miptree. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
* i965/hiz: Start to separate miptree out from hiz buffersJordan Justen2015-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Today we allocate a miptree's for the hiz buffer. We needed this in the past because we would point the hardware at offsets of the hiz buffer. Since the hiz format is not documented, this is not a good idea. Since moving to support layered rendering on Gen7+, we no longer point at an offset into the buffer on Gen7+. Therefore, to support hiz on Gen7+, we don't need a full miptree structure allocated. This patch starts to create a new auxiliary buffer structure (intel_miptree_aux_buffer) that can be a more simplistic miptree side-band buffer associated with a miptree. (For example, to serve the needs of the hiz buffer.) Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
* i965: Delete brw_state_flags::cache and related code.Kenneth Graunke2014-12-021-1/+0
| | | | | | | | | It's been merged into brw_state_flags::brw for simplicity and efficiency. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965: Alphabetize brw_tracked_state flags and use a consistent style.Kenneth Graunke2014-11-291-1/+3
| | | | | | | | | | | | | | | | Most of the dirty flags were listed in some arbitrary order. Some used bonus parenthesis. Some put multiple flags on one line, others put one per line. Some used tabs instead of spaces...but only on some lines. This patch settles on one flag per line, in alphabetical order, using spaces instead of tabs, and sheds the unnecessary parentheses. Sorting was mostly done with vim's visual block feature and !sort, although I alphabetized short lists by hand; it was pretty manual. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Matt Turner <mattst88@gmail.com>
* i965/gen7 depth: Set depth size based on LOD0 for 3D texturesJordan Justen2014-05-131-2/+2
| | | | | Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
* i965/Gen7: Set up layer constraints properly for depth buffersChris Forbes2014-05-091-9/+6
| | | | | | | | | | | | | | | Again, a few problems: - Layered attachments did not honor MinLayer. - Non-layered MSAA attachments rendered to the wrong layer due to dividing by the layer count. All depth buffers use the IMS layout, so the physical layer count == logical layer count. - Layered attachments were not limited to irb->layer_count, so we could render off the end of the texture. V2: Restore the MAX2() to account for zero depth/layer_count. Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Delete the intel_regions.c code.Eric Anholt2014-05-011-1/+0
| | | | | Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* i965: Drop use of intel_region from miptrees.Eric Anholt2014-05-011-6/+6
| | | | | | | | | | | | Note: region->width/height used to reflect the total_width/height padding of separate stencil, though mt->total_width didn't. region->width/height was being used in EGL images, where the padded value would have been the wrong one, so I converted them to use rb->Width/Height. v2: Drop debug printf that slipped in (caught by Ken) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* i965/gen7: Skip repeated NULL depth/stencil state emits.Eric Anholt2014-04-111-0/+8
| | | | | | Improves cairo performance on glamor by 2.87752% +/- 0.966977 (n=57). Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
* i965: Fix clears of layered framebuffers with mismatched layer counts.Paul Berry2014-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, Mesa enforced the following rule (from ARB_geometry_shader4's list of criteria for framebuffer completeness): * If any framebuffer attachment is layered, all attachments must have the same layer count. For three-dimensional textures, the layer count is the depth of the attached volume. For cube map textures, the layer count is always six. For one- and two-dimensional array textures, the layer count is simply the number of layers in the array texture. { FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB } However, when ARB_geometry_shader4 was adopted into GL 3.2, this rule was dropped; GL 3.2 permits different attachments to have different layer counts. This patch brings Mesa in line with GL 3.2. In order to ensure that layered clears properly clear all layers, we now have to keep track of the maximum number of layers in a layered framebuffer. Fixes the following piglit tests in spec/!OpenGL 3.2/layered-rendering: - clear-color-all-types 1d_array mipmapped - clear-color-all-types 1d_array single_level - clear-color-mismatched-layer-count - framebuffer-layer-count-mismatch Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
* mesa: Track number of layers in layered framebuffers.Paul Berry2013-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | In order to properly clear layered framebuffers, we need to know how many layers they have. The easiest way to do this is to record it in the gl_framebuffer struct when we check framebuffer completeness. This patch replaces the gl_framebuffer::Layered boolean with a gl_framebuffer::NumLayers integer, which is 0 if the framebuffer is not layered, and equal to the number of layers otherwise. v2: Remove gl_framebuffer::Layered and make gl_framebuffer::NumLayers always have a defined value. Fix factor of 6 error in the number of layers in a cube map array. Cc: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Chris Forbes <chrisf@ijw.co.nz> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
* gen7: Use logical, not physical, dims in 3DSTATE_DEPTH_BUFFER (v2)Chad Versace2013-10-071-2/+2
| | | | | | | | | | | | | | | | | In 3DSTATE_DEPTH_BUFFER, we set Width and Height to the miptree slice's physical dimensions. (Logical and physical dimensions may differ for multisample surfaces). However, in SURFACE_STATE, we always set Width and Height to the slice's logical dimensions. We should do the same for 3DSTATE_DEPTH_BUFFER, because the hw docs say so. No Piglit regressions (-x glx -x glean) on Ivybridge with Wayland. v2: No Piglit regressions, for real this time. Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
* i965/gen7: Set MOCS L3 cacheability for IVB/BYT (v2)Ville Syrjälä2013-08-211-1/+1
| | | | | | | | | | | | | | | | IVB/BYT also has the same L3 cacheability control in MOCS as HSW, so let's make use of it. pts/xonotic and pts/reaction @ 1920x1080 gain ~4% on my IVB GT2. Most other things show less gains/no regressions, except furmark which loses some 10 points. I didn't have a BYT at hand for testing. v2: Don't check (brw->gen == 7) in gen7 functions. (chadv) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* gen7 depth surface: program 3DSTATE_DEPTH_BUFFER to top of surfaceJordan Justen2013-08-041-8/+28
| | | | | | | | | | | | | | | | | | | | | Previously we would always find the 2D sub-surface of interest, and then program the surface to this location. Now we always program the 3DSTATE_DEPTH_BUFFER at the start of the surface. To select the lod/slice, we utilize the lod & minimum array element fields. As part of this change, we must revert 1f112ccf: Revert "i965/gen7: Align all depth miplevels to 8 in the X direction." We also must disable brw_workaround_depthstencil_alignment for gen >= 7. Now the hardware will handle alignment when rendering to additional slices/LODs. v2: * Merge with recent MOCS changes Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* gen7 depth surface: calculate minimum array element being renderedJordan Justen2013-08-041-0/+10
| | | | | | | | In layered rendering this will be 0. Otherwise it will be the selected slice. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* gen7 depth surface: calculate LOD being rendered toJordan Justen2013-08-041-0/+3
| | | | | | | This will be used in 3DSTATE_DEPTH_BUFFER in a later patch. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* gen7 depth surface: calculate depth (array size) for depth surfaceJordan Justen2013-08-041-0/+3
| | | | | | | | | | This will be used in 3DSTATE_DEPTH_BUFFER in a later patch. Note: Cube maps are treated as 2D arrays with 6 times as many array elements as the cube map array would have. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* gen7 depth surface: calculate more specific surface typeJordan Justen2013-08-041-0/+31
| | | | | | | | | | This will be used in 3DSTATE_DEPTH_BUFFER in a later patch. Note: Cube maps are treated as 2D arrays with 6 times as many array elements as the cube map array would have. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* i965/hsw: Change L3 MOCS for depth, hiz, and stencilChad Versace2013-07-181-2/+5
| | | | | | | | Change from "not cacheable" to "cacheable" in L3. Do so for the draw upload path and blorp. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
* i965: Cite the Sandybridge PRM for Gen7 stencil pitch requirements.Kenneth Graunke2013-07-151-9/+5
| | | | | | | | Sadly, the Ivybridge PRM can't be cited, as it is missing the relevant text for some reason. However, the Sandybridge PRM has the text Chad originally quoted, and the modern BSpec has the same text. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Delete intel_context entirely.Kenneth Graunke2013-07-091-2/+1
| | | | | | | | | | This makes brw_context inherit directly from gl_context; that was the only thing left in intel_context. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Move intel_context::is_<platform> flags to brw_context.Kenneth Graunke2013-07-091-1/+1
| | | | | | | Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Pass brw_context to functions rather than intel_context.Kenneth Graunke2013-07-091-1/+1
| | | | | | | | | | | | | | This makes brw_context available in every function that used intel_context. This makes it possible to start migrating fields from intel_context to brw_context. Surprisingly, this actually removes some code, as functions that use OUT_BATCH don't need to declare "intel"; they just use "brw." Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Chris Forbes <chrisf@ijw.co.nz> Acked-by: Paul Berry <stereotype441@gmail.com> Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
* i965: Remove _NEW_DEPTH state flagging on drawbuffers change.Eric Anholt2013-06-251-1/+1
| | | | | | | | Of the places noting a _NEW_DEPTH dependency, all were already checking for _NEW_BUFFERS if appropriate. Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* intel: Replace checks for hiz_mt with intel_has*hiz()Chad Versace2013-04-101-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When appropriate, replace each check `hiz_mt != NULL` with either a call to intel_miptree_slice_has_hiz() or intel_renderbuffer_has_hiz(). No behavioral change. This prepares for selectively enabling hiz on individual miptree slices for Haswell. This refactoring had several side effects. 1. To prevent new warnings about discarding the const qualifier, I removed 'const' from some variable declarations in intel_validate_framebuffer(). The alternative was to add const qualifiers to multiple function signatures in the intel_renderbuffer_has_hiz call graph. Since the dominant convention in the Intel code is to not qualify function parameters as const, I chose to remove rather than add const qualifiers. 2. I changed the signature of brw_emit_depth_stencil_hiz() by replacing `struct intel_mipmap_tree *hiz_mt` with `bool hiz`. The function used hiz_mt mostly as a boolean indicator of the presence of hiz, so the signature change is consistent with the patch's goal. Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
* i965: Fix stencil write enable flag in 3DSTATE_DEPTH_BUFFER on Gen7+.Kenneth Graunke2013-04-041-1/+1
| | | | | | | | | | | | ctx->Stencil.WriteMask is a statically sized array of 3 elements. Checking it against 0 actually is a NULL check, and can never fail, which meant that we always said stencil writes were enabled. Use the new core Mesa derived state flag to fix this. NOTE: This is a candidate for stable branches. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Paul Berry <stereotype441@gmail.com>
* i965: Reduce code duplication in handling of depth, stencil, and HiZ.Paul Berry2013-04-021-62/+31
| | | | | | | | | | | | | | | | | | | | | | | | | This patch consolidates duplicate code in the brw_depthbuffer and gen7_depthbuffer state atoms. Previously, these state atoms contained 5 chunks of code for emitting the _3DSTATE_DEPTH_BUFFER packet (3 for Gen4-6 and 2 for Gen7). Also a lot of logic for determining the appropriate buffer setup was duplicated between the Gen4-6 and Gen7 functions. This refactor splits the code into three separate functions: brw_emit_depthbuffer(), which determines the appropriate buffer setup in a mostly generation-independent way, brw_emit_depth_stencil_hiz(), which emits the appropriate state packets for Gen4-6, and gen7_emit_depth_stencil_hiz(), which emits the appropriate state packets for Gen7. Tested using Piglit on Gen5-7 (no regressions). v2: Re-word some comments. Fix an assertion that incorrectly prohibited packed depth/stencil formats on Gen6 (these are allowed provided that HiZ is disabled). Reviewed-by: Chad Versace <chad.versace@linux.intel.com> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* intel: Make intel_region's pitch be bytes instead of pixels.Eric Anholt2013-01-181-3/+3
| | | | | | | | | | | | We almost never want a stride in pixels -- if you're doing anything with a stride, you're specifying an offset or incrementing a pointer, and in both cases you had to multiply by cpp to get the bytes value you wanted. But worse, on the way to creating a region from a new tiled BO, we divided by cpp to get pitch in pixels, and for an RGB32 buffer (an upcoming change) the pitch wouldn't divide exactly, and we'd end up with a wrong stride in our region. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Move all the depth/stencil/hiz offset logic into the workaround.Eric Anholt2012-11-191-79/+11
| | | | | | | | | | Given that we have the mask information here (assuming the rebase is to the same tiling, which is safe), we can just save a set of miptrees and offsets and the global intra-tile offset in the context and cut out a bunch of logic. This will also save emitting the next fix I need to do twice. Acked-by: Chad Versace <chad.versace@linux.intel.com>
* i965: Fix rendering to small mipmaps of depth/stencil buffers using a temp mt.Eric Anholt2012-10-161-60/+40
| | | | | | | Fixes 51 piglit tests (fbo-clear-formats, and most of the remaining failures in depthstencil). Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Share the draw x/y offset masking code between main/blorp and all gens.Eric Anholt2012-10-161-36/+5
| | | | | | | | | | This code is twisty, and the comment before most of the blocks was actually giving me the opposite impression from its intention: We want to apply as much of our offset as possible through coarse tile-aligned adjustment, since we can do so independently per buffer, and apply the minimum we can through fine-grained drawing offset x/y, since it has to agree between all buffers. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
* intel: Add map_stencil_as_y_tiled to intel_region_get_aligned_offset.Paul Berry2012-09-121-2/+4
| | | | | | | | | | This patch modifies intel_region_get_aligned_offset() to make the appropriate calculation when the blorp engine sets up a W-tiled stencil buffer using a Y-tiled SURFACE_STATE. NOTE: This is a candidate for stable release branches. Acked-by: Eric Anholt <eric@anholt.net>
* intel: Add map_stencil_as_y_tiled to intel_region_get_tile_masks.Paul Berry2012-09-121-2/+3
| | | | | | | | | | | When the blorp engine is performing a blit from one stencil buffer to another, it sets up the surface state for these buffers as Y-tiled, so it needs to be able to force intel_region_get_tile_masks() to return the appropriate masks for a Y-tiled region. NOTE: This is a candidate for stable release branches. Acked-by: Eric Anholt <eric@anholt.net>
* i965/gen6+: Add support for fast depth clears.Eric Anholt2012-05-231-2/+2
| | | | | | | | | | 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 <ian.d.romanick@intel.com> Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
* i965/gen7: Set tile_x/y to 0 in the no-stencil case.Eric Anholt2012-05-141-1/+1
| | | | Fixes compiler warnings.
* i965/Gen7: Work around GPU hangs due to misaligned depth coordinate offsets.Paul Berry2012-05-071-0/+36
| | | | | | | | | | | | | | | | | | | | 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 <chad.versace@linux.intel.com>
* i965: Fix mipmap offsets for HiZ and separate stencil buffers.Paul Berry2012-05-071-7/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <chad.versace@linux.intel.com> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
* i965: Stop lying about cpp and height of a stencil buffer.Paul Berry2012-04-101-1/+15
| | | | | | | | | | | | | | | | | | | | | | | 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 <kenneth@whitecape.org> Reviewed-by: Chad Versace <chad.versace@linux.intel.com> v2: Clarify comments about the DDX.
* i965: Set "Stencil Buffer Enable" bit on Haswell.Kenneth Graunke2012-03-301-1/+4
| | | | | Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net>
* intel: derive intel_renderbuffer from swrast_renderbufferBrian Paul2012-01-241-4/+4
| | | | Drivers that rely on swrast need to do this, as with swrast_texture_image.
* i965/gen7: Fix depth buffer rendering to tile offsets.Eric Anholt2012-01-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, we were saying that everything from the starting tile to region width+height was part of the limits of our depthbuffer, even if the tile was near the bottom of the depthbuffer. This mean that our range was not clipping to buffer buonds if the start tile was anything but the start of the buffer. In bebc91f0f3a1f2d19d36a7f1a4f7c992ace064e9, this was changed to saying that we're just rendering to a region of the size of the renderbuffer. This is great -- we get a range that should actually match what we want. However, the hardware's range checking occurs after the X/Y offset addition, so we were clipping out rendering to small depth mip levels when an X/Y offset was present. Just add tile_x/y to the width in that case -- the WM won't produce negative x/y values pre-offset, so we just need to get the left/bottom sides of the region to cover our buffer. Fixes the following Piglit regressions on gen7: spec/ARB_depth_buffer_float/fbo-clear-formats spec/ARB_depth_texture/fbo-clear-formats spec/EXT_packed_depth_stencil/fbo-clear-formats NOTE: This is a candidate for the 8.0 branch.
* i965: Fix compiler warnings from hiz changes.Eric Anholt2012-01-101-2/+0
|
* i965/gen7: Fix batch length for 3DSTATE_HIER_DEPTH_BUFFERChad Versace2012-01-101-2/+2
| | | | | | Change from 5 to 3. Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
* i965/gen7: Enable HiZChad Versace2012-01-101-8/+23
| | | | | | | | | | | | | | | | This patch modifies all batches needed for HiZ. The batch length for 3DSTATE_HIER_DEPTH_BUFFER is also corrected from 4 to 3. Performance +6.7% on Citybench. num-frames: 400 resolution: 1918x1031 avg-hiz-off: 127.90 fps avg-hiz-on: 136.50 fps kernel: git://people.freedesktop.org/~anholt/linux.git branch=gen7-reset-sol sha=23360e4 Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
* i965: Replace references to stencil region size with buffer sizeChad Versace2012-01-101-2/+4
| | | | | | | | | | | | | | | | | It is unwise to use a stencil region's size to determine its renderbuffer's size, because at region creation we fudge the width and height to accomodate interleaved rows. (See the comment for MESA_FORMAT_S8 in intel_miptree_create()). Most users of stencil_region->{width,height} should be converted to use stencil_rb->{Width,Height}. We have already done the replacement in several locations. This patch continues the replacement in {brw,gen7}_emit_depthbuffer(). To make those functions look consistent, I've also done the equivalent replacement for the depth buffer. Acked-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
* i965: Properly demote the depth mt format for fake packed depth/stencil.Eric Anholt2011-12-191-0/+1
| | | | | | | | | | | gen7 only supports the non-packed formats, even if you associate a real separate stencil buffer -- otherwise it's as if the depth test always fails. This requires a little bit of care in the match_texture_image case, since the miptree format no longer matches the texture image format. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
generated by cgit v1.1 at 2024-05-29 05:41:46 +0000