[dtest] Additional tests for Memcpy
APIs tested:
hipMemcpy, hipMemcpyAsync,
hipMemcpyHtoD, hipMemcpyHtoDAsync,
hipMemcpyDtoH, hipMemcpyDtoHAsync,
hipMemcpyDtoD, hipMemcpyDtoDAsync
1: The aim of this test case is to cover all
the negative test cases for 8 hipMemcpy apis
2: This test launches NUM_THREADS threads.
Each thread in turn tests the working of
8 hipmemcpy apis
3: This test case verifies the working of
Memcpy apis for range of memory sizes from
smallest one unit transfer to 1GB.
Change-Id: If5c99527a78e817bafab2e1bd9b686a9ff916184
We don't care about target ID features in this test, so we can simply
strip them away to maintain compatability with the internal test table.
Change-Id: I44591a052c02f9e01876a8946f99cfedee371233
Since the majority of the Hostcall implementation now sits in the
commmon layer, the PAL backend simply just needs to invoke it. One thing
that is missing though is HSA signal support.
The newly added pal::Signal class is a light emulaion of what HSA
signals provide. The current implementation is just enough to get
Hostcall working, but it can be expanded in the future if needed to
fully emulate HSA signals.
The major difference for now between PAL and ROCm hostcall
implemenations is that PAL doesn't support blocking signals. This will
be enabled in the near future. For now use active wait for PAL.
Change-Id: I746557354ab9d71a7d4a31f9320fcc2fee5aee7f
On Windows there's something fundamentally broken about redirecting IO
into a file and then restoring that said IO to it's original state. Even
though no syscalls would fail, the output would sometimes either go into
CLI or straight up nowhere.
Simply using pipes instead of a temporary file magically resolves the
above issue ¯\_(ツ)_/¯
Unfortunately the max pipe size on Linux is 1Mb, which is not enough to
store all the data printed by the kernel. This leads to a softhang in
vprintf().
Stick to using a temporary file on Linux, but switch to pipes on
Windows. Slightly refactor the CaptureStream struct to accomadate this
difference.
Change-Id: Id8e68f150df47815a4f652ee2bcd6cfb7c3e3bac
The following snippets has different behaviour based on platform.
printf("%p", 0x123abc);
Linux -> 0x123abc
Windows -> 123ABC
printf("%p", nullptr);
Linux -> (nil)
Windows -> 0000000000000000
%p specifier according to C spec is implementation defined, so we need
to adjust the reference string to be correct on Windows.
Change-Id: I7059fa0f6cde611718bd76655637670fcbccf43c
The current implementation in ROCclr for callback is
based on OCL specification. If in HIP the same command
could get multiple callbacks, then ROCclr will process them in
a reverse order. Unique Markers for each callback will make
sure it won't happen.
Add a dependency wait for callbacks, since HSA signal callback
doesn't guarantee the order.
Change-Id: I9d514734e258312fe9a74d48132361eb17c52d67
HIP requires to return AccessedBy query for all device, but ROCr
can process one per query. Hence send the queries for all
available devices and then accumulate the results in runtime.
Change-Id: I082f9adb8e31c775a8ad1bf7a5af37440ef4bd16
Enabling DebugVMID requires a certain sequence in
PAL initialization. StartLateDeviceInit() must be called before
CommitSettingsAndInit().
Change-Id: I7385a8cc89e7a8ad97a6b56ad6acbd2cf2f29728
HIP tests require HIP callbacks to be processed in another thread.
This change will use a thread from HSA signal callbacks to make
sure a HIP callback was done asynchronously.
Also process the callback before changing the status of command
Change-Id: Icef85d0e0f808663882cf6881ff1be3e5eca29ac
With direct dispatch enqueue occurs before callback update and
it can't be tracked in the device backend
Change-Id: Ie8793e3ddb68cc5bb36348f7a8dcdbdc87a2487c
Some upstream will load hip multiple times thus Rocclr static lib will
be linked to hip::amdhip64 many times. This will bring some unexpected
issues such as in hipBLAS. The patch prevents his happening.
Change-Id: I6bb27659f74371dae6e59c59fd6bb2022cc062ff