Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

halide/Halide

a language for fast, portable data-parallel computation

People

Repo info

Activity

Dec 12 17:13

benoitsteiner commented #4462
Dec 12 00:00

abadams on apps_from_autoscheduler

Add BGU implementation Add histogram equalization Add max filter and 4 more (compare)
Dec 11 22:44

abadams on define_div_by_zero

Calculate Expr bounds using fun… Added JIT-test and removed appl… Merge branch 'master' of https:… and 65 more (compare)
Dec 11 22:44

abadams synchronize #4439
Dec 11 18:41

vksnk on increase-device-num

(compare)
Dec 11 18:40

vksnk on pos_inf-memory-assert

(compare)
Dec 11 18:40

vksnk on master

Check if shared memory allocati… Use has_upper_bound() to check … Merge pull request #4467 from h… (compare)
Dec 11 18:40

vksnk closed #4467
Dec 11 18:09

steven-johnson commented #4439
Dec 11 18:07

steven-johnson commented #4467
Dec 11 18:07

steven-johnson commented #4462
Dec 11 17:18

abadams synchronize #4439
Dec 11 17:18

abadams on define_div_by_zero

Fixes to Bounds.cpp (compare)
Dec 11 16:42

dsharletg on fix-llvm

(compare)
Dec 11 16:42

dsharletg on master

Fix for trunk LLVM. Merge pull request #4468 from h… (compare)
Dec 11 16:42

dsharletg closed #4468
Dec 11 07:29

dsharletg opened #4468
Dec 11 07:28

dsharletg on fix-llvm

Fix for trunk LLVM. (compare)
Dec 11 02:38

abadams synchronize #4439
Dec 11 02:38

abadams on define_div_by_zero

Simplify bounds of div (compare)

Steven Johnson

@steven-johnson

clearly you have a different definition of “cool” in mind

Dillon Sharlet

@dsharletg

Is there a way to trigger the build bots for halide/Halide#2554 ? looks like it didn't happen automatically

other than just pushing a commit to it of course

Andrew Adams

@abadams

Turns out never releasing semaphores is a leading cause of deadlock

Steven Johnson

@steven-johnson

"neither train shall move until the other one has passed"

Zalman Stern

@zvookin

The DMA device doesn't ever compute in a strict sense

The current design has the copies always be synchronous

In fact copies are always that way right? When the copy returns it is done.

When we extend lowering of async to something other than semaphores and threads, we will likely need to expose asynchronous copies, and perhaps an entire event model in general.

Andrew Adams

@abadams

Yeah, but even if I make them async and ignore the problems that introduces, we're on a single stream

Zalman Stern

@zvookin

Well that's sort of true for Hexagon DMA if there's one engine.

I.e. yes for a device, but since the device is modeling a piece of hardware that has that restriction anyway, probably....

Andrew Adams

@abadams

I was initially trying to overlap device compute with device<->host copies. In the cuda backend this needs a lot more work for anything like that to happen.

Zalman Stern

@zvookin

In order to have DMA going both directions one needs two devices and those will not be a single stream.

Andrew Adams

@abadams

That's all I meant

Zalman Stern

@zvookin

So I think we need to keep the current model, but we should consider introducing a new one that allows much more asynchrony.

Whether that is just async versions of the copy routines or a full event model I'm not sure

I'm not sure it makes much sense to consider until we are looking at a different way of lowering async

I.e. in the current model, synchronous copy is probably required anyway. The thread doing it would just wait immediately if it wasn't synchronous.

"Event model" likely amounts to exposing the semaphore abstraction and arranging for it to be signaled by the device support code somehow

Andrew Adams

@abadams

Overlapping CPU computation with device stuff works fine. All use of the device_api occurs on a single thread. All the CPU compute occurs on another thread.

That's what I'm targeting for now

Zalman Stern

@zvookin

"CPU" is not necessarily correct there. It can be a different device too.

That is the common case for Hexagon right?

Andrew Adams

@abadams

For the hexagon DMA work so far, "CPU" is hexagon, and "device" is the dma engine

Zalman Stern

@zvookin

Ok, but the Hexagon may be invoked via offload.

Andrew Adams

@abadams

But yeah, I think it would work to have cross-device stuff going on in parallel

All use of each device interface would be on a single distinct thread

Zalman Stern

@zvookin

yes

Andrew Adams

@abadams

and there's no cross-device-interface serialization I think

so it would just work

Zalman Stern

@zvookin

That is what I was highlighting.

The only issue I see with this design is that the overhead of the thread may be too high to use for very lightweight hardware synchronization mechanisms. Other than that, I don't see a lot of reason to do the customized lowering.

I need to make a couple more changes to the hexagon DMA

Will try to do so today.

The test only calls buffer_copy, which is mostly as it should be.

Dillon Sharlet

@dsharletg

So BTW regarding hexagon offloading, I've been thinking we simply punt on that for now

and only target standalone

anything that we get working on standalone can be made to work with offloading without solving any "hard" problems like async + storage folding, it just might involve a lot of plumbing and infrastructure

Steven Johnson

@steven-johnson

re: the windows buildbots, proposed fix is out there.

Zalman Stern

@zvookin

I'll have to consider the implications, but I think the current stuff just works if the DMA things are scheduled inside an offloaded thing.

Dillon Sharlet

@dsharletg

I think there might be some hiccups with the device interface

that will need to get plumbed over via offloading

and I don't think that will happen transparently right now

it might be easy to make it work though

Zalman Stern

@zvookin

yeah, that's small boogs territory.

I guess I'm expecting it will have to work with offload very early on to have a useful test.

Andrew Adams

@abadams

@dsharletg the host->device case also works, but there's no benefit for cuda because the version without async already manages to overlap the cpu compute and copies in a subtle way.

Confused me for a while.

CPU compute -> synchronous copy -> async kernel launch -> next batch of CPU compute (overlapped with GPU kernel launch) -> synchronous copy (stalls until kernel launch is done) ->