On 09.09.25 18:56, Timur Kristóf wrote: >> Even when we apply it I think we should drop that, the value the >> kernel uses is correct. > > Hi Christian, > > The kernel and Mesa disagree on the limits for almost all SDMA > versions, so it would be nice to actually understand what the limits of > the SDMA HW are and use the same limit in the kernel and Mesa, or if > that isn't viable, let's document why the different limits make sense. > > I'm adding Marek to CC, he wrote the comment that I referenced here. > As far as I understand from my conversation with Marek, the kernel is > actually wrong. > > If the limits depend on alignment, then we should either set a limit > that is always safe, or make sure SDMA copies in the kernel are always > aligned and add assertions about it.
That's already done. See the size restrictions applied to BOs and the callers of amdgpu_copy_buffer(). We could add another warning to amdgpu_copy_buffer(), but that is just the backend function. > Looking at the implementation of > amdgpu_copy_buffer in the kernel, I see that it relies on > copy_max_bytes and doesn't take alignment into account, so with the > current limit it could issue subsequent copies that aren't 256 byte > aligned. "Due to HW limitation, the maximum count may not be 2^n-1, can only be 2^n - 1 - start_addr[4:2]" Well according to this comments the size restriction is 32 bytes (256 bits!) and not 256 bytes. Were do you actually get the 256 bytes restriction from? Regards, Christian. > > Best regards, > Timur > >
