aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* pl111: Rename the pl111 driver to "kmsro".Eric Anholt2019-01-2827-68/+68
| | | | | | | | | | | | 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]>
* spirv/nir: handle location decorations on block interface membersNeil Roberts2019-01-282-9/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the code was taking any location decoration on the block and using that to calculate the member locations for all of the members. I think this was assuming that there would only be one location decoration for the entire block. According to the Vulkan spec it is possible to add location decorations to individual members: “If the structure type is a Block but without a Location, then each of its members must have a Location decoration. If it is a Block with a Location decoration, then its members are assigned consecutive locations in declaration order, starting from the first member which is initially the Block. Any member with its own Location decoration is assigned that location. Each remaining member is assigned the location after the immediately preceding member in declaration order.” This patch makes it instead keep track of which members have been assigned an explicit location. It also has a space to store the location for the struct as a whole. Once all the decorations have been processed it iterates over each member to fill in the missing locations using the rules described above. So, this commit is needed to get working a case like this, on both Vulkan and OpenGL using SPIR-V (ARB_gl_spirv): out block { layout(location = 2) vec4 c; layout(location = 3) vec4 d; layout(location = 0) vec4 a; layout(location = 1) vec4 b; } name; v2: (changes made by Alejandro Piñeiro) * Update after introducing struct member splitting (See commit b0c643d) * Update after only exposing interface_type for blocks, not to any struct * Update after last changes done for xfb support v3: use "assign" instead of "add" on the new method added (Tapani) Signed-off-by: Neil Roberts <[email protected]> Signed-off-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* etnaviv: add linear sampling supportChristian Gmeiner2019-01-283-1/+25
| | | | | Signed-off-by: Christian Gmeiner <[email protected]> Reviewed-by: Lucas Stach <[email protected]>
* etnaviv: update headers from rnndbChristian Gmeiner2019-01-288-55/+227
| | | | | | | Update to etna_viv commit 4d2f857. Signed-off-by: Christian Gmeiner <[email protected]> Reviewed-by: Lucas Stach <[email protected]>
* etnaviv: extend etna_resource with an addressing modeChristian Gmeiner2019-01-284-8/+22
| | | | | | | | | Defines how sampler (and pixel pipes) needs to access the data represented with a resource. The used default is mode is ETNA_ADDRESSING_MODE_TILED. Signed-off-by: Christian Gmeiner <[email protected]> Reviewed-by: Lucas Stach <[email protected]>
* nvc0: don't put text segment into bufctxIlia Mirkin2019-01-276-13/+16
| | | | | | | | | The text segment is shared among multiple contexts, while each one has its own bufctx. So when reallocating the text segment, some contexts may end up with stale values in their bufctx's. Instead limit the exposure to the bufctx to within a single draw. Signed-off-by: Ilia Mirkin <[email protected]>
* radv/ac: fix some fp16 handlingTimothy Arceri2019-01-282-2/+2
| | | | | | Fixes: b722b29f10d4 ("radv: add support for 16bit input/output") Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* v3d: Create separate sampler states for the various blend formats.Eric Anholt2019-01-274-50/+303
| | | | | | | | | | | | The sampler border color is encoded in the TMU's blending format (half floats, 32-bit floats, or integers) and must be clamped to the format's range unorm/snorm/int ranges by the driver. Additionally, the TMU doesn't know about how we're abusing the swizzle to support BGRA, A, and LA, so we have to pre-swizzle the border color for those. We don't really want to spend half a kb on sampler states in most cases, so skip generating the variants when the border color is unused or is 0,0,0,0.
* v3d: Move the sampler state to the long-lived state uploader.Eric Anholt2019-01-273-6/+13
| | | | | Samplers are small (8-24 bytes), so allocating 4k for them is a huge waste.
* v3d: Use the symbolic names for wrap modes from the XML.Eric Anholt2019-01-272-11/+14
|
* v3d: Fix stencil sampling from a separate-stencil buffer.Eric Anholt2019-01-272-0/+7
| | | | | | | | When the sampler view is in sample-stencil mode, we need to return uint stencil values. To do that, fill in the format table to return R8I, and have the sampler view point at the separate stencil buffer. Fixes dEQP-GLES31.functional.stencil_texturing.format.depth32f_stencil8_2d
* v3d: Fix stencil sampling from packed depth/stencil.Eric Anholt2019-01-271-1/+1
| | | | We need to pick the 8-bit unorm value out, not the depth component.
* v3d: Fix release-build warning about utile_h.Eric Anholt2019-01-271-2/+1
|
* v3d: Flush blit jobs immediately after generating them.Eric Anholt2019-01-271-0/+8
| | | | | | | | | | Fixes OOMs in the CTS's packed_pixels.varied_rectangle.* tests -- the series of texture uploads at the start before texturing occurred would end up all sitting around as cached jobs for reuse. By flushing immediately, peak active BO usage goes from 150M to 40M. We could maybe put some limits on how many jobs we keep around, but blits seem particularly unlikely to get reused for other drawing.
* v3d: Fix BO stats accounting for imported buffers.Eric Anholt2019-01-271-0/+3
|
* v3d: Drop maximum number of texture units down to 16.Eric Anholt2019-01-272-4/+4
| | | | | | This is the GLES 3.2 minmax, and also what the closed source driver does. Avoids hitting OOMs in the CTS's dEQP-GLES3.functional.texture.units.all_units.only_cube.1.
* v3d: Avoid duplicating limits defines between gallium and v3d core.Eric Anholt2019-01-279-17/+52
| | | | | We don't want to pull the compiler into every include in the gallium driver, so just make a new little header to store the limits.
* v3d: Fix overly-large vattr_sizes structs.Eric Anholt2019-01-271-2/+2
| | | | We want one vector size per vector, not per component.
* v3d: Rename gallium-local limits defines from VC5 to V3D.Eric Anholt2019-01-2711-33/+33
| | | | | The compiler has its limits under V3D_* (like most V3D stuff), so sync up with that.
* radv: Remove unused variable.Bas Nieuwenhuizen2019-01-271-1/+0
| | | | Trivial.
* radv: add device->instance extension dependenciesNiklas Haas2019-01-271-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | From the vulkan spec 33.3 "Extension Dependencies": "Any device extension that has an instance extension dependency that is not enabled by vkCreateInstance is considered to be unsupported, hence it must not be returned by vkEnumerateDeviceExtensionProperties for any VkPhysicalDevice child of the instance." Therefore we need to check whether the instance-level extensions are actually enabled when deciding to support a device-level extension or not. Furthermore, we need to do this for all instance-level extensions of any (transitive) device-level extension dependency, due to the following paragraph: "If an extension is supported (as queried by vkEnumerateInstanceExtensionProperties or vkEnumerateDeviceExtensionProperties), then required extensions of that extension must also be supported for the same instance or physical device." Finally, because some of these vulkan extensions may be implicitly promoted to future vulkan core API versions, we can also satisfy the dependency if the vulkan API version is high enough. Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radv: correctly use vulkan 1.0 by defaultNiklas Haas2019-01-271-1/+1
| | | | | | | | | | | | From the vulkan spec 3.2 "Instances": "Providing a NULL VkInstanceCreateInfo::pApplicationInfo or providing an apiVersion of 0 is equivalent to providing an apiVersion of VK_MAKE_VERSION(1,0,0)." Fixes: ffa15861ef7c924a33e1f "radv: UseEnumerateInstanceVersion for the default version." Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* glsl: fix block member alignment validation for vec3Niklas Haas2019-01-271-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Section 7.6.2.2 (Standard Uniform Block Layout) of the GL spec says: The base offset of the first member of a structure is taken from the aligned offset of the structure itself. The base offset of all other structure members is derived by taking the offset of the last basic machine unit consumed by the previous member and adding one. The current code does not reflect this last sentence - it effectively instead aligns up the next offset up to the alignment of the previous member. This causes an issue in exactly one case: layout(std140) uniform block { layout(offset=0) vec3 var1; layout(offset=12) float var2; }; As per section 7.6.2.1 (Uniform Buffer Object Storage) and elsewhere, a vec3 consumes 3 floats, i.e. 12 basic machine units. Therefore, `var1` in the example above consumes units 0-11, with 12 being the first available offset afterwards. However, before this commit, mesa incorrectly assumes `var2` must start at offset=16 when using explicit offsets, which results in a compile-time error. Without explicit offsets, the shaders actually work fine, indicating that mesa is already correctly aligning these fields internally. (Just not in the code that handles explicit buffer offset parsing) This patch should fix piglit tests: ssbo-explicit-offset-vec3.vert ubo-explicit-offset-vec3.vert Signed-off-by: Niklas Haas <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* spirv: Add support for SPV_EXT_physical_storage_bufferJason Ekstrand2019-01-265-3/+55
| | | | Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* spirv: Implement OpConvertPtrToU and OpConvertUToPtrJason Ekstrand2019-01-262-2/+75
| | | | | | | This only implements the actual opcodes and does not implement support for using them with specialization constants. Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* spirv: Handle OpTypeForwardPointerJason Ekstrand2019-01-261-33/+66
| | | | | | | | | | | | We handle forward declarations by creating the pointer type with it's storage type based on storage class and just waiting to fill out the actual deref type until we get the OpTypePointer. Because any composites using the forward declared type only care about the storage type (i.e. uint64_t, uvec2, etc.) when creating their glsl_type, this works fine and we can defer the actual deref_type as far as we need. Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Karol Herbst <[email protected]>
* spirv: Drop a bogus assertJason Ekstrand2019-01-261-1/+0
| | | | | | | | | | This was valid back when the only valid types of pointers were uint32 and uvec2. Now that we're allowing more variety, it could be just about anything so we'll just drop the assert. Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Karol Herbst <[email protected]>
* nir: Allow SSBOs and global to aliasJason Ekstrand2019-01-261-1/+6
| | | | Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* nir/validate: Allow array derefs of vectors for nir_var_mem_globalJason Ekstrand2019-01-261-1/+2
| | | | | Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Karol Herbst <[email protected]>
* nir/lower_io: Add support for nir_var_mem_globalJason Ekstrand2019-01-261-0/+12
| | | | | Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Karol Herbst <[email protected]>
* nir/lower_io: Add a 32 and 64-bit global address formatsJason Ekstrand2019-01-262-30/+123
| | | | | | These are simple scalar addresses. Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* nir: Add load/store/atomic global intrinsicsJason Ekstrand2019-01-263-1/+39
| | | | | | | | | These correspond roughly to reading/writing OpenCL global pointers. The idea is that they just take a bare address and load/store from it. Of course, exactly what this address means is driver-dependent. Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Karol Herbst <[email protected]>
* st/nine: Enable debug info if NDEBUG is not setAxel Davy2019-01-2611-26/+26
| | | | | | | | | | We want to have debug info as well if using meson's debugoptimized when ndebug is off. v2: use u_debug functions that do something even if DEBUG is not set. Signed-off-by: Axel Davy <[email protected]>
* st/nine: Immediately upload user provided texturesAxel Davy2019-01-261-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Fixes regression caused by 42d672fa6a766363e5703f119607f7c7975918aa st/nine: Bind src not dst in nine_context_box_upload Before that patch, for user provided textures, when the texture was destroyed, the safety check for pending uploads, which according to the code "Following condition cannot happen currently", was flushing the queue and thus triggering the upload. After the patch, the texture destruction was delayed after the upload. However the user frees the texture buffer, as it thinks the texture released. Instead of reverting the faulty patch, this patch instead flushes the csmt queue right away after queuing the upload for this type of textures. This is more future-proof, as we may want to bind the surface for other reasons in the future. Signed-off-by: Axel Davy <[email protected]> Cc: 18.3 <[email protected]>
* i965: Always compile fp64 funcs when neededMatt Turner2019-01-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compilation of user-specified shaders with software fp64 works by compiling on demand an "fp64-funcs" shader implementing various fp64 operations and then linking it into the "user shader". In commit 64b8c86d37ebb1e1d286c69d642d52b7bcf051d3 Author: Timothy Arceri <[email protected]> Date: Thu Jan 17 17:16:29 2019 +1100 glsl: be much more aggressive when skipping shader compilation we changed the behavior of the shader cache to skip compilation earlier when we get a cache hit. After the aforementioned commit, compiling a user program using fp64 would store into the cache an entry for the fp64-funcs shader. Subsequent compilations of uncached user shaders using fp64 would fail in compile_fp64_funcs() after finding a cache entry for the fp64-funcs, but being unprepared to read from the cache. It's unclear to me how to retrieve the cached NIR of the fp64-funcs (if it even is cached), so just call _mesa_glsl_compile_shader() with force_recompile=true in order to ensure we generate the fp64-funcs successfully. Tested-by: Mark Janes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler: Add a file-level description of brw_eu_validate.cMatt Turner2019-01-261-1/+13
| | | | | | Acked-by: Jose Maria Casanova Crespo <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* freedreno: add renderonly scanoutJonathan Marek2019-01-268-10/+66
| | | | | | | | | | This allows creating a fd_screen with a renderonly object which will be used to allocated scanout resources. Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Eric Anholt <[email protected]> [slight tweak to fix uninitialized 'prsc' in debug print] Signed-off-by: Rob Clark <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 18:24:41 +0000