wine/vkd3d
0
0
Fork 0
mirror of https://gitlab.winehq.org/wine/vkd3d.git synced 2025-09-12 18:50:22 -07:00
Code Issues Packages Projects Releases Wiki Activity

vkd3d-shader/hlsl: Store function overloads in a list.

Browse Source 
The choice to store them in an rbtree was made early on. It does not seem likely
that HLSL programs would define many overloads for any of their functions, but I
suspect the idea was rather that intrinsics would be defined as plain
hlsl_ir_function_decl structures [cf. 447463e590]
and that some intrinsics that could operate on any type would therefore need
many overrides.

This is not how we deal with intrinsics, however. When the first intrinsics were
implemented I made the choice disregard this intended design, and instead match
and convert their types manually, in C. Nothing that has happened in the time
since has led me to question that choice, and in fact, the flexibility with
which we must accommodate functions has led me to believe that matching in this
way was definitely the right choice. The main other designs I see would have
been:

* define each intrinsic variant separately using existing HLSL types. Besides
  efficiency concerns (i.e. this would take more space in memory, and would take
  longer to generate each variant), the normal type-matching rules don't really
  apply to intrinsics.

  [For example: elementwise intrinsics like abs() return the same type as the
  input, including preserving the distinction between float and float1. It is
  legal to define separate HLSL overloads taking float and float1, but trying to
  invoke these functions yields an "ambiguous function call" error.]

* introduce new (semi-)generic types. This is far more code and ends up acting
  like our current scheme (with helpers) in a slightly more complex form.

So I think we can go ahead and rip out this vestige of the original design for
intrinsics.

As for why to change it: rbtrees are simply more complex to deal with, and it
seems unlikely to me that the difference is going to matter. I do not expect any
program to define large quantities of intrinsics; linked list search should be
good enough.
This commit is contained in:
Zebediah Figura
2023-09-08 16:27:10 -05:00
committed by Alexandre Julliard
parent 2b59a759d5
commit b1c2852cd7
Notes: Alexandre Julliard 2023-11-10 00:10:07 +01:00 
Approved-by: Giovanni Mascellani (@giomasce)
Approved-by: Henri Verbeet (@hverbeet)
Approved-by: Alexandre Julliard (@julliard)
Merge-Request: https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/454
4 changed files with 69 additions and 83 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
libs/vkd3d-shader/hlsl.h
View File

@@ -450,7 +450,7 @@ struct hlsl_ir_function
const char *name;
/* Tree containing function definitions, stored as hlsl_ir_function_decl structures, which would
* be more than one in case of function overloading. */
struct rb_tree overloads;
struct list overloads;
};
struct hlsl_ir_function_decl
@@ -460,8 +460,8 @@ struct hlsl_ir_function_decl
struct hlsl_ir_var *return_var;
struct vkd3d_shader_location loc;
/* Item entry in hlsl_ir_function.overloads. The parameters' types are used as key. */
struct rb_entry entry;
/* Item entry in hlsl_ir_function.overloads. */
struct list entry;
/* Function to which this declaration corresponds. */
struct hlsl_ir_function *func;
@@ -1173,6 +1173,8 @@ void hlsl_free_var(struct hlsl_ir_var *decl);
struct hlsl_ir_function *hlsl_get_function(struct hlsl_ctx *ctx, const char *name);
struct hlsl_ir_function_decl *hlsl_get_first_func_decl(struct hlsl_ctx *ctx, const char *name);
struct hlsl_ir_function_decl *hlsl_get_func_decl(struct hlsl_ctx *ctx, const char *name,
const struct hlsl_func_parameters *parameters);
const struct hlsl_profile_info *hlsl_get_target_info(const char *target);
struct hlsl_type *hlsl_get_type(struct hlsl_scope *scope, const char *name, bool recursive, bool case_insensitive);
struct hlsl_ir_var *hlsl_get_var(struct hlsl_scope *scope, const char *name);