Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 20:48
    steven-johnson synchronize #6553
  • 20:48

    steven-johnson on static-buffer-dims

    Update Generator.h (compare)

  • 20:04
    steven-johnson synchronize #6553
  • 20:04

    steven-johnson on static-buffer-dims

    Update Generator.h (compare)

  • 19:57
    zvookin commented #6568
  • 19:48
    abadams synchronize #6568
  • 19:48

    abadams on deprecate_output

    OutputFile -> OutputType Also … (compare)

  • 19:16
    abadams review_requested #6568
  • 19:16
    abadams opened #6568
  • 19:16

    abadams on deprecate_output

    Rename Output to OutputFile and… (compare)

  • 17:45

    steven-johnson on xt+statbuf

    Merge branch 'srj/static-buffer… (compare)

  • 17:14

    steven-johnson on xtensa-codegen

    Fix deprecation warnings in Pyt… Use add_halide_generator() ever… Fix for top-of-tree LLVM (#6561… and 6 more (compare)

  • 17:08
    steven-johnson synchronize #6553
  • 17:08

    steven-johnson on static-buffer-dims

    Update templated_generator.cpp (compare)

  • 16:48
    steven-johnson synchronize #6553
  • 16:48

    steven-johnson on static-buffer-dims

    Make HALIDE_REGISTER_GENERATOR … Enable simd_op_check test for w… Revert "Fix for top-of-tree LLV… and 3 more (compare)

  • Jan 18 23:21
    steven-johnson synchronize #6567
  • Jan 18 23:21

    steven-johnson on simd-op

    clang-format (compare)

  • Jan 18 23:04
    steven-johnson synchronize #6567
  • Jan 18 23:04

    steven-johnson on simd-op

    Update simd_op_check.cpp (compare)

Ashish Uthama
@ashishUthama
I would like to too .. but not sure how to proceed :( I checked the definition in VS and it correctly opened up that header
These are our cmake flags:
51 CMAKE_HALIDE_OPTIONS:= \
52 -DLLVM_DIR=${LLVM_ROOT}/release/lib/cmake/llvm \
53 -DCLANG=${CLANG} \
54 -DWARNINGS_AS_ERRORS=OFF \
55 -DWITH_PYTHON_BINDINGS=OFF \
56 -DWITH_TEST_AUTO_SCHEDULE=ON \
57 -DWITH_TEST_CORRECTNESS=OFF \
58 -DWITH_TEST_ERROR=ON \
59 -DWITH_TEST_WARNING=ON \
60 -DWITH_TEST_PERFORMANCE=ON \
61 -DWITH_TEST_OPENGL=OFF \
62 -DWITH_TEST_GENERATOR=ON \
63 -DWITH_APPS=OFF \
64 -DWITH_TUTORIALS=OFF \
65 -DWITH_DOCS=OFF \
66 -DWITH_UTILS=OFF .
oh, llvm - ok, likely that. Will double check, it might be that our in house llvm build has limited targets.
Alex Reinking
@alexreinking:matrix.org
[m]
That would make sense. Our binaries contain all supported backends
Ashish Uthama
@ashishUthama
yes, that explains it.Thanks! And -- thanks for the push to versioned regular releases, Much appreciated!
Alex Reinking
@alexreinking:matrix.org
[m]
Totally! Hopefully we'll be able to get the release latency (after LLVM) even tighter for the next releases :)
Derek Gerstmann
@derek-gerstmann
@alexreinking:matrix.org Hiya! I'm looking at backporting PR #6405 from master to create a v13.0.1 release. Should I create a "backports/13.x" branch and merge things in there, and then push the results into "releases/13.x"? Just trying to match what Andrew and I are seeing in the repo to follow conventions. Any suggestions?
Alex Reinking
@alexreinking:matrix.org
[m]
I use backports/N.x for staging changes to release/N.x. When it's ready, I open a PR with release/N.x as the target branch. There is CI set up for this scenario. Be sure to include a commit that bumps the version to 13.0.1.
release/N.x is (or ought to be) protected (like master), so you can't push to it
Derek Gerstmann
@derek-gerstmann
Ahh ... okay cool! Does the "release/N.x" branch itself get created automatically?
Alex Reinking
@alexreinking:matrix.org
[m]
No. When creating a new major release, we fork it off of master.
Derek Gerstmann
@derek-gerstmann
Makes sense! Okay, I'll work on getting things merged! Thanks!
Alex Reinking
@alexreinking:matrix.org
[m]
Also, I prefer to not squash commits from backports/N.x into release/N.x. I think the cherry-picking history is valuable (as are any separate/additional patches necessary to correctly backport) as is keeping the version number bump separate.
No problem! Happy to share the release responsibility :)
Derek Gerstmann
@derek-gerstmann
Cool. Yeah, I'm the same. I rarely squash commits unless there's a really good reason to.
Sweet! Happy to help! :)
Alex Reinking
@alexreinking:matrix.org
[m]
I bring it up because the repository default PR-merge mode is to squash
Derek Gerstmann
@derek-gerstmann
Oooh, good to know! I'll turn it off for the release PR. Thanks for the heads up!
Alex Reinking
@alexreinking:matrix.org
[m]
Of course!
Ashish Uthama
@ashishUthama
@alexreinking:matrix.org - is it reasonable to ask for the LICENSE file to be included in the downloads?
Alex Reinking
@alexreinking:matrix.org
[m]
I think it is... I would add it to the share/doc/Halide folder (at least on Linux), along with the other READMEs.
Ashish Uthama
@ashishUthama
I'll create an issue and try to make the change.
Alex Reinking
@alexreinking:matrix.org
[m]
Sure... I can review, but I'm traveling through 12/5, and pushing for the 11/19 PLDI deadline, so my bandwidth is limited
Ashish Uthama
@ashishUthama
no hurry!
Nikola Smiljanić
@popizdeh
Can someone please explain this message Loop over output.s0.x has extent output.extent.0. Can only vectorize loops over a constant extent > 1. Let's say we're dealing with floats and SSE, I don't get why the loop over x can't simply loop over 1/4 of the extent and process 4 float values at the time (let's ignore the case where extent is not divisible by 4). Do I need to split x into constant size chunks in order to get vectorization working?
Zalman Stern
@zvookin
How are you calling vectorize? Typically one does f.vectorize(x, 4) which provides the split as part of a single directive. If one writes f.vectorize(x) it means the extent must be constant and known and the vectorization amount is the complete extent.
5 replies
steven-johnson
@steven-johnson:matrix.org
[m]
mac-buildbot-1 is going DOWN for a long-overdue OS upgrade (since I am actually physically in front of it). Back up soon-ish I hope.
Derek Gerstmann
@derek-gerstmann
FYI -- Halide v13.0.1 has been released: https://github.com/halide/Halide/releases/tag/v13.0.1
Vlad Levenfeld
@vladl-innopeaktech_gitlab
To call some AOT generated code from a Hexagon binary (running on the simulation), what do I need to link my Hexagon binary to? I am getting some error messages about undefined symbols (halide_string_to_string, halide_msan_annotate_memory_is_initialized, a couple of others) but libHalide.so and libHalide.a are both x86_64 libs
(I am getting the error messages when I run the simulation)
Or is there perhaps a way to statically link those missing functions when I run the AOT generator?
shoaibkamil
@shoaibkamil:matrix.org
[m]
It sounds like you're missing a runtime perhaps? What was the target for the AOT generated code?
Vlad Levenfeld
@vladl-innopeaktech_gitlab
hexagon-32-qurt-hvx_128-hvx_v66-no_asserts-no_bounds_query-enable_llvm_loop_opt
I can see some DSP libs in Hexagon SDK's copy of Halide, but I don't seem to be generating these libs when I am building Halide from source
Vlad Levenfeld
@vladl-innopeaktech_gitlab
this might be relevant
$ objdump -t build/host/ResizeNearestNeighbor.a | grep halide_
00000000 l    df *ABS*  00000000 halide_buffer_t.cpp
00000000         *UND*  00000000 halide_error
00000000         *UND*  00000000 halide_msan_annotate_memory_is_initialized
00000000  w    F .text.halide_qurt_hvx_lock     000000b0 halide_qurt_hvx_lock
00000000  w    F .text.halide_qurt_hvx_unlock   000000ac halide_qurt_hvx_unlock
00000000  w    F .text.halide_qurt_hvx_unlock_as_destructor     00000008 halide_qurt_hvx_unl
ock_as_destructor
00000000         *UND*  00000000 halide_string_to_string
00000000  w    F .text.halide_vtcm_free 00000008 halide_vtcm_free
00000000  w    F .text.halide_vtcm_malloc       0000000c halide_vtcm_malloc
That ResizeNearestNeighbor.a is the AOT generation result. It already has references to these functions at this stage.
So either I need to link them statically at AOT-generation-time or I need to dynamically link some runtime lib... and hope that it will work on the hexagon simulator
Vlad Levenfeld
@vladl-innopeaktech_gitlab
Either that, or maybe I am making a mistake during generation and these functions shouldn't be getting referenced at all in the output?
Vlad Levenfeld
@vladl-innopeaktech_gitlab
Ok, looks like I was missing something during AOT generation. I just needed to add the dependency ResizeNearestNeighbor.runtime to the same target that's pulling in the ResizeNearestNeighbors target in my CMakeLists.
Now I am just missing definitions for halide_error and halide_print
Vlad Levenfeld
@vladl-innopeaktech_gitlab
Found them in libhalide_hexagon_remote_skel.so in Qualcomm's SDK fwiw
Problem solved
Ashish Uthama
@ashishUthama
@alexreinking:matrix.org - also wondering if the packages should include the tools/ folder (esp GenGen.cpp )
whoops..nvm. Its there!
didnt look under share/Halide/tools/
Sambhav Saxena
@sambhavsaxena
Hi everyone, I'm a second year CS student from a second tier university. I'm eager to contribute to this organization but can't get the slightest idea of where to get started. Can I get some help regarding the same?
vincenzoml
@vincenzoml
Hi there, I have a simple question: is there some library of halide-implemented imaging functions? As a start, connected components in 2d and 3d?
vincenzoml
@vincenzoml
I'm considering using it as a backend for voxlogica (https://github.com/vincenzoml/VoxLogicA) in the future, in place of OpenCl / SimpleITK
But I would definitely love to avoid re-implementing all kernels from scratch
tuscasp
@tuscasp

Hi there. I would like to create a basic inheritance structure based on Halide::Generator, so as to avoid duplicated code.

The idea is that the base generator class should have a (virtual) function that is to be overridden by derived classes. Moreover, each derived class should have a specific input parameter, not available in the base class.

In normal C++ this is quite straightforward. My current Halide implementation is all in a single file, having the following classes:

class Base : public Halide::Generator<Base> {
public:
    Input<Buffer<float>> input{"input", 2};

    Output<Buffer<float>> output{"brighter", 2};

    Var x, y;

    virtual Func process(Func input);

    virtual void generate() {
        output = process(input);
        output.vectorize(x, 16).parallel(y);
    }
};
class DerivedGain : public Base {
    public:
    Input<float> gain{"gain"};

    Func process (Func input) override{
        Func result("result");
        result(x,y) = input(x,y) * gain;
        return result;
    }
};
class DerivedOffset : public Base{
    public:
    Input<float> offset{"offset"};

    Func process (Func input) override{
        Func result("result");
        result(x,y) = input(x,y) + offset;
        return result;
    }
};

Finally, I only register the two derived classes, since I have no direct interest in the Base one:

HALIDE_REGISTER_GENERATOR(DerivedGain, derived_gain)
HALIDE_REGISTER_GENERATOR(DerivedOffset, derived_offset)

But during compilation, it launches an error suggesting that class Base was being instantiated (which I do not need to happen) :

in function Base::Base():
my_generators.cpp:(.text._ZN4BaseC2Ev[_ZN4BaseC5Ev]+0x2f): undefined reference to vtable for Base

If instead of using a virtual function I implement it in the Base class like so:

class Base : public Halide::Generator<Base> {
public:
    Input<Buffer<float>> input{"input", 2};

    Output<Buffer<float>> output{"brighter", 2};

    Var x, y;

    // Func process(Func input);
    Func process (Func input){
        Func result("result");
        result(x,y) = input(x,y);
        return result;
    }

    virtual void generate() {
        output = process(input);
        output.vectorize(x, 16).parallel(y);
    }
};

Then everything compiles, but the object and header files with the generated code have the wrong function signatures (noticeable as there are missing gain/offset parameters):

derived_gain.h:

int derived_gain(struct halide_buffer_t *_input_buffer, struct halide_buffer_t *_result_buffer);

derived_offset.h:

int derived_offset(struct halide_buffer_t *_input_buffer, struct halide_buffer_t *_result_buffer);

Therefore, I would like to know which mistake I am introducing in the class definitions and how to solve it.