Okay, so, just to confirm and for future reference, at least in the HLSL compiler we are calling:
"component": To an "atomic", single type that cannot be indexed, i.e. a scalar or an object[1], within another type, at any nesting level.
"element": To one of the outermost parts of another type: * A field within a struct. * An array element within an array. * A column/row within a matrix. * A scalar within a vector. i.e. the resulting type after applying one indexation, going down one nesting level.
---
[1] Textures can be indexed in HLSL, but we are handling those cases as a resource_load/resource_store. I am not sure if this would also apply for Shader Model 5.1 resource arrays.
On 12-08-22 14:06, Zebediah Figura (she/her) wrote:
On 8/11/22 15:26, Francisco Casas wrote:
From: Francisco Casas fcasas@codeweavers.com
Signed-off-by: Francisco Casas fcasas@codeweavers.com
libs/vkd3d-shader/hlsl.c | 17 +++++++++ libs/vkd3d-shader/hlsl.h | 1 + libs/vkd3d-shader/hlsl_codegen.c | 63 ++++++++++++++++++++++++++------ 3 files changed, 69 insertions(+), 12 deletions(-)
Nice :D
+unsigned int hlsl_type_length(const struct hlsl_type *type)
"length" feels a bit ambiguous (I thought for a second it might mean "component count"). How about "element count"? _______________________________________________ wine-gitlab mailing list -- wine-gitlab@winehq.org To unsubscribe send an email to wine-gitlab-leave@winehq.org