You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if this is intended behavior, but it led to some small confusion leading to reordering the ExpressionEvaluator scheduler before NoOp in #2209. I'm posting this issue since it is confusing for a NoOp scheduler to compute an op.
The following test "fails":
TEST_F(NVFuserTest, ZeroDimAdd) {
auto fusion = std::make_unique<Fusion>();
FusionGuard fg(fusion.get());
auto tv0 = makeSymbolicTensor(0, DataType::Float);
auto tv1 = makeSymbolicTensor(0, DataType::Float);
auto tv2 = add(tv0, tv1);
fusion->addInput(tv0);
fusion->addInput(tv1);
fusion->addOutput(tv2);
at::Tensor t0 = at::randn({}, at::kFloat).cuda();
at::Tensor t1 = at::randn({}, at::kFloat).cuda();
at::Tensor out_ref = t0 + t1;
FusionExecutorCache fec(std::move(fusion));
auto out = fec.runFusionWithInputs({t0, t1});
const FusionKernelRuntime* runtime = fec.getMostRecentKernelRuntime();
EXPECT_FALSE(runtime->isSegmented());
const std::vector<FusionExecutor>& executors = runtime->executors();
EXPECT_EQ(executors.size(), 1);
// Verify that fusion compilation was not skipped.EXPECT_TRUE(executors.front().hasCompiledKernel());
EXPECT_EQ(
runtime->schedulerHeuristics()->heuristicsList().front()->heuristic(),
ScheduleHeuristic::PointWise);
/*Expected equality of these values: runtime->schedulerHeuristics()->heuristicsList().front()->heuristic() Which is: no_op ScheduleHeuristic::PointWise Which is: pointwise*/EXPECT_TRUE(at::allclose(out[0], out_ref));
}
Even though the no-op scheduler claims the segment, it does result in a working fusion and the result is correct. Here is the kernel:
Segmenter logging doesn't seem to give any clues as to why NoOp accepts the fusion:
***Runtime***: Try to schedule fusion un-segmented:
Scheduler _expr_eval_ ***rejected*** because : Fusion must contain a single expression of type MatmulOp
***Accepted*** as: no_op
The text was updated successfully, but these errors were encountered:
This is actually the intended behavior of the NoOp scheduler. We just need to be more careful to exclude ops that produce reductions to zero-dimensional outputs, like matmuls with all 1D inputs. I'll do that in #2236 and close this.
I'm not sure if this is intended behavior, but it led to some small confusion leading to reordering the
ExpressionEvaluator
scheduler before NoOp in #2209. I'm posting this issue since it is confusing for a NoOp scheduler to compute an op.The following test "fails":
Even though the no-op scheduler claims the segment, it does result in a working fusion and the result is correct. Here is the kernel:
Segmenter logging doesn't seem to give any clues as to why NoOp accepts the fusion:
The text was updated successfully, but these errors were encountered: