summaryrefslogtreecommitdiffstats
path: root/src/gallium/auxiliary
Commit message (Collapse)AuthorAgeFilesLines
* meson: build gallium winsys for dri, null, and wrapperDylan Baker2017-10-161-3/+9
| | | | | Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <eric at anholt.net>
* meson: Build gallium pipe-loaderDylan Baker2017-10-162-0/+65
| | | | Signed-off-by: Dylan Baker <[email protected]>
* meson: Build gallium auxiliaryDylan Baker2017-10-161-0/+528
| | | | | | | v2: - guard gallivm files with "with_llvm" instead of "dep_llvm.found()" Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]> (v1)
* gallium: add tests for PIPE_FORMAT_{X1,A1}B5G5R5_UNORM formatsNicolai Hähnle2017-10-121-0/+13
| | | | | | | This is a left-over from my version of adding the new format after rebasing on Eric's version. Reviewed-by: Marek Olšák <[email protected]>
* gallium: allow 512-bit vectorsTim Rowley2017-10-112-9/+9
| | | | | | | | | Increase the max allowed vector size from 256 to 512. No piglit llvmpipe regressions running on avx2. Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* broadcom: Add V3D 3.3 gallium driver called "vc5", for BCM7268.Eric Anholt2017-10-103-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | V3D 3.3 is a continuation of the 3D implementation in VC4 (v2.1 and v2.6). V3D 3.3 introduces an MMU (no more CMA allocations) and support for GLES3.1. This driver is not currently conformant, though that will be a target as soon as possible. V3D 3.x parts use a new texture tiling layout common across many Broadcom graphics parts including and the HVS scanout engine. It also massively changes the QPU instructions, introducing a common physical register file (no more A/B split) and half-float instructions, while removing the 4x8 unorm instructions in favor of half-float for talking to fixed function interfaces. Because so much has changed, vc5 is implemented in a separate gallium driver, using only the XML code-generation support from vc4. v2: Fix tile layout for 64bpp textures. Fix texture swizzling for 32-bit returns. Fix up a bit of MRT setup. Sync the simulator to kernel behavior a bit more. Improve uniform debugging code. Rebase on QIR->VIR rename. Move texture state mostly to the CSOs. Improve cache flushing on the simulator. Fix program deletion use-after-frees. Acked-by: Dave Airlie <[email protected]> (uabi plan) Acked-by: Daniel Vetter <[email protected]> (uabi plan)
* gallium: Add support for 5551 with the 1-bit field in the low bit.Eric Anholt2017-10-101-0/+2
| | | | | | | | | | | | This is how VC4 stores 5551 textures, which we need to support for GL_OES_required_internalformat. v2: Extend commit message, fix svga driver build, add BE ordering from Roland. v3: Rebase on PIPE_FORMAT_R10G10B10X2_UNORM addition. Reviewed-by: Marek Olšák <[email protected]> (v2) Reviewed-by: Nicolai Hähnle <[email protected]> (v2)
* u_threaded_context: fix a memory leakNicolai Hähnle2017-10-101-7/+8
| | | | | | | | The uploaders can own transfers which need to be unmapped. Destroy them before the final sync (they're not used from the driver thread anyway) so that the transfer_unmap call is processed by the driver. Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: don't change viewport for blits, use window-space positionsMarek Olšák2017-10-072-1/+4
| | | | | | The viewport state was an identity anyway. Reviewed-by: Nicolai Hähnle <[email protected]>
* radeonsi: don't save and restore vertex buffers and elements for u_blitterMarek Olšák2017-10-071-6/+9
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium/u_blitter: let drivers decide which VS to use for draw_rectangleMarek Olšák2017-10-072-41/+61
| | | | | | | This approach allows drivers to set their own vertex shader and skip compilation of u_blitter vertex shaders. Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium/u_blitter: let drivers set the vertex elements stateMarek Olšák2017-10-072-26/+30
| | | | | | radeonsi won't set it. Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium/u_blitter: remove blitter_context_priv::viewportMarek Olšák2017-10-071-10/+8
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* gallivm: don't use pabs intrinsic with llvm version >= 6Roland Scheidegger2017-10-071-9/+4
| | | | | | | | | | | | The intrinsic is gone, causing shader compilation to crash. While here, also change the fallback code to match what llvm's auto-updater of these intrinsics would do (except that there will still be zext/trunc instructions in there), which should ensure that the sequence gets recognized and fused back into a pabs in the end (I didn't test this, and it's possible even the old sequence would get recognized, but I don't see a reason why we shouldn't use the same sequence in any case). Tested-by: Vinson Lee <[email protected]>
* tgsi/ureg: allow any register file in address operandsMarek Olšák2017-10-061-6/+0
| | | | | Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* tgsi/scan: scan address operands (v2)Marek Olšák2017-10-061-1/+42
| | | | | | v2: set swizzled usage mask Reviewed-by: Nicolai Hähnle <[email protected]>
* tgsi/scan: set correct usage mask for tex offsets in scan_src_operandMarek Olšák2017-10-061-4/+4
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* tgsi/scan: take advantage of already swizzled usage mask in scan_src_operandMarek Olšák2017-10-061-30/+17
| | | | | | It has always been a usage mask *after* swizzling. Reviewed-by: Nicolai Hähnle <[email protected]>
* tgsi/scan: set non-valid src_index for tex offsets in scan_src_operandMarek Olšák2017-10-061-1/+1
| | | | | | tex offsets are not "Src" operands. Reviewed-by: Nicolai Hähnle <[email protected]>
* tgsi: implement tgsi_util_get_inst_usage_mask properlyMarek Olšák2017-10-062-113/+206
| | | | | | All opcodes are handled. Reviewed-by: Nicolai Hähnle <[email protected]>
* gallivm/ppc64le: allow environmental control of Altivec code generationBen Crocker2017-10-051-8/+24
| | | | | | | | | | | | | | In check_os_altivec_support(), allow control of Altivec (first PPC vector instruction set) code generation via a new environmental control, GALLIVM_ALTIVEC, which is expected to take on a value of 1 or 0. The default is to enable Altivec code generation. This environmental control of Altivec code generation is initially available only #ifdef DEBUG. Cc: "17.2" <[email protected]> Signed-off-by: Ben Crocker <[email protected]> Acked-by: Roland Scheidegger <[email protected]>
* gallivm/ppc64le: adjust VSX code generation control.Ben Crocker2017-10-051-7/+30
| | | | | | | | | | | | | | | | | | | | | | | In lp_build_create_jit_compiler_for_module(), advance the minimum version of LLVM for VSX code generation to 4.0; this is the minimum revision at which several known VSX code generation bugs are fixed: https://llvm.org/bugs/show_bug.cgi?id=25503 (fixed in 3.8.1) https://llvm.org/bugs/show_bug.cgi?id=26775 (fixed in 3.8.1) https://llvm.org/bugs/show_bug.cgi?id=33531 (fixed in 4.0) An llc performance bug introduced in LLVM 4.0, https://llvm.org/bugs/show_bug.cgi?id=34647 is still pending as of LLVM 5.0, but only has a pronounced effect on one of the Piglit tests: ext_transform_feedback-max-varyings. All changes tested via Piglit. Cc: "17.2" <[email protected]> Signed-off-by: Ben Crocker <[email protected]> Acked-by: Roland Scheidegger <[email protected]>
* gallivm: allow additional llc optionsBen Crocker2017-10-051-0/+23
| | | | | | | | | | | | | | | | In init_native_targets, allow the passing of additional options to the LLC compiler via new GALLIVM_LLC_OPTIONS environmental control. This option is available only #ifdef DEBUG, initially. At top, add #include <llvm-c/Support.h> for LLVMParseCommandLineOptions() declaration. v2: Fix compile error with old llvm versions (sroland) Cc: "17.2" <[email protected]> Signed-off-by: Ben Crocker <[email protected]> Acked-by: Nicolai Hähnle <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: fix typo in debug_printf messageBen Crocker2017-10-051-1/+1
| | | | | | | | | | In gallivm_compile_module, fix a typo in the debug_printf("Invoke as \"llc ..." message. Cc: "17.2" <[email protected]> Signed-off-by: Ben Crocker <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: silence 'variable may be used uninitialized' warningsBrian Paul2017-10-031-1/+1
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* gallium/u_tests: fix ifdef for sync_file fencesGeorge Kyriazis2017-10-031-1/+1
| | | | | | include libsync.h only when libdrm is compiled in Reviewed-by: Marek Olšák <[email protected]>
* mesa: Remove force_s3tc_enable driconf variableMatt Turner2017-10-021-1/+0
| | | | | Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* gallium: Remove util_format_s3tc_init()Matt Turner2017-10-022-78/+5
| | | | | Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* gallium: Remove util_format_s3tc_enabledMatt Turner2017-10-023-59/+1
| | | | | Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* gallium/u_tests: test sync_file fencesMarek Olšák2017-10-031-0/+101
| | | | | | | This should be sufficient for testing all kernel/libdrm/radeonsi codepaths that are used by radeonsi. Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium: add PIPE_FORMAT_R10G10B10X2_UNORMNicolai Hähnle2017-10-022-0/+7
| | | | Reviewed-by: Marek Olšák <[email protected]>
* gallium/vl: don't use the template keywordMarek Olšák2017-09-301-14/+14
| | | | | | for C++ editors Reviewed-by: Brian Paul <[email protected]>
* gallium: add new LOD opcodeRoland Scheidegger2017-09-303-4/+59
| | | | | | | | | | The operation performed is all the same as LODQ, but with the usual differences between dx10 and GL texture opcodes, that is separate resource and sampler indices (plus result swizzling, and setting z/w channels to zero). Reviewed-by: Jose Fonseca <[email protected]> Acked-by: Nicolai Hähnle <[email protected]>
* gallium: add LDEXP TGSI instruction and corresponding capNicolai Hähnle2017-09-295-2/+20
| | | | | Reviewed-by: Marek Olšák <[email protected]> Tested-by: Dieter Nützel <[email protected]>
* tgsi: infer that dst[1] of DFRACEXP is an integerNicolai Hähnle2017-09-294-5/+8
| | | | | Reviewed-by: Marek Olšák <[email protected]> Tested-by: Dieter Nützel <[email protected]>
* gallivm: add support for TGSI instructions with two outputsNicolai Hähnle2017-09-293-1/+31
| | | | | Reviewed-by: Marek Olšák <[email protected]> Tested-by: Dieter Nützel <[email protected]>
* gallivm: add dst register index to lp_build_tgsi_context::emit_storeNicolai Hähnle2017-09-293-9/+9
| | | | | Reviewed-by: Marek Olšák <[email protected]> Tested-by: Dieter Nützel <[email protected]>
* tgsi: clarify the semantics of DFRACEXPNicolai Hähnle2017-09-292-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The status quo is quite the mess: 1. tgsi_exec will do a per-channel computation, and store the dst[0] result (significand) correctly for each channel. The dst[1] result (exponent) will be written to the first bit set in the writemask. So per-component calculation only works partially. 2. r600 will only do a single computation. It will replicate the exponent but not the significand. 3. The docs pretend that there's per-component calculation, but even get dst[0] and dst[1] confused. 4. Luckily, st_glsl_to_tgsi only ever emits single-component instructions, and kind-of assumes that everything is replicated, generating this for the dvec4 case: DFRACEXP TEMP[0].xy, TEMP[1].x, CONST[0][0].xyxy DFRACEXP TEMP[0].zw, TEMP[1].y, CONST[0][0].zwzw DFRACEXP TEMP[2].xy, TEMP[1].z, CONST[0][1].xyxy DFRACEXP TEMP[2].zw, TEMP[1].w, CONST[0][1].zwzw Settle on the simplest behavior, which is single-component calculation with replication, document it, and adjust tgsi_exec and r600. Reviewed-by: Marek Olšák <[email protected]> Tested-by: Dieter Nützel <[email protected]>
* tgsi: infer that DLDEXP's second source has an integer typeNicolai Hähnle2017-09-294-7/+11
| | | | | Reviewed-by: Marek Olšák <[email protected]> Tested-by: Dieter Nützel <[email protected]>
* gallium/util: use new util_vasprintf() functionBrian Paul2017-09-281-1/+2
| | | | Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium: Weaken assertion about u_mm's align2 field.Eric Anholt2017-09-261-1/+4
| | | | | | | | | vc5 MMU mappings are access-controlled at a 128kb boundary, so the 4kb here was too small for that purpose. Allowing any valid align2 value that u_mm's 32-bit addressing can represent will still catch most cases of people passing in a byte alignment. Reviewed-by: Nicolai Hähnle <[email protected]>
* vl/compositor: convert RGB buffer to YUV with color conversionLeo Liu2017-09-252-0/+81
| | | | Acked-by: Christian König <[email protected]>
* vl/csc: add a RGB to YUV CSC matrixLeo Liu2017-09-252-1/+11
| | | | Acked-by: Christian König <[email protected]>
* vl/compositor: create RGB to YUV fragment shaderLeo Liu2017-09-252-0/+51
| | | | Acked-by: Christian König <[email protected]>
* vl/compositor: add Bob top and bottom to YUV deint functionLeo Liu2017-09-251-6/+28
| | | | Acked-by: Christian König <[email protected]>
* vl/compositor: remove vl_compositor_yuv_deint() functionLeo Liu2017-09-252-40/+0
| | | | | | No longer used. Acked-by: Christian König <[email protected]>
* vl/compositor: add a new function for YUV deintLeo Liu2017-09-252-0/+42
| | | | | | | It will replace previous deint function with abilities of scaling and field deinterlacing Acked-by: Christian König <[email protected]>
* vl/compositor: extend YUV deint function to do field deintLeo Liu2017-09-252-12/+26
| | | | | | It will add Bob deint ability to interlaced video for HW encoder Acked-by: Christian König <[email protected]>
* vl/compositor: separate YUV part from shader video buffer functionLeo Liu2017-09-251-13/+18
| | | | | | So that it can be re-used Acked-by: Christian König <[email protected]>
* gallium/util: Remove unused keymapThomas Helland2017-09-213-388/+0
| | | | | | | | | | This is not used anywhere in the codebase. It's a hashtable implementation that is based around cso_hash, and is therefore (and as mentioned in a comment in the source) quite similar to u_hash_table. CC: Brian Paul<[email protected]> Reviewed-by: Marek Olšák <[email protected]>