summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* st/mesa: rework blit_copy_pixels to use pipe->blitMarek Olšák2013-06-131-35/+79
| | | | | | | | | | | | | | | There were 2 issues with it: - resource_copy_region doesn't allow different sample counts of both src and dst, which can occur if we blit between a window and a FBO, and the window has an MSAA colorbuffer and the FBO doesn't. (this was the main motivation for using pipe->blit) - blitting from or to a non-zero layer/slice/face was broken, because rtt_face and rtt_slice were ignored. blit_copy_pixels is now used even if the formats and orientation of framebuffers don't match. Reviewed-by: Brian Paul <[email protected]>
* gallium/util: make WRITES_ALL_CBUFS optional in the passthrough fragment shaderMarek Olšák2013-06-132-2/+4
| | | | Reviewed-by: Brian Paul <[email protected]>
* mesa: fix OES_EGL_image_external being partially allowed in the core profileMarek Olšák2013-06-134-6/+8
| | | | Reviewed-by: Chad Versace <[email protected]>
* glsl: Add gl_shader_program::UniformLocationBaseScaleIan Romanick2013-06-123-3/+21
| | | | | | | | | | | | | | | | This is used by _mesa_uniform_merge_location_offset and _mesa_uniform_split_location_offset to determine how the base and offset are packed. Previously, this value was hard coded as (1U<<16) in those functions via the shift and mask contained therein. The value is still (1U<<16), but it can be changed in the future. The next patch dynamically generates this value. NOTE: This is a candidate for stable release branches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-and-tested-by: Chad Versace <[email protected]>
* glsl: Add a gl_shader_program parameter to ↵Ian Romanick2013-06-124-5/+7
| | | | | | | | | | | | _mesa_uniform_{merge,split}_location_offset This will be used in the next commit. NOTE: This is a candidate for stable release branches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-and-tested-by: Chad Versace <[email protected]>
* i965/gen7: Enable support for fast color clears.Paul Berry2013-06-121-0/+20
| | | | | | | | | | | This patch adds code to place mcs_state into INTEL_MCS_STATE_RESOLVED for miptrees that are capable of supporting fast color clears. This will have no effect on buffers that don't undergo a fast color clear; however, for buffers that do undergo a fast color clear, an MCS miptree will be allocated (at the time of the first fast clear), and will be used thereafter. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Disable fast color clears on shared regions.Paul Berry2013-06-124-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | In certain circumstances the memory region underlying a miptree is shared with other miptrees, or with other code outside Mesa's control. This happens, for instance, when an extension like GL_OES_EGL_image or GLX_EXT_texture_from_pixmap extension is used to associate a miptree with an image existing outside of Mesa. When this happens, we need to disable fast color clears on the miptree in question, since there's no good synchronization mechanism to ensure that deferred clear writes get performed by the time the buffer is examined from the other miptree, or from outside of Mesa. Fortunately, this should not be a performance hit for most applications, since most applications that use these extensions use them for importing textures into Mesa, rather than for exporting rendered images out of Mesa. So most of the time the miptrees involved will never experience a clear. v2: Rework based on the fact that we have decided not to use an accessor function to protect access to the region. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Resolve color buffers when necessary.Paul Berry2013-06-127-3/+37
| | | | | | | | | | | | | | | | Resolve color buffers that have been fast-color cleared: 1. before texturing from the buffer (brw_predraw_resolve_buffers()) 2. before using the buffer as the source in a blorp blit (brw_blorp_blit_miptrees()) 3. before mapping the buffer's miptree (intel_miptree_map_raw(), intel_texsubimage_tiled_memcpy()) 4. before accessing the buffer using the hardware blitter (intel_miptree_blit(), do_blit_bitmap()) v2: Rework based on the fact that we have decided not to use an accessor function to protect access to the region. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Ensure that front/back buffers are fast-clear resolved.Paul Berry2013-06-123-12/+15
| | | | | | | | | | | | We already had code in intel_downsample_for_dri2_flush() for downsampling front and back buffers when multisampling was in use. This patch extends that function to perform fast color clear resolves when necessary. To account for the additional functionality, the function is renamed to simply intel_resolve_for_dri2_flush(). Reviewed-by: Eric Anholt <[email protected]>
* i965/blorp: Write blorp code to do render target resolves.Paul Berry2013-06-126-0/+96
| | | | | | | | | | | | | | | | | | | This patch implements the "render target resolve" blorp operation. This will be needed when a buffer that has experienced a fast color clear is later used for a purpose other than as a render target (texturing, glReadPixels, or swapped to the screen). It resolves any remaining deferred clear operation that was not taken care of during normal rendering. Fortunately not much work is necessary; all we need to do is scale down the size of the rectangle primitive being emitted, run the fragment shader with the "Render Target Resolve Enable" bit set, and ensure that the fragment shader writes to the render target using the "replicated color" message. We already have a fragment shader that does that (the shader that we use for fast color clears), so for simplicity we re-use it. Reviewed-by: Eric Anholt <[email protected]>
* i965/blorp: Expand clear class hierarchy to prepare for RT resolves.Paul Berry2013-06-122-25/+35
| | | | | | | | | | | | | | The fragment shaders that to do color clears will be re-used to perform so-called "render target resolves" (the resolves associated with fast color clears). To prepare for that, this patch expands the class hierarchy for blorp params by adding brw_blorp_const_color_params (which will be used for all blorp operations where the fragment shader outputs a constant color). Some other data structures and functions were also renamed to use "const_color" nomenclature where appropriate. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Implement fast color clear operation in BLORP.Paul Berry2013-06-129-14/+240
| | | | | | | | | | | | | | | | | | Since we defer allocation of the MCS miptree until the time of the fast clear operation, this patch also implements creation of the MCS miptree. In addition, this patch adds the field intel_mipmap_tree::fast_clear_color_value, which holds the most recent fast color clear value, if any. We use it to set the SURFACE_STATE's clear color for render targets. v2: Flag BRW_NEW_SURFACES when allocating the MCS miptree. Generate a perf_debug message if clearing to a color that isn't compatible with fast color clear. Fix "control reaches end of non-void function" build warning. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Create helper functions for single-sample MCS buffers.Paul Berry2013-06-122-0/+128
| | | | Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Set up MCS in SURFACE_STATE whenever MCS is present.Paul Berry2013-06-123-5/+7
| | | | | | | | | | | | | | | On Gen7+, MCS buffers are used both for compressed multisampled color buffers and for "fast clear" of single-sampled color buffers. Previous to this patch series, we didn't support fast clear, so we only used MCS with multisampled bolor buffers. As a first step to implementing fast clears, this patch modifies the code that sets up SURFACE_STATE so that it configures the MCS buffer whenever it is present, regardless of whether we are multisampling or not. Reviewed-by: Eric Anholt <[email protected]>
* i965/gen7+: Create an enum for keeping track of fast color clear state.Paul Berry2013-06-126-0/+104
| | | | | | | | | | | | | This patch includes code to update the fast color clear state appropriately when rendering occurs. The state will also need to be updated when a fast clear or a resolve operation is performed; those state updates will be added when the fast clear and resolve operations are added. v2: Create a new function, intel_miptree_used_for_rendering() to handle updating the fast color clear state when rendering occurs. Reviewed-by: Eric Anholt <[email protected]>
* intel: Conditionally compile mcs-related code for i965 only.Paul Berry2013-06-122-1/+9
| | | | | | | | | This patch ifdefs out intel_mipmap_tree::mcs_mt when building the i915 (pre-Gen4) driver (MCS buffers aren't supported until Gen7, so there is no need for this field in the i915 driver). This should make it a bit easier to implement fast color clears without undue risk to i915. Reviewed-by: Eric Anholt <[email protected]>
* intel: Keep region name in intel_miptree_create_for_dri2_buffer().Paul Berry2013-06-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | When processing a buffer received from the X server, intel_process_dri2_buffer() examines intel_region::name to determine whether it's received a brand new buffer, or the same buffer it received from the X server the last time it made a request. However, this didn't work properly, because in the call to intel_miptree_create_for_dri2_buffer(), we create a fresh intel_region object to represent the buffer, and this was causing us to forget the buffer's previous name. This patch fixes things by copying over the region name when creating the fresh intel_region object. At the moment, this is just a minor performance optimization. However, when fast color clears are added, it will be necessary to ensure that the fast color clear state for a buffer doesn't get discarded the next time we receive that buffer from the X server. Reviewed-by: Eric Anholt <[email protected]>
* i965: Emit the depth/stencil state pointer directly, not via atoms.Kenneth Graunke2013-06-117-80/+18
| | | | | | | | | | | | | | | | | | | | | See two commits ago for the rationale. This allows us to delete the whole gen7_cc_state.c file. This does move these commands before the depth stall flushes from brw_emit_depthbuffer, which may be a problem. The documentation for 3DSTATE_DEPTH_BUFFER mentions that depth stall flushes are required before changing any depth/stencil buffer state, but explicitly lists 3DSTATE_DEPTH_BUFFER, 3DSTATE_HIER_DEPTH_BUFFER, 3DSTATE_STENCIL_BUFFER, and 3DSTATE_CLEAR_PARAMS. It does not mention this particular packet (_3DSTATE_DEPTH_STENCIL_STATE_POINTERS). No observed Piglit regressions on Sandybridge or Ivybridge. Together with the last two commits, this makes a cairo-gl benchmark faster by 0.324552% +/- 0.258355% on Ivybridge. No statistically significant change on Sandybridge. (Thanks to Eric for the numbers.) Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Emit the CC state pointer directly rather than via atoms.Kenneth Graunke2013-06-115-30/+18
| | | | | | See the previous commit for the rationale. Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Emit the BLEND_STATE pointer directly rather than via atoms.Kenneth Graunke2013-06-115-30/+18
| | | | | | | | | | | | | | | | | | | | | | | | Previously, we would: 1. Emit the new indirect state. 2. Flag CACHE_NEW_BLEND_STATE. 3. Rely on later state atoms to notice CACHE_NEW_BLEND_STATE and emit a pointer to the new indirect state. This is rather cumbersome: it requires two state atoms instead of one, and there's a strict ordering dependency in the list. Plus, the code gets spread across two functions (or even files in the case of Gen7+). Gen7+ has a packet to update just the blend state pointer, so it makes a lot of sense to simply emit that right away. Gen6 has a combined packet which updates blending, the color calculator, and depth/stencil state; however, each can still be modified independently. This drops the Gen6 micro-optimization where we tried to only emit one packet that changed all three states. State updates are pretty cheap. CACHE_NEW_BLEND_STATE is no longer necessary, so drop it. Signed-off-by: Kenneth Graunke <[email protected]>
* Revert "i965: Disable unused pipeline stages once at startup on Gen7+."Kenneth Graunke2013-06-113-6/+13
| | | | | | | | | | This reverts commit 6c966ccf07bcaf64fba1a9b699440c30dc96e732. Apparently causes GPU hangs. Conflicts: src/mesa/drivers/dri/i965/brw_state.h src/mesa/drivers/dri/i965/brw_state_upload.c
* swrast: add texfetch code for some XBGR formatsBrian Paul2013-06-112-9/+46
| | | | | | | | | | Fixes piglit texture-packed-formats regression. We need to implement more XBGR formats here eventually, but many are UINT/SINT formats which swrast doesn't handle yet anyway (integer textures). Bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=64935 Reviewed-by: Jose Fonseca <[email protected]>
* mesa: add missing texture strings in tex_target_name()Brian Paul2013-06-101-0/+5
| | | | And add a static assert for the future.
* mesa: Add a _mesa_problem to document a piglit failure on i965.Eric Anholt2013-06-101-0/+6
| | | | | | | | | Having figured out what was going on with piglit fbo-depth copypixels GL_DEPTH_COMPONENT32F (falling all the way back to swrast on CopyPixels to a float depth buffer), I'm not inclined to fix the problem currently but it seems worth saving someone else the debug time. Reviewed-by: Matt Turner <[email protected]>
* i965/vs: Avoid the MUL/MACH/MOV sequence for small integer multiplies.Eric Anholt2013-06-101-13/+37
| | | | | | | | | | | | | | | We do a lot of multiplies by 3 or 4 for skinning shaders, and we can avoid the sequence if we just move them into the right argument of the MUL. On pre-IVB, this means reliably putting a constant in a position where it can't be constant folded, but that's still better than MUL/MACH/MOV. Improves GLB 2.7 trex performance by 0.788648% +/- 0.23865% (n=29/30) v2: Fix test for pre-sandybridge. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> (v1)
* i965/vs: Allow copy propagation into MUL/MACH.Eric Anholt2013-06-101-2/+4
| | | | | | | | | | | This is a trivial port of 1d6ead38042cc0d1e667d8ff55937c1e32d108b1 from the FS. No significant performance difference on trex (misplaced the data, but it was about n=20). Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vs: Use the MAD instruction when possible.Eric Anholt2013-06-104-0/+43
| | | | | | | | | | | | | | This is different from how we do it in the FS - we are using MAD even when some of the args are constants, because with the relatively unrestrained ability to schedule a MOV to prepare a temporary with that data, we can get lower latency for the sequence of instructions. No significant performance difference on GLB2.7 trex (n=33/34), though it doesn't have that many MADs. I noticed MAD opportunities while reading the code for the DOTA2 bug. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* intel: Reserve less batchbuffer space.Kenneth Graunke2013-06-101-4/+3
| | | | | | | | | | | | | | | Now that Gen6+ relies on hardware contexts, we don't need to record an occlusion query value at the end of each batch. That means we no longer need to reserve space for the absurd number of PIPE_CONTROLs required to do that on Sandybridge. See commit 4e087de51ad0e7ba4a7199d3664e1d096f8dc510, which bumped this up to 60 bytes. This is not quite a revert, as it uses 24 bytes instead of 16, and saves the comments. As far as I can tell, the old value of 16 bytes was just wrong, so we shouldn't go back to that. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Allocate push constant L3 space once at startup on Gen7+.Kenneth Graunke2013-06-104-12/+4
| | | | | | | | | | | We always allocate the maximum amount of space and never change it, so it makes sense to do it once. Programming it on startup also lets us skip re-programming it from BLORP. This removes a tiny amount of overhead from our drawing loop. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Disable unused pipeline stages once at startup on Gen7+.Kenneth Graunke2013-06-103-13/+9
| | | | | | | This removes a tiny bit of code from our drawing loop. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Don't emit PIPELINE_SELECT from BLORP.Kenneth Graunke2013-06-101-19/+0
| | | | | | | | | | | Now that we emit invariant state at startup (and never select the media pipeline), the 3D pipeline will always already be selected, even if BLORP is the first operation. So this is unnecessary. v2: Fix unused variable warning (intel_context is no longer used). Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Emit invariant state once at startup on Gen6+.Kenneth Graunke2013-06-103-4/+20
| | | | | | | | | | | Now that we have hardware contexts, we can safely initialize our GPU state once at startup, rather than needing a state atom with the BRW_NEW_CONTEXT flag set. This removes a tiny bit of code from our drawing loop. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Delete some dead state atom prototypes.Kenneth Graunke2013-06-101-9/+0
| | | | | | | These atoms don't actually exist. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Change return type of check_state() to bool.Kenneth Graunke2013-06-101-2/+2
| | | | | | | The existing code already returned a boolean; this just clarifies that. Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Remove unused second parameter of brw_print_dirty_count().Kenneth Graunke2013-06-101-4/+4
| | | | | Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* dlist: fix save_SamplerParameteriChris Forbes2013-06-091-1/+1
| | | | | | | | | | This was building the temporary array to pass to save_SamplerParameteriv, and then not passing it. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Vinson Lee <[email protected]> Signed-off-by: Vinson Lee <[email protected]>
* mesa: Prevent possible out-of-bounds read by save_SamplerParameteriv.Vinson Lee2013-06-081-1/+4
| | | | | | | Fixes "Out-of-bounds access" defect reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Report core FBO incompleteness cases through GL_ARB_debug_output.Eric Anholt2013-06-071-18/+25
| | | | | | | | | | | | | Just like we produce from inside the Intel driver, this can help provide information quickly about FBO incompatibility problems (particularly when using apitrace replay). Currently, in driver-marked incompleteness cases, you'll get both the driver message and the core message on Intel. Until the other drivers are fixed to produce output, I think this is better than not putting in a message for driver-marked incomplete. Reviewed-by: Brian Paul <[email protected]>
* intel: flush fake front buffer if server is about to destroy it.Paul Berry2013-06-071-0/+9
| | | | | | Fixes piglit test "spec/!OpenGL 1.0/gl-1.0-front-invalidate-back" Reviewed-by: Anuj Phogat <[email protected]>
* intel: flush fake front buffer more robustly.Paul Berry2013-06-071-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | When a fake front buffer is in use, if we request the front buffer (using screen->dri2.loader->getBuffersWithFormat()), the X server copies the real front buffer to the fake front buffer and returns the fake front buffer. We sometimes make redundant requests for the front buffer (due to using a single counter to track invalidates for both the front and back buffers), so there's a danger of pending front buffer rendering getting overwritten when the redundant front buffer request occurs. Previous to this patch, intel_update_renderbuffers() worked around that problem by sometimes doing intel_flush() and intel_flush_front() before calling intel_query_dri2_buffers(). But it only did the workaround when the front buffer was bound for drawing; it didn't do it when the front buffer was bound for reading. This patch moves the workaround code to intel_query_dri2_buffers(), so that it happens in exactly the circumstances where it is needed. This should fix some of the sporadic failures in Piglit tests fbo-sys-blit and fbo-sys-sub-blit. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* intel: make intel_flush_front safe to call during initial MakeCurrentPaul Berry2013-06-071-1/+1
| | | | | | | | | | | | | | The patch that follows will fix a bug that prevents intel_flush_front() from being called often enough. In doing so, it will create a situation where intel_flush_front() is called during the initial call to glXMakeCurrent(). In this circumstance, ctx->DrawBuffer hasn't been initialized yet and is NULL. Fortunately, intel->front_buffer_dirty is false, so intel_flush_front() doesn't actually need to do anything. To avoid a segfault, swap the order of terms in intel_flush_front()'s if statement. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* mesa: Expose MAX_FRAGMENT_INPUT_COMPONENTS on ES3 and desktop 3.2.Eric Anholt2013-06-072-0/+10
| | | | | | | | | piglit OpenGL ES 3.0/minmax now passes. This was also one of the subcase failures in OpenGL 3.2/minmax (and still is, because our value is too low for 3.2, but at least we report what it is). Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Expose texture array getters on GLES3.Eric Anholt2013-06-072-2/+10
| | | | | | | | | Part of fixing piglit OpenGL ES 3.0/minmax. v2: s/_gles3/_es3/ in extra name, for consistency (review by Matt). Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* mesa: Fix the return value of TEXTURE_BINDING_2D_ARRAY.Eric Anholt2013-06-071-1/+1
| | | | | | | Noticed by inspection when reviewing the next commit. Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Expose texel offset limits in GLES3.Eric Anholt2013-06-072-5/+6
| | | | | | | | | Part of fixing piglit OpenGL ES 3.0/minmax. v2: s/_gles3/_es3/ in extra name, for consistency (review by Matt). Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* gallium: Remove draw_arrays() and draw_arrays_instanced() functionsArnas Milasevicius2013-06-071-0/+22
| | | | | | | | Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced(). draw_arrays() was used by nobody else. Now there's just one "draw" entrypoint into the draw module. Signed-off-by: Brian Paul <[email protected]>
* i965/vs: add support for emitting gl_ClipVertexChris Forbes2013-06-072-7/+3
| | | | | | | | | | | Removes the special-case suppression of gl_ClipVertex in the VUE map. Also calculate vertex outcodes for user clip planes based on gl_ClipVertex if written; otherwise gl_Position. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/clip: Add support for gl_ClipVertexChris Forbes2013-06-073-4/+55
| | | | | | | | | | | When clipping triangles against a user clip plane, and gl_ClipVertex is provided in the vertex, use it instead of hpos. TODO: A similar change should be made at some point for line clipping. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Fix uniform buffer object counting.Eric Anholt2013-06-061-1/+9
| | | | | | | | | | | | | | | | | | | | We were counting uniforms located in UBOs against the default uniform block limit, while not doing any counting against the specific combined limit. Note that I couldn't quite find justification for the way I did this, but I think it's the only sensible thing: The spec talks about components, so each "float" in a std140 block would count as 1 component and a "vec4" would count as 4, though they occupy the same amount of space. Since GPU limits on uniform buffer loads are surely going to be about the size of the blocks, I just counted them that way. Fixes link failures in piglit arb_uniform_buffer_object/maxuniformblocksize when ported to geometry shaders on Paul's GS branch, since in that case the max block size is bigger than the default uniform block component limit. Reviewed-by: Ian Romanick <[email protected]>
* intel: Use the CHIPSET macro in the PCI ID tables for the device name.Kenneth Graunke2013-06-061-184/+4
| | | | | | | | | | | | | Putting the human readable device names directly in the PCI ID list consolidates things in one place. It also makes it easy to customize the name on a per-PCI ID basis without a huge code explosion. Based on a patch by Kristian Høgsberg. v2: Fix 830M/845G names and #undef CHIPSET (caught by Emit Velikov). 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-03 08:42:38 +0000