Steven Johnson comments

Results 456 comments of


                                            Steven Johnson

There is no way to declare Halide::Runtime::Buffer<float16>

Did this get addressed as part of https://github.com/halide/Halide/pull/3667?

There is no way to declare Halide::Runtime::Buffer<float16>

Could we just add types to `HalideRuntime.h` that are strictly proxies for halide_type_of() for float16 and bfloat16?

There is no way to declare Halide::Runtime::Buffer<float16>

> We could consider making the float16 implementation in Float16.h/Float16.cpp part of the runtime too. Yeah, but that would require adding a fair amount of new runtime API surface area...

Require an autoscheduler for build_gradient_module()/GRADIENT_DESCENT

> If you're asking for the derivative of an element wise thing (e.g. a generator that just does relu), then requiring an autoscheduler to run is a bit ridiculous. Is...

Require an autoscheduler for build_gradient_module()/GRADIENT_DESCENT

Part of the footgun here is that you can ask for this on any arbitrary Generator and we'll try our best; while looking at https://github.com/halide/Halide/issues/8393 I just modified the Python...

Integrating with OSS-Fuzz

> We could ignore the inputs that the fuzzers give us and just generate a batch of other inputs Or use the inputs to form a seed for our "fuzzer"...

Integrating with OSS-Fuzz

Has anything ever come of this?

halide 18.0.0: `FTBFS on arm64 with SVE: Unhandled exception: Error: For SVE/SVE2 support, target_vector_bits=<size> must be set in target``

> Likely the answer is to not turn on any SVE features automatically for compilation +1

GPU tutorials (12 & 19) fail on arm32

When I last looked at this I thought the 'right' fix was to update our code to use the newer __atomic primitives instead of the older __sync ones, but that...

Consider using llvm.vector.insert and llvm.vector.extract in slice_vector.

Is this still relevant, given that the SVE2 branch has landed?