summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* st/mesa: Limit GL_MAX_[NATIVE_]PROGRAM_PARAMETERS_ARB to 2048Kenneth Graunke2019-02-121-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Piglit's vp-max-array test creates a vertex program containing a uniform array sized to the value of GL_MAX_NATIVE_PROGRAM_PARAMETERS_ARB. Mesa will then add additional state-var parameters for things like the MVP matrix. radeonsi currently exposes a value of 4096, derived from constant buffer upload size. This means the array will have 4096 elements, and the extra MVP state-vars would get a prog_src_register::Index of over 4096. Unfortunately, prog_src_register::Index is a signed 13-bit integer, so values beyond 4096 end up turning into negative numbers. Negative source indexes are only valid for relative addressing, so this ends up generating illegal IR. In prog_to_nir, this would cause an out of bounds array access. st_mesa_to_tgsi checks for a negative value, assumes it's bogus, and remaps it to parameter 0 in order to get something in-range. This isn't right - instead of reading the MVP matrix, it would read the first element of the vertex program's large array. But the test only checks that the program compiles, so we never noticed that it was broken. This patch limits the size of the program limits, with the understanding that we may need to generate additional state-vars internally. i965 has exposed 1024 for this limit for years, so I don't expect lowering it to 2048 will cause any practical problems for radeonsi or other drivers. Fixes vp-max-array with prog_to_nir.c. Cc: "19.0" <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Eric Anholt <[email protected]> (cherry picked from commit f45dd6d31b2ff46a082931386ccd0bf043cfad59)
* st/mesa: require RGBA2, RGB4, and RGBA4 to be renderableKarol Herbst2019-02-121-0/+2
| | | | | | | | | | | | | If the driver does not support rendering to these formats but does support texturing, we can end up in incompatibilities between textures and renderbuffers that are then copied to. Fixes KHR-GL45.copy_image.functional on nvc0 Reviewed-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Cc: 19.0 <[email protected]> (cherry picked from commit cbd1ad6165f0aea7fb7c6fd1b36ad5317dd65cb7)
* gallium: add PIPE_CAP_MAX_VARYINGSKarol Herbst2019-02-121-4/+1
| | | | | | | | | | | | | | | | | | | Some NVIDIA hardware can accept 128 fragment shader input components, but only have up to 124 varying-interpolated input components. We add a new cap to express this cleanly. For most drivers, this will have the same value as PIPE_SHADER_CAP_MAX_INPUTS for the fragment shader. Fixes KHR-GL45.limits.max_fragment_input_components Conflicts resolved by Dylan Signed-off-by: Karol Herbst <[email protected]> [imirkin: rebased, improved docs/commit message] Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Rob Clark <[email protected]> Acked-by: Eric Anholt <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Cc: 19.0 <[email protected]> (cherry picked from commit 6010d7b8e8bee1bcea2b329cf6d3b44c5fc3ca66)
* Revert "nir/opt_peephole_select: Don't peephole_select expensive math ↵Dylan Baker2019-02-121-1/+1
| | | | | | | | | | instructions" This reverts commit 378f9967710e9145f2a4f8eee89d87badbe0e6ea. This also remove the default true argument from the a2xx nir backend, which was introduced after this commit. There should be no change in functionality.
* st/mesa: Fix topogun-1.06-orc-84k-resize.trace crashNeha Bhende2019-02-011-0/+4
| | | | | | | | | | | | | | We need to initialize all fields in rs->prim explicitly while creating new rastpos stage. Fixes: bac8534267 ("st/mesa: allow glDrawElements to work with GL_SELECT feedback") v2: Initializing all fields in rs->prim as per Ilia. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]> (cherry picked from commit 69d736b17a96a4d7a21c3c88fd787091acc1def0)
* mesa: Skip partial InvalidateFramebuffer of packed depth/stencil.Eric Anholt2019-01-311-0/+23
| | | | | | | | | | | One of the CTS cases tries to invalidate just stencil of packed depth/stencil, and we incorrectly lost the depth contents. Fixes dEQP-GLES3.functional.fbo.invalidate.whole.unbind_read_stencil Fixes: 0c42b5f3cb90 ("mesa: wire up InvalidateFramebuffer") Reviewed-by: Marek Olšák <[email protected]> (cherry picked from commit db2ae51121067b66d4ee8313ba7f74cecb201a03)
* android,autotools,i965: Fix location of float64_glsl.hDylan Baker2019-01-302-1/+3
| | | | | | | | | | | Android.mk and autotools disagree about where generated files should go, which wasn't a problem until we wanted to build a dist tarball. This corrects the problme by changing the output and include paths to be the same on android and autotools (meson already has the correct include path). Fixes: 7d7b30835cfb9eb89beca9fb8593d0954f79b84d ("automake: Fix path to generated source")
* mesa/st: wire up DiscardFramebufferJonathan Marek2019-01-291-0/+25
| | | | | Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: wire up InvalidateFramebufferRob Clark2019-01-292-7/+66
| | | | | | | | | | And before someone actually starts implementing DiscardFramebuffer() lets rework the interface to something that is actually usable. Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Jonathan Marek <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel/defines: Explicitly cast to uint32_t in SET_FIELD and SET_BITSJason Ekstrand2019-01-291-1/+1
| | | | | | | | | 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]>
* 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]>
* 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]>
* Revert "mesa/main: remove ARB suffix from glGetnTexImage"Emil Velikov2019-01-242-5/+5
| | | | | | | | | | | | | This reverts commit f1998e15ffccf260552bf559abe1a733a8ce990e. This changes the ABI, such that glGetnTexImageARB entry-point from the GLAPI gets removed. Thus accessing many functions by offset (as we do) will result in getting the wrong one. Follow-up work will swap the by-offset handling, but for now revert this patch. Acked-by: Erik Faye-Lund <[email protected]>
* mesa: correctly use os.path.join in our python scriptsEmil Velikov2019-01-241-4/+3
| | | | | | | | | | | | With Windows in mind, using forward slash isn't the right thing to do. Even if it just works, we might want to fix it. As here, use __file__ instead of argv[0] and sys.path.insert over sys.path.append. With the path tweak being reportedly faster. Suggested-by: Dylan Baker <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Erik Faye-Lund <[email protected]>
* st/mesa: fix PRIMITIVES_GENERATED query after the "pipeline stat single" changesMarek Olšák2019-01-231-1/+2
| | | | | | | | | | | | When this functionality was added, the PRIMITIVES_GENERATED query was accidentally omitted. This causes issues for drivers that support transform feedback." Fixes: d644698b443 ("gallium: Add the ability to query a single pipeline statistics counter") Reviewed-by: Erik Faye-Lund <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: purge framebuffers when unbinding a contextMarek Olšák2019-01-231-0/+5
| | | | | | | This fixes pipe_surface "leaks". Cc: 18.3 <[email protected]> Acked-by: Timothy Arceri <[email protected]>
* gallium: Add PIPE_CAP_GLSL_TESS_LEVELS_AS_INPUTSCaio Marcelo de Oliveira Filho2019-01-231-0/+2
| | | | | | | | | | | | In the Intel backend, it makes the most sense to treat gl_TessLevelInner and gl_TessLevelOuter as ordinary shader inputs. For Radeon, it makes more sense to treat them as system values which get special handling. We already have a compiler option for this, but the Iris driver will need a capability bit so we can set it appropriately. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* mesa: add MESA_SHADER_KERNELKarol Herbst2019-01-211-0/+4
| | | | | | | | used for CL kernels Signed-off-by: Karol Herbst <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* nir: rename nir_var_ssbo to nir_var_mem_ssboKarol Herbst2019-01-191-1/+1
| | | | | | | | Signed-off-by: Karol Herbst <[email protected]> Acked-by: Jason Ekstrand <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* nir: rename nir_var_ubo to nir_var_mem_uboKarol Herbst2019-01-191-1/+1
| | | | | | | | Signed-off-by: Karol Herbst <[email protected]> Acked-by: Jason Ekstrand <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* nir: rename nir_var_function to nir_var_function_tempKarol Herbst2019-01-192-2/+2
| | | | | | | | Signed-off-by: Karol Herbst <[email protected]> Acked-by: Jason Ekstrand <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* nir: rename nir_var_private to nir_var_shader_tempKarol Herbst2019-01-191-1/+1
| | | | | | | | Signed-off-by: Karol Herbst <[email protected]> Acked-by: Jason Ekstrand <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* glsl: don't skip GLSL IR opts on first-time compilesTimothy Arceri2019-01-191-2/+1
| | | | | | | | | | | | | | This basically reverts c2bc0aa7b188. By running the opts we reduce memory using in Team Fortress 2 from 1.5GB -> 1.3GB from start-up to game menu. This will likely increase Deus Ex start up times as per commit c2bc0aa7b188. However currently 32bit games like Team Fortress 2 can run out of memory on low memory systems, so that seems more important. Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: Optionally override RGB/RGBX dst alpha blend factorsKenneth Graunke2019-01-155-2/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Intel's blending hardware does not properly return 1.0 for destination alpha for RGBX formats; it requires the factors to be overridden to either zero or one. Broadcom vc4 and v3d also could use this override. While overriding these factors is safe in general, Nouveau and Radeon would prefer not to. Their blending hardware already returns correct values for RGB/RGBX formats, and would like to avoid the resulting per-buffer blending and independent blend factors (rgb != a) since it can cause additional overhead. I considered simply handling this in the driver, but it's not as nice. pipe_blend_state doesn't have any format information, so we'd need the hardware blend state to depend on both pipe_blend_state and pipe_framebuffer_state. Furthermore, Intel GPUs don't have a native RGBX_SNORM format, so I avoid exposing one, which makes Gallium fall back to RGBA_SNORM. The pipe_surfaces we get in the driver have an RGBA format, making it impossible to tell that there shouldn't be an alpha channel. One could argue that st not handling it in that case is a bug. To work around this, we'd have to expose RGBX pipe formats, mapped to RGBA hardware formats, and add format swizzling special cases. All doable, but it ends up being more code than I'd like. st_atom_blend already has access to the right information and it's trivial to accomplish there, so we just add a cap bit and do that. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* gallium: Add the ability to query a single pipeline statistics counterKenneth Graunke2019-01-154-2/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gallium historically has treated pipeline statistics queries as a single query, PIPE_QUERY_PIPELINE_STATISTICS, which returns a block of 11 values. This was originally patterned after the D3D1x API. Much later, Brian introduced an OpenGL extension that exposed these counters - but it exposes 11 separate queries, each of which returns a single value. Today, st/mesa simply queries all 11 values, and returns a single value. While pipeline statistics counters aren't typically performance critical, this is still not a great fit. A D3D1x->GL translator might request all 11 counters by creating 11 separate GL queries...which Gallium would map to reads of all 11 values each time, resulting in a total 121 counter reads. That's not ideal. This patch adds a new cap, PIPE_CAP_QUERY_PIPELINE_STATISTICS_SINGLE, and corresponding query type PIPE_QUERY_PIPELINE_STATISTICS_SINGLE. When calling create_query(), q->index should be set to one of the PIPE_STAT_QUERY_* enums to select a counter. Unlike the block query, this returns the value in pipe_query_result::u64 (as it's a single value) instead of the pipe_query_data_pipeline_statistics group. We update st/mesa to expose ARB_pipeline_statistics_query if either capability is set, preferring the new SINGLE variant when available. Thanks to Roland, Ilia, and Marek for helping me sort this out. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* st/mesa: Rearrange PIPE_QUERY_PIPELINE_STATISTICS result fetching.Kenneth Graunke2019-01-151-43/+45
| | | | | | | | | | | This just changes the order of the switch statements, so we only look at target if the query type is PIPE_QUERY_PIPELINE_STATISTICS. The next commit will introduce a new SINGLE query type which can be used for the same GL query types, and it won't want this processing. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* st/mesa: Make an enum for pipeline statistics query result indices.Kenneth Graunke2019-01-151-11/+11
| | | | | | | | | | | | Gallium handles pipeline statistics queries as a single query (PIPE_QUERY_PIPELINE_STATISTICS) which returns a struct with 11 values. Sometimes it's useful to refer to each of those values individually, rather than as a group. To avoid hardcoding numbers, we define a new enum for each value. Here, the name and enum value correspond to the index in the struct pipe_query_data_pipeline_statistics result. Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* i965: Drop mark_surface_used mechanism.Kenneth Graunke2019-01-133-5/+7
| | | | | | | | | | | | | | | | | | | | | The original idea was that the backend compiler could eliminate surfaces, so we would have it mark which ones are actually used, then shrink the binding table accordingly. Unfortunately, it's a pretty blunt mechanism - it can only prune things from the end, not the middle - since we decide the layout before we even start the backend compiler, and only limit the size. It also basically gives up if it sees indirect array access. Besides, we do the vast majority of our surface elimination in NIR anyway, not the backend - and I don't see that trend changing any time soon. Vulkan abandoned this plan a long time ago, and I don't use it in Iris, but it's still been kicking around in i965. I hacked shader-db to print the binding table size in bytes, and observed no changes with this patch. So, this code appears to do nothing useful. Acked-by: Jason Ekstrand <[email protected]>
* st/nir: Lower TES gl_PatchVerticesIn to a constant if linked with a TCS.Kenneth Graunke2019-01-111-0/+23
| | | | | | | | If the TCS and TES are linked together, we can simply replace the TES's gl_PatchVerticesIn system value with a constant, possibly allowing extra optimization or letting the driver avoid uploading a special value. Reviewed-by: Timothy Arceri <[email protected]>
* blorp: Pass the batch to lookup/upload_shader instead of contextKenneth Graunke2019-01-101-4/+4
| | | | | | | | | This will allow drivers to pin shader buffers if necessary. i965 and anv do not need to do this today, but iris will. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* blorp: Add blorp_get_surface_address to the driver interface.Kenneth Graunke2019-01-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, BLORP expects drivers to provide two functions for dealing with buffers: blorp_emit_reloc and blorp_surface_reloc. Both record a relocation and combine the BO address and offset into a full 64-bit address. Traditionally, blorp_surface_reloc has written that combined address to an implicitly-known buffer where surface states are stored. (In contrast, blorp_emit_reloc returns the value.) The upcoming Iris driver stores surface states in multiple buffers, which makes it impossible for blorp_surface_reloc to write the combined address - it only takes an offset, not the actual buffer to write to. This commit adds a third function, blorp_get_surface_address, which combines and returns an address, which is then passed to ISL's surface state fill functions. Softpin-only drivers can return a real address here and skip writing it in blorp_surface_reloc. Relocation-based drivers are have options. They can simply return 0 from the new function, and continue writing the address from blorp_surface_reloc. Or, they can return a presumed address from blorp_get_surface_address, and have other relocation processing write the real value later. For now, i965 and anv simply return 0. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Compile fp64 funcs only if we do not have 64-bit hardware supportMatt Turner2019-01-101-1/+1
| | | | Brown bag fix...
* intel/isl: move tiled_memcpy static libs from i965 to islTapani Pälli2019-01-1014-1459/+91
| | | | | | | | | | | | | | Patch moves intel_tiled_memcpy[_sse41] libraries to isl, renames some functions and types and makes the required build system changes for meson, automake and Android. No functional changes are introduced. v2: code cleanups, move isl_get_memcpy_type to i965 (Jason) v3: move isl_mem_copy_fn to priv header, cleanups (Jason, Dylan) Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Dylan Baker <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965: Enable 64-bit GLSL extensionsMatt Turner2019-01-091-4/+4
| | | | | | | Now that we have software implementations of ARB_gpu_shader_int64 and ARB_gpu_shader_fp64 we can unconditionally enable these extensions. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Compile fp64 software routines and lower double-opsMatt Turner2019-01-093-1/+63
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Create file to contain software fp64 functionsMatt Turner2019-01-091-0/+1
| | | | | | | The following patches will add implementations of various double-precision operations to this file. Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: don't leak pipe_surface if pipe_context is not currentMarek Olšák2019-01-091-1/+4
| | | | | | | | | | We have found some pipe_surface leaks internally. This is the same code as surface_destroy in radeonsi. Ideally, surface_destroy would be in pipe_screen. Cc: 18.3 <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* st/mesa: don't reference pipe_surface locally in PBO codeMarek Olšák2019-01-091-3/+1
| | | | Reviewed-by: Brian Paul <[email protected]>
* st/mesa: unify window-system renderbuffer initializationMarek Olšák2019-01-093-21/+28
| | | | Reviewed-by: Brian Paul <[email protected]>
* radeon: fix printf format specifier.Maya Rashish2019-01-091-1/+1
| | | | | | | | | | | | From glibc printf(3): Z A nonstandard synonym for z that predates the appearance of z. Do not use in new code. Z may not exist on non-glibc systems. Prefer the standard symbol. Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* nir: rename global/local to private/function memoryKarol Herbst2019-01-082-3/+3
| | | | | | | | | | | | | | | | | | the naming is a bit confusing no matter how you look at it. Within SPIR-V "global" memory is memory accessible from all threads. glsl "global" memory normally refers to shader thread private memory declared at global scope. As we already use "shared" for memory shared across all thrads of a work group the solution where everybody could be happy with is to rename "global" to "private" and use "global" later for memory usually stored within system accessible memory (be it VRAM or system RAM if keeping SVM in mind). glsl "local" memory is memory only accessible within a function, while SPIR-V "local" memory is memory accessible within the same workgroup. v2: rename local to function as well v3: rename vtn_variable_mode_local as well Signed-off-by: Karol Herbst <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* spirv: Sort supported capabilitiesJason Ekstrand2019-01-071-5/+5
| | | | Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* spirv: Add support for using derefs for UBO/SSBO accessJason Ekstrand2019-01-081-0/+1
| | | | | | | | | For now, it's hidden behind a cap. Hopefully, we can eventually drop that along with all the manual offset code in spirv_to_nir. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Tested-by: Bas Nieuwenhuizen <[email protected]>
* nir: Move propagation of cast derefs to a new nir_opt_deref passJason Ekstrand2019-01-081-1/+1
| | | | | | | | | We're going to want to do more deref optimizations going forward and this gives us a central place to do them. Also, cast propagation will get a bit more complicated with the addition of ptr_as_array derefs. Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* glsl_type: Add support for explicitly laid out matrices and arraysJason Ekstrand2019-01-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | SPIR-V allows for matrix and array types to be decorated with explicit byte stride decorations and matrix types to be decorated row- or column-major. This commit adds support to glsl_type to encode this information. Because this doesn't work nicely with std430 and std140 alignments, we add asserts to ensure that we don't use any of the std430 or std140 layout functions with explicitly laid out types. In SPIR-V, the layout information for matrices is applied to the parent struct member instead of to the matrix type itself. However, this is gets rather clumsy when you're walking derefs trying to compute offsets because, the moment you hit a matrix, you have to crawl back the deref chain and find the struct. Instead, we take the same path here as we've taken in spirv_to_nir and put the decorations on the matrix type itself. This also subtly adds support for strided vector types. These don't come up in SPIR-V directly but you can get one as the result of taking a column from a row-major matrix or a row from a column-major matrix. Reviewed-by: Alejandro Piñeiro <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 18:22:13 +0000