- 28 Oct, 2020 40 commits
-
-
-
-
-
-
Reviewed-by:
Jesse Natalie <jenatali@microsoft.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Karol Herbst <kherbst@redhat.com>
Part-of: <mesa/mesa!6472> -
nir_shader::num_inputs isn't supposed to be a count of how many input variables we have. It's a size of the lowered input space. Reviewed-by:
Karol Herbst <kherbst@redhat.com>
Part-of: <mesa/mesa!6472> -
Reviewed-by:
Karol Herbst <kherbst@redhat.com>
Part-of: <mesa/mesa!6472> -
Reviewed-by:
Karol Herbst <kherbst@redhat.com>
Part-of: <mesa/mesa!6472> -
This commit propagates the alignment information provided either through the Alignment decoration on pointers or via the alignment mem operands to OpLoad, OpStore, and OpCopyMemory to the NIR deref chain. It does so by wrapping the deref in a cast. NIR should be able to clean up most unnecessary casts only leaving us with the useful alignment information. Reviewed-by:
-
Reviewed-by:
Karol Herbst <kherbst@redhat.com>
Part-of: <mesa/mesa!6472> -
If we have a cast deref with alignment information and we can get equal or better alignment information from something further up the deref chain, we can strip the alignment information from the cast and allow other optimizations to potentially eliminate the cast. Reviewed-by:
Karol Herbst <kherbst@redhat.com>
Part-of: <mesa/mesa!6472> -
Generally, if a cast has alignment information, that information is useful and we don't want to loose it. Reviewed-by:
Karol Herbst <kherbst@redhat.com>
Part-of: <mesa/mesa!6472> -
If the deref has no explicit alignment in the chain, we assume component alignment which is what we currently assume for all derefs today. This should be correct for all APIs in the sense that we can usually assume at least component alignment. However, for some APIs such as OpenCL, we could potentially make larger alignment assumptions. The intention is that those will be handled via alignment-increasing casts. Reviewed-by:
-
Reviewed-by:
-
This renames it to drop the ptr_as and makes it handle all of the stride cases. There's a bit of a tricky bit in here around Booleans but we currently use 32-bit for those always. Reviewed-by:
-
Reviewed-by:
-
When creating explicit type, the alignment information is lost, thus forcing explicit type users to recalculate the alignment using the same size_align() function. Let's add a new field to cache this information. Only structs, matrices, and vectors have and explicit alignment. Arrays alignment is implicitly set to its element alignment and matrices are required to have an alignment that matches that of its vector columns. the concept of alignment simply doesn't apply to other types. We make the strategic choice to not allow explicit alignments on scalars. This is for a couple of reasons: 1. There are no cases today where we use explicit types where we want any other alignment for scalars than natural alignment. 2. Vectors don't have a component alignment that's separate from the explicit_alignment so it's impossible to get an explicitly aligned scalar type which is the component of the explicitly aligned vector type. This choice may cause problems if we ever want to use explicitly laid out types for things like varyings where we sometimes want vec4 alignment of scalars. We can deal with that when the time comes. Reviewed-by: -
OpenCL doesn't mandate a size and this is consistent with the rest of the glsl_type system. While we're here, we also clean ::cl_size() up a bit and use a new explicit_type_scalar_byte_size() helper. Reviewed-by:
Karol Herbst <kherbst@redhat.com>
Part-of: <mesa/mesa!6472> -
Right now, when calling get_explicit_type_for_size_align() on a packed struct, the packed attribute is lost and field offsets are wrong. Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: -
We need to parse the CPacked decoration early enough to apply it when calculating field offsets and creating the struct type. Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: -
CPacked decoration is only allowed on struct definitions, not struct members. Signed-off-by:
Karol Herbst <kherbst@redhat.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: -
Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!6090> -
-
Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!6090> -
Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!6090> -
Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!6090> -
Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!6090> -
I think these are needed to order the visibility/availability operation with the access. Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!6090> -
The Uniform storage class can be used for SSBOs. This should also fix make available/visible for the Output storage class. Signed-off-by:
Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!6090> -
Add a vtn_get_mem_operands() helper to extract memory operand attached to load/store operations. Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net>
Part-of: <mesa/mesa!6090> -
This reverts commit b62ab035.
-
This reverts commit db131082.
-
This reverts commit f7dd66dd.
-
This reverts commit f0ebc56c.
-
This reverts commit 9f79447d.
-
This reverts commit 2a40b849.
-
This reverts commit 34fa01a2.
-
This reverts commit a539b00b.
-
This reverts commit 1d1105ed.
-
This reverts commit fa36c562.
-
