aboutsummaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* intel/eu: Use GET_BITS in brw_inst_set_send_ex_descJason Ekstrand2019-01-291-5/+5
| | | | | | It's a bit more readable Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use SHADER_OPCODE_SEND for varying UBO pulls on gen7+Jason Ekstrand2019-01-297-88/+25
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use SHADER_OPCODE_SEND for texturing on gen7+Jason Ekstrand2019-01-294-142/+177
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use a logical opcode for IMAGE_SIZEJason Ekstrand2019-01-294-6/+21
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Use SHADER_OPCODE_SEND for surface messagesJason Ekstrand2019-01-295-214/+201
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Add a generic SEND opcodeJason Ekstrand2019-01-299-3/+91
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/eu: Rework surface descriptor helpersJason Ekstrand2019-01-292-234/+234
| | | | | | | | | | This commit pulls the surface descriptor helpers out into brw_eu.h and makes them no longer depend on the codegen infrastructure. This should allow us to use them directly from the IR code instead of the generator. This change is unfortunately less mechanical than perhaps one would like but it should be fairly straightforward. Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/eu: Add has_simd4x2 bools to surface_write functionsJason Ekstrand2019-01-291-6/+8
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Take an explicit exec size in brw_surface_payload_size()Jason Ekstrand2019-01-291-20/+39
| | | | | | | | Instead of magically falling back to SIMD8 for atomics and typed messages on Ivy Bridge, explicitly figure out the exec size and pass that into brw_surface_payload_size. Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Handle IMAGE_SIZE in size_read() and is_send_from_grf()Jason Ekstrand2019-01-291-0/+2
| | | | | | | Like all the other sends, it's just mlen * REG_SIZE. Fixes: 3cbc02e4693 "intel: Use TXS for image_size when we have..." Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/defines: Explicitly cast to uint32_t in SET_FIELD and SET_BITSJason Ekstrand2019-01-292-3/+3
| | | | | | | | | If you pass a bool in as the value to set, the C standard says that it gets converted to an int prior to shifting. If you try to set a bool to bit 31, this lands you in undefined behavior. It's better just to add the explicit cast and let the compiler delete it for us. Reviewed-by: Iago Toral Quiroga <[email protected]>
* intel/fs: Get rid of fs_inst::equalsJason Ekstrand2019-01-292-23/+7
| | | | | | | | | | There are piles of fields that it doesn't check so using it is a lie. The only reason why it's not causing problem is because it has exactly one user which only uses it for MOV instructions (which aren't very interesting) and only on Sandy Bridge and earlier hardware. Just get rid of it and inline it in the one place that it's actually used. Reviewed-by: Iago Toral Quiroga <[email protected]>
* freedreno: minor cleanupsRob Clark2019-01-292-2/+0
| | | | Signed-off-by: Rob Clark <[email protected]>
* freedreno: stop frob'ing pipe_resource::nr_samplesRob Clark2019-01-294-6/+15
| | | | | | | | | | | | Previously we tried to normalize nr_samples to MAX2(1, nr_samples) to avoid having to deal with 0 vs 1 everywhere. But this causes problems in mesa/st, for example st_finalize_texture() will think there is a nr_samples mismatch and recreate the texture. Somehow this manifests as corrupt x11 font rendering on generations that do not support MSAA (but apparently works fine on a5xx and a6xx which do support MSAA.) Fixes: cf0c7258ee0 freedreno/a5xx: MSAA Signed-off-by: Rob Clark <[email protected]>
* freedreno/a6xx: fix blitter nr_samples checkRob Clark2019-01-291-1/+3
| | | | | | nr_samples for non-MSAA case could be either zero or one. Signed-off-by: Rob Clark <[email protected]>
* freedreno/a5xx: fix blitter nr_samples checkRob Clark2019-01-291-1/+2
| | | | | | nr_samples for non-MSAA case could be either zero or one. Signed-off-by: Rob Clark <[email protected]>
* radv: Enable VK_EXT_memory_priority.Bas Nieuwenhuizen2019-01-293-5/+20
| | | | Reviewed-by: Samuel Pitoiset <[email protected]>
* radv/winsys: Add priority handling during submit.Bas Nieuwenhuizen2019-01-293-49/+115
| | | | | | | | | Switched to the raw bo list api to avoid having to use 2 arrays for everything. This was introduced in libdrm 2.4.97 which we already depend upon. Reviewed-by: Samuel Pitoiset <[email protected]>
* radv/winsys: Set winsys bo priority on creation.Bas Nieuwenhuizen2019-01-2912-29/+82
| | | | Reviewed-by: Samuel Pitoiset <[email protected]>
* radv: re-enable fast depth clears for 16-bit surfaces on VISamuel Pitoiset2019-01-291-8/+0
| | | | | | | | | | | | | | | | | | | This has been disabled some months ago because it introduced rendering issues with Shadow Of Warrier II (DXVK). This game is no longer affected, I wonder if 824cfc1ee5e ("radv: rework the TC-compat HTILE hardware bug with COND_EXEC") fixed the problem. I checked The Forest on my Polaris, and it renders fine too. According to Phillip, this gives +5.5% with Rise Of The Tomb Raider and DXVK. This is because DXVK uses 16-bit depth surfaces while the native port from Feral uses 32-bit depth surfaces. Unfortunately, Shadow Of The Tomb Raider isn't affected because it clears each layer of a D16 array texture individually. So it doesn't hit the fast clear path. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* vc4: Enable NEON asm on meson cross-builds.Eric Anholt2019-01-281-4/+6
| | | | | | | | | The core Mesa with_asm_arch and USE_ARM_ASM flags are disabled for meson cross-builds because of the need to run host binaries on the build system. vc4 doesn't need to do that, so skip with_asm_arch to enable NEON on my cross-builds. Fixes: ebcb4c2156e9 ("meson: Enable VC4's NEON assembly support.")
* vc4: Declare the cpu pointers as being modified in NEON asm.Carsten Haitzler (Rasterman)2019-01-281-18/+15
| | | | | | | | | | | | | Otherwise, the compiler is free to reuse the register containing the input for another call and assume that the value hasn't been modified. Fixes crashes on texture upload/download with current gcc. We now have to have a temporary for the cpu2 value, since outputs must be lvalues. (commit message by anholt) Fixes: 4d30024238ef ("vc4: Use NEON to speed up utile loads on Pi2.")
* vc4: Use named parameters for the NEON inline asm.Carsten Haitzler (Rasterman)2019-01-281-80/+100
| | | | | | | This makes the asm code more intelligible and clarifies the functional change in the next commit. (commit message and commit squashing by anholt)
* kmsro: Add freedreno renderonly supportJonathan Marek2019-01-283-0/+20
| | | | Signed-off-by: Jonathan Marek <[email protected]>
* freedreno: a2xx: add perfcntrsJonathan Marek2019-01-288-0/+1118
| | | | | | Based on a5xx perfcntrs implementation. Signed-off-by: Jonathan Marek <[email protected]>
* freedreno: a2xx: minor solid_vertexbuf fixupsJonathan Marek2019-01-283-4/+6
| | | | | | | The big thing here is the 0x60 offset for the mem2gmem copy which I missed in my last patch. Signed-off-by: Jonathan Marek <[email protected]>
* freedreno: a2xx: clear fixes and fast clear pathJonathan Marek2019-01-288-126/+434
| | | | | | | | This fixes the depth/stencil clear on a20x, and adds a fast clear path. The fast clear path is only used for a20x, needs performance tests on a22x. Signed-off-by: Jonathan Marek <[email protected]>
* freedreno: a2xx: a20x hw binningJonathan Marek2019-01-2811-16/+298
| | | | Signed-off-by: Jonathan Marek <[email protected]>
* freedreno: update a2xx registersJonathan Marek2019-01-281-11/+893
| | | | Signed-off-by: Jonathan Marek <[email protected]>
* glsl: use remap location when serialising uniform program resource dataTimothy Arceri2019-01-291-7/+26
| | | | | | | | | | | | | This allows us to avoid expensive string compares since we already have a map to the pointers. These compares were taking ~30 seconds for a single shader compile in Godot due to it using 64,000+ uniforms. Fixes: c4cff5f40254 ("glsl: add basic support for resource list to shader cache") Reviewed-by: Tapani Pälli <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109229
* freedreno: a2xx: enable early-Z testingJonathan Marek2019-01-284-3/+11
| | | | | | | Enable earlyZ when alpha test is disabled. Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Rob Clark <[email protected]>
* freedreno: a2xx: ir2 cleanupJonathan Marek2019-01-282-3/+1
| | | | Reviewed-by: Rob Clark <[email protected]>
* Switch imx to kmsro and remove the imx winsysRob Herring2019-01-2816-253/+3
| | | | | | | The kmsro winsys is equivalent to the imx winsys, so we can switch to it and remove the imx one. Signed-off-by: Rob Herring <[email protected]>
* kmsro: Add etnaviv renderonly supportRob Herring2019-01-284-17/+50
| | | | | | | | Enable using etnaviv for KMS renderonly. This still needs KMS driver name mapping to kmsro to be used automatically. Acked-by: Eric Anholt <[email protected]> Signed-off-by: Rob Herring <[email protected]>
* kmsro: Extend to include hx8357d.Eric Anholt2019-01-284-0/+4
| | | | | | | | | | | | This allows vc4 to initialize on the Adafruit PiTFT 3.5" touchscreen with the hx8357d tinydrm driver v2: Whitespace fix noted by Eric Engestrom, update commit message for the driver being merged. v3: Rebase on Rob Herring's pipe-loader changes. Acked-by: Eric Engestrom <[email protected]> (v1) Acked-by: Emil Velikov <[email protected]> (v1)
* pipe-loader: Fallback to kmsro driver when no matching driver name foundRob Herring2019-01-281-5/+8
| | | | | | | | | | If we can't find a driver matching by name, then use the kmsro driver. This removes the need for needing a driver descriptor for every possible KMS driver. Signed-off-by: Rob Herring <[email protected]> Reviewed-by: Alyssa Rosenzweig <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* pl111: Rename the pl111 driver to "kmsro".Eric Anholt2019-01-2821-51/+51
| | | | | | | | | | | | The vc4 driver can do prime sharing to many different KMS-only devices, such as the various tinydrm drivers for SPI-attached displays. Rename the driver away from "pl111" to represent what it will actually support: various sorts of KMS displays with the renderonly layer used to attach a GPU. Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Acked-by: Emil Velikov <[email protected]>
* radv: set noalias/dereferenceable LLVM attributes based on param typesSamuel Pitoiset2019-01-281-13/+7
| | | | | | | | Instead of using this useless array_params_mask variable. This should set these two attributes to streamout buffers too. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radv: simplify allocating user SGPRS for descriptor setsSamuel Pitoiset2019-01-281-68/+34
| | | | | | | | Unnecesary to check the current stages if desc_set_used_mask is used. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radv: remove radv_userdata_info::indirect fieldSamuel Pitoiset2019-01-283-12/+6
| | | | | | | Always false. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* mesa/main: Expose EXT_sRGB_write_controlGert Wollny2019-01-283-5/+4
| | | | | | | | | | | | | | | Use EXT_framebuffer_sRGB to expose EXT_sRGB_write_control on GLES. Remove the checks for desktion GL in the enable calls, since EXT_framebuffer_sRGB now also indicates support for switching the linear-sRGB color space conversion on GLES. Thanks to Ilia Mirkin for all the helpful discussions that helped to rework this series. v2: Fix alphabetical listing of extensions (Tapani Pälli) Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]> (v1)
* mesa/main/version: Lower the requirements for GLES 3.0Gert Wollny2019-01-281-2/+2
| | | | | | | | | | | GLES 3.0 does not actually require support for EXT_framebuffer_sRGB, it only needs support for sRGB attachments to framebuffers and framebuffer objects as defined in ARB_framebuffer_objects. v2: Clarify that ARB_framebuffer_objects is needed. Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/main: Use flag for EXT_sRGB instead of EXT_framebuffer_sRGB where possibleGert Wollny2019-01-285-5/+5
| | | | | | | | | | | | | | | | All drivers that support EXT_framebuffer_sRGB also support EXT_sRGB, but in order to keep this commit minial, and not to break any drivers both flags are checked. v2: - Use only EXT_sRGB (Ilia Mirkin) - Move adding the flag EXT_sRGB to gl_extensions to a separate patch v3: use _mesa_has_EXT_framebuffer_sRGB instead of extension flag The _mesa_has function also checks for the correct versions and should be preferred over using the flags directly (Erik) Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa/st: rework support for sRGB framebuffer attachementsGert Wollny2019-01-284-18/+31
| | | | | | | | | | | | | | | | | | | | | For GLES sRGB framebuffer attachemnt support is provided in two steps: sRGB attachments like described in EXT_sRGB (and GLES 3.0) that enable linear to sRGB color space transformation automatically, and the ability to switch formats of the render target surface between sRGB and linear that introduces full support for EXT_framebuffer_sRGB. Set the according flags to reflect these two levels of sRGB support. As a difference between desktopm GL and GLES, on desktop GL for a sRGB framebuffer attachment the linear-sRGB conversion is turned off by default, and for GLES it is turned on. This needs to be taken into account when initally creating a surface, i.e. on desktop GL creation of a sRGB surface is preferred, but on GLES sRGB surfaces are only created when explicitely requested. v2: - Use the new CAPS name Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i965: Set flag for EXT_sRGBGert Wollny2019-01-281-0/+1
| | | | | | Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: <Gurchetan Singh [email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* mesa:main: Add flag for EXT_sRGB to gl_extensionsGert Wollny2019-01-281-0/+1
| | | | | | | | | | | | | EXT_sRGB is an (incomplete) GLES extension that provides support for sRGB framebuffer attachments, hence it can be used to check for this support as an alternative to EXT_framebuffer_sRGB that provies the same functionality but also sRGB write control support. However, since EXT_sRGB is incomplete and superseted by GLES 3.0 it will not be exposed as an extension. Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* virgl: Set sRGB write control CAP based on host capabilitiesGert Wollny2019-01-283-0/+13
| | | | | | | | | v2: - Use the renamed CAPS - add assetions to make sure that mesa doesn't try to switch destination surface formats when it is not supported. (Ilia Mirkin) Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Gurchetan Singh <[email protected]>
* Gallium: Add new CAPS to indicate whether a driver can switch SRGB writeGert Wollny2019-01-283-0/+6
| | | | | | | | | | | | | | Add a new cap that indicates whether the drivers supports enabling/disabling the conversion from linear space to sRGB for a framebuffer attachment. In Driver terms that this CAP indicates whether the driver can switcht between a linear and and a sRGB surface format for draw destinations witout changing the sourface itself. v2: rename CAP to DEST_SURFACE_SRGB_CONTROL to reflect its purpouse better (pointed out by Ilia Mirkin) Signed-off-by: Gert Wollny <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* spirv: Don't use special semantics when counting vertex attribute sizeNeil Roberts2019-01-281-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under Vulkan, the double vertex attributes take up the same size regardless of whether they are vertex inputs or any other stage interface. Under OpenGL (ARB_gl_spirv), from GLSL 4.60 spec, section 4.3.9 Interface Blocks: "It is a compile-time error to have an input block in a vertex shader or an output block in a fragment shader. These uses are reserved for future use." So we also don't need to check if it is an vertex input or not, and use false in any case. v2: (changes made by Alejandro Piñeiro) * Update required after "spirv: Handle location decorations on block interface members" own updates (original patch was sent several months ago) * After Neil suggesting it, confirm that this change can be also done for OpenGL (ARB_gl_spirv). Expand commit message. v3: update after changing name of main method on a previous patch Signed-off-by: Neil Roberts <[email protected]> Signed-off-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* glsl_types: Rename parameter of glsl_count_attribute_slotsNeil Roberts2019-01-284-10/+17
| | | | | | | | | | | | glsl_count_attribute_slots takes a parameter to specify whether the type is being used as a vertex input because on GL double attributes only take up one slot. Vulkan doesn’t make this distinction so this patch renames the argument to is_gl_vertex_input in order to make it more clear that it should always be false on Vulkan. v2: minor variable renaming (s/member/member_type) (Tapani) Reviewed-by: Tapani Pälli <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 21:51:43 +0000