| Bug ID | 89164 |
|---|---|
| Summary | AMD Kaveri: gbm_bo_get_stride returns wrong values for cursor buffers |
| Product | Mesa |
| Version | 10.4 |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | andreas.pokorny@gmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
When creating a cursor with GBM_BO_USE_CURSOR{_64x64} and a dimension of 64 by
64 pixel the operation succeeds and the returned stride size is always 256.
When drawing the cursor buffer and displaying on screen graphical artifacts
appear. Instead of 128 bytes a stride size of 512 seems to be correct on Kaveri
systems.
For this particular scenario there is a workaround: query 'an arbitrary but
valid cursor buffer size' with DRM_CAP_CURSOR_WIDTH DRM_CAP_CURSOR_HEIGHT.
Still gbm_bo_get_stride should not return a wrong stride size.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | NOTABUG |
You need to pass the dimensions queried from DRM_CAP_CURSOR_WI= DTH and DRM_CAP_CURSOR_HEIGHT instead of hardcoding 64. As of CIK, Radeon hardware = only supports 256x256 hardware cursors.
(In reply to Michel D=C3=A4nzer from comment #1) > You need to pass the dimensions queried from DRM= _CAP_CURSOR_WIDTH and > DRM_CAP_CURSOR_HEIGHT instead of hardcoding 64. As of CIK, Radeon hard= ware > only supports 256x256 hardware cursors. Yes, but since buffer creation with a smaller size does not fail, gbm_bo_get_stride should return the right size.
(In reply to Andreas Pokorny from comment #2) > Yes, but since buffer creation with a smaller si= ze does not fail, > gbm_bo_get_stride should return the right size. It returns the stride of the allocated buffer. The problem is that the buff= er size doesn't match the hardware cursor size in the first place. Returning a different stride can't change that.