summaryrefslogtreecommitdiffstats
path: root/src/compiler/spirv
Commit message (Collapse)AuthorAgeFilesLines
* spirv/nir: Add support for SPV_KHR_8bit_storageJose Maria Casanova Crespo2018-07-101-0/+6
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* spirv: Include headers and grammar for SPV_KHR_8bit_storageJose Maria Casanova Crespo2018-07-102-7/+40
| | | | | | Updates headers and grammar to ff684ffc6a35d2a58f0f63108877d0064ea33feb Acked-by: Jason Ekstrand <[email protected]>
* nir: Fix OpAtomicCounterIDecrement for uniform atomic countersAntia Puentes2018-07-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From the SPIR-V 1.0 specification, section 3.32.18, "Atomic Instructions": "OpAtomicIDecrement: <skip> The instruction's result is the Original Value." However, we were implementing it, for uniform atomic counters, as a pre-decrement operation, as was the one available from GLSL. Renamed the former nir intrinsic 'atomic_counter_dec*' to 'atomic_counter_pre_dec*' for clarification purposes, as it implements a pre-decrement operation as specified for GLSL. From GLSL 4.50 spec, section 8.10, "Atomic Counter Functions": "uint atomicCounterDecrement (atomic_uint c) Atomically 1. decrements the counter for c, and 2. returns the value resulting from the decrement operation. These two steps are done atomically with respect to the atomic counter functions in this table." Added a new nir intrinsic 'atomic_counter_post_dec*' which implements a post-decrement operation as required by SPIR-V. v2: (Timothy Arceri) * Add extra spec quotes on commit message * Use "post" instead "pos" to avoid confusion with "position" Signed-off-by: Antia Puentes <[email protected]> Signed-off-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* spirv/nir: add capability check for SpvCapabilityAtomicStorageAlejandro Piñeiro2018-07-031-1/+4
| | | | | | | | | | | | | | | | | Capability that informs if atomic counters are supported. From SPIR-V 1.0 spec, section 3.7, "Storage Class", item 10 from table: (Column "Storage Class"): "AtomicCounter For holding atomic counters. Visible across all functions of the current invocation. Atomic counter-specific memory." (Column "Required Capability"): "AtomicStorage" Reviewed-by: Timothy Arceri <[email protected]>
* spirv/nir: add atomic counter support on vtn_handle_ssbo_or_shared_atomicAlejandro Piñeiro2018-07-031-6/+84
| | | | | | So renamed to a more general vtn_handle_atomics Reviewed-by: Timothy Arceri <[email protected]>
* spirv/nir: initialize offset on the nir var at vtn_create_variableAlejandro Piñeiro2018-07-031-0/+1
| | | | | | | This is convenient when dealing with atomic counter uniforms. The alternative would be doing that at vtn_handle_atomics. Reviewed-by: Timothy Arceri <[email protected]>
* nir/spirv: Fix atomic counter (multidimensional-)arraysAntia Puentes2018-07-031-3/+24
| | | | | | | | | | | | | | | | | | | | When constructing NIR if we have a SPIR-V uint variable and the storage class is SpvStorageClassAtomicCounter, we store as NIR's glsl_type an atomic_uint to reflect the fact that the variable is an atomic counter. However, we were tweaking the type only for atomic_uint scalars, we have to do it as well for atomic_uint arrays and atomic_uint arrays of arrays of any depth. Signed-off-by: Antia Puentes <[email protected]> Signed-off-by: Alejandro Piñeiro <[email protected]> v2: update after deref patches got pushed (Alejandro Piñeiro) v3: simplify repair_atomic_type (suggested by Timothy Arceri, included on the patch by Alejandro) Reviewed-by: Timothy Arceri <[email protected]>
* spirv/nir: tweak nir type when storage class is SpvStorageClassAtomicCounterAlejandro Piñeiro2018-07-031-1/+11
| | | | | | | | | | | | | GLSL types differentiates uint from atomic uint. On SPIR-V the type is uint, and the variable has a specific storage class. So we need to tweak the type based on the storage class. Ideally we would like to get the proper type at vtn_handle_type, but we don't have the storage class at that moment. We tweak only the nir type, as is the one that really requires it. Reviewed-by: Timothy Arceri <[email protected]>
* spirv/nir: add offset at vtn_variableAlejandro Piñeiro2018-07-032-0/+4
| | | | | | | | | Also initialize it on var_decoration_cb This is equivalent to nir_variable.offset, used to store the location an atomic counter is stored at. Reviewed-by: Timothy Arceri <[email protected]>
* spirv/nir: SpvStorageClassAtomicCounter support on vtn_storage_class_to_modeAlejandro Piñeiro2018-07-031-1/+4
| | | | | | Atomic Counters are uniforms per spec. Reviewed-by: Timothy Arceri <[email protected]>
* nir,spirv: Rework function callsJason Ekstrand2018-06-224-156/+141
| | | | | | | | | | | | | | | | | | | | | | | | | | This commit completely reworks function calls in NIR. Instead of having a set of variables for the parameters and return value, nir_call_instr now has simply has a number of sources which get mapped to load_param intrinsics inside the functions. It's up to the client API to build an ABI on top of that. In SPIR-V, out parameters are handled by passing the result of a deref through as an SSA value and storing to it. This virtue of this approach can be seen by how much it allows us to delete from core NIR. In particular, nir_inline_functions gets halved and goes from a fairly difficult pass to understand in detail to almost trivial. It also simplifies spirv_to_nir somewhat because NIR functions never were a good fit for SPIR-V. Unfortunately, there is no good way to do this without a mega-commit. Core NIR and SPIR-V have to be changed at the same time. This also requires changes to anv and radv because nir_inline_functions couldn't handle deref instructions before this change and can't work without them after this change. Acked-by: Rob Clark <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* spirv/cfg: Make the builder fully capable for both walksJason Ekstrand2018-06-221-0/+2
| | | | | | | | | | | | | | We were only initializing vtn_builder::func for the pre-walk where we build the CFG. We were only initializing the nir_builder for the later walk through the instructions even though were were setting b->cursor for the pre-walk. Let's set both both places so that everything is consistent. This useful because we handle OpFunctionParameter in the pre-walk and we're going to need to be able to emit instructions. Acked-by: Rob Clark <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* spirv: Record the type of functionsJason Ekstrand2018-06-222-2/+4
| | | | | | | Acked-by: Rob Clark <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* spirv: Update vtn_pointer_to/from_ssa to handle deref pointersJason Ekstrand2018-06-221-31/+42
| | | | | | | | | | Now that pointers can be derefs and derefs just produce SSA values, we can convert any pointer to/from SSA. Acked-by: Rob Clark <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* spirv: Allow pointers to have a deref at the baseJason Ekstrand2018-06-222-43/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, pointers fell into two categories: index/offset for UBOs, SSBOs, etc. and var + access chain for logical pointers. This commit adds another logical pointer mode that's deref + access chain. It's tempting to think that we can just replace variable-based pointers with deref-based or at least replace the access chain with a deref chain. Unfortunately, there are a few sticky bits that prevent this: 1) We can't return deref-based pointers from OpVariable because those opcodes may come outside of a function so there's no place to emit the deref instructions. 2) We can't always use variable-based pointers because we may not always know the variable. (We do now, but he upcoming function rework will take that option away.) 3) We also can't replace the access chain struct with a deref. Due to the re-ordering we do in order to handle loop continues, the derefs we would emit as part of OpAccessChain may not dominate their uses. We normally fix this up with nir_repair_ssa but that generates phi nodes which we don't want in the middle of our deref chains. All in all, we have no real better option than to support partial access chains while also re-emitting the deref instructions on the spot. Acked-by: Rob Clark <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* spirv: Clean up vtn_pointer_to_offsetJason Ekstrand2018-06-223-77/+16
| | | | | | | | | | Now that push constants are using on-the-fly offsets, we no longer need to handle access chains in vtn_pointer_to_offset. Acked-by: Rob Clark <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* spirv: Make push constants an offset-based pointerJason Ekstrand2018-06-222-28/+17
| | | | | | | | | | | | | | | | | | Push constants have been a weird edge-case for a while in that they have explitic offsets but we've been internally building access chains for them. This mostly works but it means that passing pointers to push constants through as function arguments is broken. The easy thing to do for now is to just treat them like UBOs or SSBOs only without a block index. This does loose a bit of information since we no longer have an accurate access range and any indirect access will look like it could read the whole block. Unfortunately, there's not much we can do about that. Once NIR derefs get a bit more powerful, we can plumb these through as derefs and be able to reason about them again. Acked-by: Rob Clark <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* spirv: Use NIR per-member splittingJason Ekstrand2018-06-222-109/+38
| | | | | | | | | | | | Before, we were doing structure splitting in spirv_to_nir. Unfortunately, this doesn't really work when you think about passing struct pointers into functions. Doing it later in NIR is a much better plan. Acked-by: Rob Clark <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* nir/spirv: Pass nir_variable_data into apply_var_decorationJason Ekstrand2018-06-221-26/+26
| | | | | | | Acked-by: Rob Clark <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* spirv: Use deref instructions for most variablesJason Ekstrand2018-06-225-190/+184
| | | | | | | | | The only thing still using old-school drefs are function calls. Acked-by: Rob Clark <[email protected]> Acked-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* spirv: Set nir_variable->explicit_bindingNeil Roberts2018-06-212-0/+3
| | | | | | | | | When SpvDecorationBinding is encountered in the SPIR-V source it now sets explicit_binding on the nir_variable. This will be used to determine whether to initialise sampler and image uniforms with the binding value. Reviewed-by: Timothy Arceri <[email protected]>
* spirv: Get rid of vtn_variable_mode_image/samplerNeil Roberts2018-06-214-37/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vtn_variable_mode_image and _sampler are instead replaced with vtn_variable_mode_uniform which encompasses both of them. In the few places where it was neccessary to distinguish between the two, the GLSL type of the pointer is used instead. The main reason to do this is that on OpenGL it is permitted to put images and samplers into structs and declare a uniform with them. That means that variables can now have a mix of uniform, sampler and image modes so picking a single one of those modes for a variable no longer makes sense. This fixes OpLoad on a sampler within a struct which was previously using the variable mode to determine whether it was a sampler or not. The type of the variable is a struct so it was not being considered to be uniform mode even though the member being loaded should be sampler mode. The previous code appeared to be using var->interface_type as a place to store the type of the variable without the enclosing array for images and samplers. I guess this worked because opaque types can not appear in interfaces so the interface_type is sort of unused. This patch removes the overloading of var->interface_type and any places that needed the type without the array can now just deduce it from var->type. v2: squash in this patch the changes to anv/nir (Timothy) Signed-off-by: Eduardo Lima <[email protected]> Signed-off-by: Neil Roberts <[email protected] Signed-off-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* spirv: translate default-block uniformsNicolai Hähnle2018-06-212-10/+16
| | | | | | | | | | | | | | | | | | They are supported by SPIR-V for ARB_gl_spirv. v2 (changes on top of Nicolai's original patch): * Handle UniformConstant storage class for uniforms other than samplers and images. (Eduardo Lima) * Handle location decoration also for samplers and images. (Eduardo Lima) * Rebase update (spirv_to_nir options added, logging changes, and others) (Alejandro Piñeiro) Signed-off-by: Nicolai Hähnle <[email protected]> Signed-off-by: Eduardo Lima <[email protected]> Signed-off-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* spirv: add/hookup SpvCapabilityStencilExportEXTGustavo Lima Chaves2018-06-082-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v2: An attempt to support SpvExecutionModeStencilRefReplacingEXT's behavior also follows, with the interpretation to said mode being we prevent writes to the built-in FragStencilRefEXT variable when the execution mode isn't set. v3: A more cautious reading of 1db44252d01bf7539452ccc2b5210c74b8dcd573 led me to a missing change that would stop (what I later discovered were) GPU hangs on the CTS test written to exercise this. v4: Turn FragStencilRefEXT decoration usage without StencilRefReplacingEXT mode into a warning, instead of trying to make the variable read-only. If we are to follow the originating extension on GL, the built-in variable in question should never be readable anyway. v5/v6: rebases. v7: Fix check for gen9 lost in rebase. (Ilia) Reduce the scope of the bool used to track whether SpvExecutionModeStencilRefReplacingEXT was used. Was in shader_info, moved to vtn_builder. (Jason) v8: Assert for fragment shader handling StencilRefReplacingEXT execution mode. (Caio) Remove warning logic, since an entry point might not have StencilRefReplacingEXT execution mode, but the global output variable might still exist for another entry point in the module. (Jason) Reviewed-by: Jason Ekstrand <[email protected]>
* compiler/spirv: reject invalid shader code properlyMartin Pelikán2018-06-012-5/+38
| | | | | | | | | | After bebe3d626e5, b->fail_jump is prepared after vtn_create_builder which can longjmp(3) to it through its vtx_assert()s. This corrupts the stack and creates confusing core dumps, so we need to avoid it. While there, I decided to print the offending values for debugability. Reviewed-by: Jason Ekstrand <[email protected]>
* spirv: fix visiting inner loops with same break/continue blockSamuel Pitoiset2018-05-151-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | We should stop walking through the CFG when the inner loop's break block ends up as the same block as the outer loop's continue block because we are already going to visit it. This fixes the following assertion which ends up by crashing in RADV or ANV: SPIR-V parsing FAILED: In file ../src/compiler/spirv/vtn_cfg.c:381 block->node.link.next == NULL 0 bytes into the SPIR-V binary This also fixes a crash with a camera shader from SteamVR. v2: make use of vtn_get_branch_type() and add an assertion Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106090 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106504 CC: 18.0 18.1 <[email protected]> Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* compiler/spirv: add implementation to check for SpvCapabilityInt16 supportIago Toral Quiroga2018-05-031-1/+3
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* compiler/spirv: implement 16-bit bitcastsIago Toral Quiroga2018-05-031-9/+22
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* spirv: Apply OriginUpperLeft to FragCoordNeil Roberts2018-05-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This behaviour was changed in 1e5b09f42f694687ac. The commit message for that says it is just a “tidy up” so my assumption is that the behaviour change was a mistake. It’s a little hard to decipher looking at the diff, but the previous code before that patch was: if (builtin == SpvBuiltInFragCoord || builtin == SpvBuiltInSamplePosition) nir_var->data.origin_upper_left = b->origin_upper_left; if (builtin == SpvBuiltInFragCoord) nir_var->data.pixel_center_integer = b->pixel_center_integer; After the patch the code was: case SpvBuiltInSamplePosition: nir_var->data.origin_upper_left = b->origin_upper_left; /* fallthrough */ case SpvBuiltInFragCoord: nir_var->data.pixel_center_integer = b->pixel_center_integer; break; Before the patch origin_upper_left affected both builtins and pixel_center_integer only affected FragCoord. After the patch origin_upper_left only affects SamplePosition and pixel_center_integer affects both variables. This patch tries to restore the previous behaviour by changing the code to: case SpvBuiltInFragCoord: nir_var->data.pixel_center_integer = b->pixel_center_integer; /* fallthrough */ case SpvBuiltInSamplePosition: nir_var->data.origin_upper_left = b->origin_upper_left; break; This change will be important for ARB_gl_spirv which is meant to support OriginLowerLeft. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Fixes: 1e5b09f42f694687ac "spirv: Tidy some repeated if checks..."
* spirv: convert some operands for bitwise shift and bitwise ops to uint32Samuel Iglesias Gonsálvez2018-05-031-0/+35
| | | | | | | | | | | | | | | | | SPIR-V allows to define the shift, offset and count operands for shift and bitfield opcodes with a bit-size different than 32 bits, but in NIR the opcodes have that limitation. As agreed in the mailing list, this patch adds a conversion to 32 bits to fix this. For more info, see: https://lists.freedesktop.org/archives/mesa-dev/2018-April/193026.html v2: - src_bit_size will have zero value for variable bit-size operands (Jason). Signed-off-by: Samuel Iglesias Gonsálvez <[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]>
* spirv: Lower BaseVertex to FIRST_VERTEX instead of BASE_VERTEXNeil Roberts2018-04-191-1/+4
| | | | | | | | | | | | | The base vertex in Vulkan is different from GL in that for non-indexed primitives the value is taken from the firstVertex parameter instead of being set to zero. This coincides with the new SYSTEM_VALUE_FIRST_VERTEX instead of BASE_VERTEX. v2 (idr): Add comment describing why SYSTEM_VALUE_FIRST_VERTEX is used for SpvBuiltInBaseVertex. Suggested by Jason. Reviewed-by: Ian Romanick <[email protected]> [v1] Reviewed-by: Jason Ekstrand <[email protected]>
* spirv: Add support for runtime descriptor array cap.Bas Nieuwenhuizen2018-04-181-0/+4
| | | | Reviewed-by: Samuel Pitoiset <[email protected]>
* spirv: Add support for VK_EXT_descriptor_indexing uniform indexing caps.Bas Nieuwenhuizen2018-04-181-0/+6
| | | | Reviewed-by: Samuel Pitoiset <[email protected]>
* spirv: Update spirv.h to 12f8de9f04327336b699b1b80aa390ae7f9ddbf4Bas Nieuwenhuizen2018-04-182-4/+183
| | | | Acked-by: Samuel Pitoiset <[email protected]>
* spirv: Accept doubles in FaceForward, Reflect and RefractNeil Roberts2018-04-171-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | The SPIR-V spec doesn’t specify a size requirement for these and the equivalent functions in the GLSL spec have explicit alternatives for doubles. Refract is a little bit more complicated due to the fact that the final argument is always supposed to be a scalar 32- or 16- bit float regardless of the other operands. However in practice it seems there is a bug in glslang that makes it convert the argument to 64-bit if you actually try to pass it a 32-bit value while the other arguments are 64-bit. This adds an optional conversion of the final argument in order to support any type. These have been tested against the automatically generated tests of glsl-4.00/execution/built-in-functions using the ARB_gl_spirv branch which tests it with quite a large range of combinations. The issue with glslang has been filed here: https://github.com/KhronosGroup/glslang/issues/1279 v2: Convert the eta operand of Refract from any size in order to make it eventually cope with 16-bit floats. Reviewed-by: Jason Ekstrand <[email protected]>
* spirv: Add a 64-bit implementation of OpIsInfNeil Roberts2018-04-171-3/+4
| | | | | | | | | | | | The only change neccessary is to change the type of the constant used to compare against. This has been tested against the arb_gpu_shader_fp64/execution/ fs-isinf-dvec tests using the ARB_gl_spirv branch. v2: Use nir_imm_floatN_t for the constant. Reviewed-by: Jason Ekstrand <[email protected]>
* spirv: Use nir_imm_floatN_t for constants for GLSL450 builtinsNeil Roberts2018-04-171-1/+1
| | | | | | | | | | There is an existing macro that is used to choose between either a float or a double immediate constant based on the bit size of the first operand to the builtin. This is now changed to use the new nir_imm_floatN_t helper function to reduce the number of places that make this decision. Reviewed-by: Jason Ekstrand <[email protected]>
* nir/spirv: Fix warning and add missing breaks.Daniel Schürmann2018-04-142-0/+4
| | | | | Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* spirv: Use the LOCAL_GROUP_SIZE system valueJason Ekstrand2018-04-091-15/+2
| | | | Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* compiler/spirv: set is_shadow for depth comparitor sampling opcodesIago Toral Quiroga2018-04-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | From the SPIR-V spec, OpTypeImage: "Depth is whether or not this image is a depth image. (Note that whether or not depth comparisons are actually done is a property of the sampling opcode, not of this type declaration.)" The sampling opcodes that specify depth comparisons are OpImageSample{Proj}Dref{Explicit,Implicit}Lod, so we should set is_shadow only for these (we were using the deph property of the image until now). v2: - Do the same for OpImageDrefGather. - Set is_shadow to false if the sampling opcode is not one of these (Jason) - Reuse an existing switch statement instead of adding a new one (Jason) Fixes crashes in: dEQP-VK.spirv_assembly.instruction.graphics.image_sampler.depth_property.* Reviewed-by: Jason Ekstrand <[email protected]> Cc: [email protected]
* nir+drivers: add helpers to get # of src/dest componentsRob Clark2018-04-031-2/+1
| | | | | | | | | Add helpers to get the number of src/dest components for an intrinsic, and update spots that were open-coding this logic to use the helpers instead. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* spirv: s/uint/unsigned/ to fix MSVC buildBrian Paul2018-03-301-1/+1
| | | | Reviewed-by: Neil Roberts <[email protected]>
* nir/spirv: s/uint32_t/SpvOp/ in various functionsBrian Paul2018-03-303-7/+7
| | | | | | | | | | The MSVC compiler warns when the function parameter types don't exactly match with respect to enum vs. uint32_t. Use SpvOp everywhere. Alternately, uint32_t could be used everywhere. There doesn't seem to be an advantage to one over the other. Reviewed-by: Neil Roberts <[email protected]>
* nir/spirv: fix MSVC syntax error in vtn_handle_texture()Brian Paul2018-03-301-1/+2
| | | | Reviewed-by: Neil Roberts <[email protected]>
* nir/spirv: move NORETURN annotation on _vtn_fail() prototypeBrian Paul2018-03-301-2/+4
| | | | | | | This needs to before the function, not after, to compile with MSVC. This works with gcc too. Reviewed-by: Neil Roberts <[email protected]>
* nir/spirv: fix MSVC warning in vtn_align_u32()Brian Paul2018-03-301-1/+1
| | | | | | | Fixes warning that "negation of an unsigned value results in an unsigned value". Reviewed-by: Neil Roberts <[email protected]>
* nir/spirv: add gl_spirv_validation methodAlejandro Piñeiro2018-03-304-14/+303
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ARB_gl_spirv adds the ability to use SPIR-V binaries, and a new method, glSpecializeShader. Here we add a new function to do the validation for this function: From OpenGL 4.6 spec, section 7.2.1" "Shader Specialization", error table: INVALID_VALUE is generated if <pEntryPoint> does not name a valid entry point for <shader>. INVALID_VALUE is generated if any element of <pConstantIndex> refers to a specialization constant that does not exist in the shader module contained in <shader>."" v2: rebase update (spirv_to_nir options added, changes on the warning logging, and others) v3: include passing options on common initialization, doesn't call setjmp on common_initialization v4: (after Jason comments): * Rename common_initialization to vtn_builder_create * Move validation method and their helpers to own source file. * Create own handle_constant_decoration_cb instead of reuse existing one v5: put vtn_build_create refactoring to their own patch (Jason) v6: update after vtn_builder_create method renamed, add explanatory comment, tweak existing comment and commit message (Timothy)
* spirv: add vtn_create_builderAlejandro Piñeiro2018-03-302-17/+38
| | | | | | | | | Refactored from spirv_to_nir, in order to be reused later. Reviewed-by: Timothy Arceri <[email protected]> v2: renamed method (from vtn_builder_create), add explanatory comment (Timothy)
* spirv: Move SPIR-V building to Makefile.spirv.am and spirv/meson.buildIan Romanick2018-03-291-0/+33
| | | | | | | | | | | | | Future changes will add generated files used only from src/compiler/glsl. These can't be built from Makefile.nir.am, and we can't move all the rules from Makefile.nir.am to Makefile.spirv.am (and it would be silly anyway). v2: Do it for meson too. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> (the meson bits) Reviewed-by: Alejandro Piñeiro <[email protected]> (the automake bits)
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-21 00:10:11 +0000