-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ref::quant_dot for int8 computes wrong result in test validation #1815
Comments
Working on reproducing test from commit, but I wrote the following ref_op_dot_test and printed the first 5 elements for sanity checking:
This test passes on develop branch. The first 5 elements are the same as the GPU results printed above. |
@kahmed10 The important part of puzzle is why reference test will give different results under different scenarios. I admit it can yield correct result in mlir dedicated test too. But this one is very particular to |
This should probably use |
Yes I can reproduce the difference in results (failure) from your branch. Will need to investigate further on what is causing the difference. |
It still passes when checking |
After further inspection, the reason that there are differences between CPU and GPU is because of unintended rounding on the GPU codegen side. We have a fix in place and will open a PR soon. |
Fixes the failing test case in #1815. Added a test that would otherwise fail without the change.
Refer to branch:
bug-reference-dot-incorrect-result
The unit test is here: 1a6495a
I wrote this unit test such that it can function exactly the same as the original
int8_quantization
test.Reproducing instructions:
$ make -j test_gpu_quantization && MIGRAPHX_ENABLE_MLIR=0 MIGRAPHX_TRACE_EVAL=2 ./bin/test_gpu_quantization &> compile.log
The failure looks like:
Full log is here: compile.log
Analysis
Both cpu and gpu are computing the exact same gemm problem:
cpu reference result (computed from migraphx) is wrong, and gpu reference (computed by rocblas) is correct. I have validated the result by computing it on third-party matrix multiplier.
Conclusion
int8_quantization
test, which should also be failing, is instead passingThe text was updated successfully, but these errors were encountered: