Skip to content

Conversation

@soccercheng
Copy link

This request contains patches for RISC-V target platform support.

franz and others added 15 commits February 28, 2025 13:29
There was a missing check here before enforcing a local size that would
cause uneven WGs.
cl_khr_sub_group_ballot seems to implicitly assume max 128
sized SGs due to the return value type uint4. However, the
max SG size is not stated anywhere in the specs and thus should
not affect the other sub group functionality to my understanding.

The 128 assumption is used for WI masking for the basic
subgroup test, causing a crash when exceeding it.

This just ups the limit to 1280 to push the limit up to
work around the issue. A proper fix would be to use dynamic bit
vector size here or define a max SG size in the specs (which
doesn't make sense).
mutable_dispatch_global_size was failing because the update_global_size = 3
was not a multiple of the Local WS (original command's LWS = GWS / 64 and PoCL
doesn't support non-uniform WGs). Fixed by increasing the GWS to 256K and LWS
to 16K. The test should really detect the max Local WS of the device and use
multiples of that value - that ensures changing global WS without changing
local WS will still result in an acceptable GWS/LWS combination.

Fixes another test which had an out-of-bounds access because it hardcoded
old value of GWS.
If the queried type was "signed" or "unsigned" (with an implied int),
the returned size was zero.
Reverts part of "cl_khr_command_buffer_mutable_dispatch & negative_command_buffer tests: fix Skip logic"
commit. This was found by review to be invalid.
the negative_command_buffer_command_copy_image_sync_points_null_or_num_zero
test was using incorrect buffer size (1 byte per pixel instead of 4),
this resulted in PoCL returning the error:

CL_INVALID_VALUE dst_origin+region is outside the dst_buffer

which the test assumed is invalid result because it expected
CL_INVALID_SYNC_POINT_WAIT_LIST_KHR.
@pjaaskel
Copy link
Member

Thanks @soccercheng! Can you send this PR directly to the upstream CTS in the KhronosGroup project repo?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants