Kenneth Graunke writes:
> On 11/26/2013 12:02 AM, Francisco Jerez wrote:
> [snip]
>> + add_image_function("imageLoad",
>> + image_builtin_builder(*this)
>> + .emit_stub("__intrinsic_image_load")
>> + .has_return()
>> +
On 11/26/2013 12:02 AM, Francisco Jerez wrote:
[snip]
> + add_image_function("imageLoad",
> + image_builtin_builder(*this)
> + .emit_stub("__intrinsic_image_load")
> + .has_return()
> + .has_vector_data_type()
> +
Paul Berry writes:
>[...]
> I see a few downsides to this approach:
>
> - There is unnecessary code duplication between
> builtin_builder::create_intrinsics() and
> builtin_builder::create_builtins(). Both of them create the same set of
> functions using the same parameters, with the only differ
On 26 November 2013 00:02, Francisco Jerez wrote:
> Because of the combinatorial explosion of different image built-ins
> with different image dimensionalities and base data types, enumerating
> all the 242 possibilities would be annoying and a waste of .text
> space. Instead use a special path
Because of the combinatorial explosion of different image built-ins
with different image dimensionalities and base data types, enumerating
all the 242 possibilities would be annoying and a waste of .text
space. Instead use a special path in the built-in builder that loops
over all the known image