summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* broadcom/vc5: Add an assert about GFXH-1559.Eric Anholt2018-04-261-0/+9
| | | | | Our TF outputs always start at 6 or 7 currently, so we don't hit the broken 8 case. Let's make sure that doesn't change somehow.
* broadcom/vc5: Add validation that we don't violate GFXH-1633 requirements.Eric Anholt2018-04-261-0/+13
| | | | We don't use ldunifa yet, but we will eventually for UBOs.
* broadcom/vc5: Add validation that we don't violate GFXH-1625 requirements.Eric Anholt2018-04-261-0/+5
| | | | We don't use TMUWT yet, but we will once we do SSBOs.
* broadcom/vc5: Implement GFXH-1742 workaround (emit 2 dummy stores on 4.x).Eric Anholt2018-04-261-8/+27
| | | | | | This should fix help with intermittent GPU hangs in tests switching formats while rendering small frames. Unfortunately, it didn't help with the tests I'm having troubles with.
* broadcom/vc5: Add QPU validation for register writes after thrend.Eric Anholt2018-04-261-3/+31
| | | | | | | The next shader gets to start writing the register file during these slots, so make sure we don't stomp over them. The only case of hitting this that I could imagine would be dead writes.
* st: Choose a 2101010 format for GL_RGB/GL_RGBA with a 2_10_10_10 type.Eric Anholt2018-04-261-0/+13
| | | | | | | | | | | | GLES's GL_EXT_texture_type_2_10_10_10_REV allows uploading this type to an unsized internalformat, and it should be non-color-renderable. fbobject.c's implementation of the check for color-renderable is checks that the texture has a 2101010 mesa format, so make sure that we have chosen a 2101010 format so that check can do what it meant to. Fixes KHR-GLES3.packed_pixels.pbo_rectangle.rgb on vc5. Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: fix missing setting of _ElementSize in new_draw_rasterpos_stageCharmaine Lee2018-04-261-0/+5
| | | | | | | | | With this patch, _ElementSize is initialized along with the rest of the vertex array attributes in new_draw_rasterpos_stage(). This fixes a crash in st_pipe_vertex_format() when running topogun-1.06-orc-84k-resize trace file with VMware svga driver. Reviewed-by: Brian Paul <[email protected]>
* st/va: Fix typosDrew Davenport2018-04-261-24/+24
| | | | | | | | | s/attibute/attribute/ s/suface/surface/ v2: rebased(Leo) Reviewed-by: Leo Liu <[email protected]>
* st/va: Fix potential buffer overreadDrew Davenport2018-04-261-1/+1
| | | | | | | | VASurfaceAttribExternalBuffers.pitches is indexed by plane. Current implementation only supports single plane layout. Reviewed-by: Kristian H. Kristensen <[email protected]> Reviewed-by: Leo Liu <[email protected]>
* radeon/vcn: fix mpeg4 msg buffer settingsBoyuan Zhang2018-04-261-9/+9
| | | | | | | | Previous bit-fields assignments are incorrect and will result certain mpeg4 decode failed due to wrong flag values. This patch fixes these assignments. Signed-off-by: Boyuan Zhang <[email protected]> Reviewed-by: Leo Liu <[email protected]>
* radeon: Drop broken front_buffer_reading/drawing optimizationIan Romanick2018-04-263-46/+18
| | | | | Signed-off-by: Ian Romanick <[email protected]> Acked-by: Timothy Arceri <[email protected]>
* radeon: Use _mesa_is_front_buffer_drawingIan Romanick2018-04-264-25/+5
| | | | | Signed-off-by: Ian Romanick <[email protected]> Acked-by: Timothy Arceri <[email protected]>
* radv: set ac_surf_info::num_channels correctlySamuel Pitoiset2018-04-262-1/+8
| | | | | | | | | | | | num_channels has been introduced since "ac/surface: don't set the display flag for obviously unsupported cases". Based on RadeonSI. Fixes: e29facff315 ("ac/surface: don't set the display flag for obviously unsupported cases (v2)") Cc: 18.1 <[email protected]> Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radv: fix DCC enablement since partial MSAA implementationSamuel Pitoiset2018-04-261-6/+6
| | | | | | | | | | | | | dcc_msaa_allowed is always false on GFX9+ and only true on VI if RADV_PERFTEST=dccmsaa is set. This means DCC was disabled in some situations where it should not. This is likely going to fix a performance regression. Fixes: 2f63b3dd09 ("radv: enable DCC for MSAA 2x textures on VI under an option") Cc: 18.1 <[email protected]> Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* nir/opt_constant_folding: fix folding of 8 and 16 bit intsKarol Herbst2018-04-261-2/+12
| | | | | | Signed-off-by: Karol Herbst <[email protected]> Reviewed-by: Jose Maria Casanova Crespo <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* nir: print 8 and 16 bit constants correctlyKarol Herbst2018-04-261-2/+14
| | | | | | Signed-off-by: Karol Herbst <[email protected]> Reviewed-by: Rob Clark <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* nir: support converting to 8-bit integers in nir_type_conversion_opKarol Herbst2018-04-261-1/+6
| | | | | | Signed-off-by: Karol Herbst <[email protected]> Reviewed-by: Jose Maria Casanova Crespo <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* spirv: Don’t check for NaN for most OpFOrd* comparisonsNeil Roberts2018-04-261-11/+6
| | | | | | | | | | | | | | | | | | | For all of the OpFOrd* comparisons except OpFOrdNotEqual the hardware should probably already return false if one of the operands is NaN so we don’t need to have an explicit check for it. This seems to at least work on Intel hardware. This should reduce the number of instructions generated for the most common comparisons. For what it’s worth, the original code to handle this was added in e062eb6415de3a. The commit message for that says that it was to fix some CTS tests for OpFUnord* opcodes. Even if the hardware doesn’t handle NaNs this patch shouldn’t affect those tests. At any rate they have since been moved out of the mustpass list. Incidentally those tests fail on the nvidia proprietary driver so it doesn’t seem like handling NaNs correctly is a priority. Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* Intel: Add a Kaby Lake PCI IDMatt Atwood2018-04-251-0/+1
| | | | | | | v2: Branding changed Signed-off-by: Matt Atwood <[email protected]> Reviewed-by: Rafael Antognolli <[email protected]>
* gallium/util: Fix incorrect refcounting of separate stencil.Eric Anholt2018-04-251-2/+1
| | | | | | | | | | | The driver may have a reference on the separate stencil buffer for some reason (like an unflushed job using it), so we can't directly free the resource and should instead just decrement the refcount that we own. Fixes double-free in KHR-GLES3.packed_depth_stencil.blit.depth32f_stencil8 on vc5. Fixes: e94eb5e6000e ("gallium/util: add u_transfer_helper") Reviewed-by: Rob Clark <[email protected]>
* broadcom/vc5: Fix reloads of separate stencil buffers.Eric Anholt2018-04-251-4/+16
| | | | Like for stores, we need to emit a separate load_general packet.
* broadcom/vc5: Fix cpp of MSAA surfaces on 4.x.Eric Anholt2018-04-252-3/+5
| | | | | | The internal-type-bpp path is for surfaces that get stored in the raw TLB format. For 4.x, we're storing MSAA as just 2x width/height at the original format.
* broadcom/vc5: Implement stencil blits using RGBA.Eric Anholt2018-04-252-2/+83
| | | | Fixes piglit fbo-depthstencil blit default_fb
* broadcom/vc5: Remove leftover vc4 MSAA lowering setup in the FS key.Eric Anholt2018-04-252-16/+6
|
* broadcom/vc5: Fix tile load/store of MSAA surfaces on 4.x.Eric Anholt2018-04-253-5/+15
| | | | | For single-sample we have to always program SAMPLE_0, but for multisample we want to store all the samples.
* travis: update libva required versionJuan A. Suarez Romero2018-04-251-1/+1
| | | | | | | | | Commit fa328456e8f29 added VP9 config support, but this needs a newer libva version, 1.7.0 or above. Fixes: fa328456e8f ("st/va: add VP9 config to enable profile2") CC: 18.1 <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* mesa: GL_EXT_texture_norm16 extension plumbingTapani Pälli2018-04-257-15/+84
| | | | | | | | | | | | | | | | | | | | | Patch enables use of short and unsigned short data for texture uploads, rendering and reading of framebuffers within the restrictions specified in GL_EXT_texture_norm16 spec. Patch also enables those 16bit format layout qualifiers listed in GL_NV_image_formats that depend on EXT_texture_norm16. v2: expose extension with dummy_true fix layout qualifier map changes (Ilia Mirkin) v3: use _mesa_has_EXT_texture_norm16, other fixes and cleanup (Ilia Mirkin) v4: fix rest of the issues found Signed-off-by: Tapani Pälli <[email protected]> Acked-by: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* meson: Fix with_intel_vk and with_amd_vk variablesJordan Justen2018-04-241-2/+2
| | | | | | | Fixes: 5608d0a2cee "meson: use array type options" Cc: Dylan Baker <[email protected]> Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* draw: fix different sign logic when clippingRoland Scheidegger2018-04-251-9/+8
| | | | | | | | | | | | | | | | | | | The logic was flawed, since mul(x,y) will be <= 0 (exactly 0) when the sign is the same but both numbers are sufficiently small (if the product is smaller than 2^-128). This could apparently lead to emitting a sufficient amount of additional bogus vertices to overflow the allocated array for them, hitting an assertion (still safe with release builds since we just aborted clipping after the assertion in this case - I'm however unsure if this is now really no longer possible, so that code stays). Not sure if the additional vertices could cause other grief, I didn't see anything wrong even when hitting the assertion. Essentially, both +-0 are treated as positive (the vertex is considered to be inside the clip volume for this plane), so integrate the logic determining different sign into the branch there. Reviewed-by: Jose Fonseca <[email protected]>
* draw: simplify clip null tri logicRoland Scheidegger2018-04-251-11/+9
| | | | | | | | | Simplifies the logic when to emit null tris (albeit the reasons why we have to do this remain unclear). This is strictly just logic simplification, the behavior doesn't change at all. Reviewed-by: Jose Fonseca <[email protected]>
* nvc0/ir: all short immediates are sign-extended, adjust LIMM testIlia Mirkin2018-04-243-19/+24
| | | | | | | | | | | | | | | | | | | | | | Some analysis suggests that all short immediates are sign-extended. The insnCanLoad logic already accounted for this, but we could still pick the wrong form when emitting actual instructions that support both short and long immediates (with the long form usually having additional restrictions that insnCanLoad should be aware of). This also reverses a bunch of commits that had previously "worked around" this issue in various emitters: 9c63224540ef: gm107/ir: make use of ADD32I for all immediates 83a4f28dc27b: gm107/ir: make use of LOP32I for all immediates b84c97587b4a: gm107/ir: make use of IMUL32I for all immediates d30768025a22: gk110/ir: make use of IMUL32I for all immediates as well as the original import for UMUL in the nvc0 emitter. Reported-by: Karol Herbst <[email protected]> Signed-off-by: Ilia Mirkin <[email protected]> Tested-by: Karol Herbst <[email protected]>
* mesa: call DrawBufferAllocate driver hook in update_framebuffer for ↵Boyan Ding2018-04-251-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | windows-system FB When draw buffers are changed on a bound framebuffer, DrawBufferAllocate() hook should be called. However, it is missing in update_framebuffer with window-system framebuffer, in which FB's draw buffer state should match context state, potentially resulting in a change. Note: This is needed because gallium delays creating the front buffer, i965 works fine without this change. V2 (Timothy Arceri): - Rebased on merged/simplified DrawBuffer driver function - Move DrawBuffer call outside fb->ColorDrawBuffer[0] != ctx->Color.DrawBuffer[0] check to make piglit pass. v3 (Timothy Arceri): - Call new DrawBuffaerAllocate() driver function. Tested-by: Dieter Nützel <[email protected]> (v2) Reviewed-by: Brian Paul <[email protected]> (v2) Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99116
* st/mesa: add new driver function DrawBufferAllocateTimothy Arceri2018-04-253-7/+11
| | | | | | | | | Unlike some of the classic drivers the st was only using DrawBuffer() to allocated some buffers on-demand. Creating a separate function will allow us to call it from update_framebuffer() in the following patch without regressing some of the older classic drivers. Reviewed-by: Marek Olšák <[email protected]>
* mesa: some C99 tidy ups for framebuffer.cTimothy Arceri2018-04-251-13/+5
| | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* meson: Fix no-rtti in llvm detectionDylan Baker2018-04-241-1/+1
| | | | | | | | | | Because I clearly wasn't thinking and clearly didn't do a good job testing. Sigh Fixes: c5a97d658ec19cc02719d7f86c1b0715e3d9ffc4 ("meson: fix builds against LLVM built without rtti") Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* meson: use new warning functionDylan Baker2018-04-241-1/+1
| | | | | | | Instead of emulating it with message. Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: use array type optionsDylan Baker2018-04-242-75/+88
| | | | | | | | | | This option type is nice since it involves less converting strings into lists, and because it validates the values that are provided. v2: - Set with_any_vk to true if any vulkan driver is built (Eric) Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: fix builds against LLVM built without rttiDylan Baker2018-04-241-0/+7
| | | | | | | | | | | Building without rtti is a frought with peril, but it's something that autotools supports so we need to support it too. Since we've moved to version 0.44 as a whole we can use the meson functionality for accessing random llvm-config options we can check for rtti and add -fno-rtti to all C++ code accordingly. Signed-off-by: Dylan Baker <[email protected]>
* meson: remove dummy_cppDylan Baker2018-04-244-11/+3
| | | | | | | | | | meson has gotten pretty smart about tracking C and C++ dependencies (internal and external), and using the right linker. This wasn't always the case and we created empty c++ files to force the use of the c++ linker. We don't need that any more. Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: allow empty sources when using link_wholeDylan Baker2018-04-241-8/+1
| | | | | | | | | meson used to get grumpy if the sources list was empty, even when using --whole-archive (link_whole). In more recent versions that's not true, so remove the workaround. Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: remove workaround for custom target creating .h and .c filesDylan Baker2018-04-241-13/+4
| | | | | | | | | In more modern versions of meson a custom_target returns an index-able object. This allows us to create accurate dependency models for targets that rely only on the header and not on the code from anv_entrypoints. Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: raise required version to 0.44.1Dylan Baker2018-04-243-11/+2
| | | | | | | | | | | | We have already required 0.44 for building clover and swr, so it was already partially required. This just makes it required across the board instead of just for clover and swr. There is a bug in 0.44 which makes it impossible to build mesa in some configurations, so require 0.44.1 which fixes this. Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: fix graw-xlib after auxiliary consolidationDylan Baker2018-04-241-2/+1
| | | | | | | | | | This one's completely my fault, I didn't do good enough testing after rebasing and this got missed. Fixes: d28c24650110c130008be3d3fe584520ff00ceb1 ("meson: build graw tests") Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: only build mesa_st tests when build-tests is trueDylan Baker2018-04-241-1/+3
| | | | | | | | | | Since we have an option to turn test building on and off, we should honor that. Fixes: 34cb4d0ebc14663113705beae63dd52b9d1b2d87 ("meson: build tests for gallium mesa state tracker") Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: don't build classic mesa tests without dri_driversDylan Baker2018-04-241-1/+1
| | | | | | | | | | Since mesa_classic is build-on-demand the tests will create a demand and add a bunch of extra compilation. Fixes: 43a6e84927e3b1290f6f211f5dfb184dfe5a719e ("meson: build mesa test.") Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/meta_util: Re-enable sRGB-encoded fast-clears on CNLNanley Chery2018-04-241-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | The paths which sample with the clear color are now using a getter which performs the sRGB decode needed to enable this fast clear. This path can be exercised by fast-clearing a texture, then performing an operation which requires sRGB decoding. Test coverage for this feature is provided with the following tests: * Shader texture calls: - spec@ext_texture_srgb@tex-srgb * Shader texelfetch calls: - spec@arb_framebuffer_srgb@fbo-fast-clear - spec@arb_framebuffer_srgb@msaa-fast-clear * Blending: - spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend * Blitting: - spec@arb_framebuffer_srgb@blit texture srgb msaa enabled clear Reviewed-by: Jason Ekstrand <[email protected]>
* i965/miptree: Extend the sRGB-blending WA to future platformsNanley Chery2018-04-241-2/+2
| | | | | | The blending issue seems to be present on CNL as well. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Add and use a getter for the clear colorNanley Chery2018-04-244-11/+51
| | | | | | | | | | | | | | | It returns both the inline clear color and a clear address which points to the indirect clear color buffer (or NULL if unused/non-existent). This getter allows CNL to sample from fast-cleared sRGB textures correctly by doing the needed sRGB-decode on the clear color (inline) and making the indirect clear color buffer unused. v2 (Rafael): * Have a more detailed commit message. * Add a comment on the sRGB conversion process. Reviewed-by: Rafael Antognolli <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* util/srgb: Add a float sRGB -> linear helperJason Ekstrand2018-04-241-0/+14
| | | | | Reviewed-by: Nanley Chery <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/wm_surface_state: Use the clear address if clear_bo is non-NULLNanley Chery2018-04-241-11/+6
| | | | | | | | | | We want to add and use a getter that turns off the indirect path by returning zero for the clear color bo and offset. v2: Fix usage of "clear address" in commit message (Jason). Reviewed-by: Rafael Antognolli <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 01:45:15 +0000