ReemaAlzaid commented on PR #12838: URL: https://github.com/apache/gluten/pull/12838#issuecomment-5417353397
> Based on my understanding, the gap lies in the `VeloxGpuColumnarBatchSerializer` is always called regardless of the hash join stage is executed on cpu or gpu. When cudf is enabled, the query fails when the hash join is executed on CPU, but can pass on GPU. > > This change will cause the hash join to fail when it is executed on the GPU. I agree with you on this. `CudfValueStream` extends `CudfOperator`, so the adapter marks it as producing GPU output and inserts no `CudfFromVelox` after it `grep -c from-velox on a q95` run is 0. The GPU serializer was the only thing uploading. This PR removes it and puts nothing in its place, so `CudfHashJoinBuild` gets a host batch and the cast fails. Exactly what you saw. The missing piece is #12471, which uploads in `CudfVectorStream` instead. With both applied q95 passes, same plan and same build tables as before one H2D copy, just moved to the consumer Also on autoBroadcastJoinThreshold=-1; I only used it to isolate q16 to a single broadcast, and I'll re run at the default. So there are two options we could do: - Land #12471 first and rebase this on it. - Or Make this self contained: pass the consuming stage's `offloadCuda` into `BuildSideRelation#deserialized` instead of a hard coded false. GPU stage → GPU serializer, CPU stage → host serializer, no cross PR dependency I lean toward 2. Happy to do either -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
