aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/r600/radeon_video.c
Commit message (Collapse)AuthorAgeFilesLines
* r600: Remove HEVC related code since HEVC is not supportedThong Thai2020-01-031-15/+2
| | | | | | | Signed-off-by: Thong Thai <[email protected]> Reviewed-by: Leo Liu <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3153> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3153>
* gallium: switch boolean -> bool at the interface definitionsIlia Mirkin2019-07-221-4/+4
| | | | | | | | | | | | | | | | | | This is a relatively minimal change to adjust all the gallium interfaces to use bool instead of boolean. I tried to avoid making unrelated changes inside of drivers to flip boolean -> bool to reduce the risk of regressions (the compiler will much more easily allow "dirty" values inside a char-based boolean than a C99 _Bool). This has been build-tested on amd64 with: Gallium drivers: nouveau r300 r600 radeonsi freedreno swrast etnaviv v3d vc4 i915 svga virgl swr panfrost iris lima kmsro Gallium st: mesa xa xvmc xvmc vdpau va Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]>
* winsys/amdgpu: explicitly declare whether buffer_map is permanent or notNicolai Hähnle2018-11-281-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new driver-private transfer flag RADEON_TRANSFER_TEMPORARY that specifies whether the caller will use buffer_unmap or not. The default behavior is set to permanent maps, because that's what drivers do for Gallium buffer maps. This should eliminate the need for hacks in libdrm. Assertions are added to catch when the buffer_unmap calls don't match the (temporary) buffer_map calls. I did my best to update r600 for consistency (r300 needs no changes because it never calls buffer_unmap), even though the radeon winsys ignores the new flag. As an added bonus, this should actually improve the performance of the normal fast path, because we no longer call into libdrm at all after the first map, and there's one less atomic in the winsys itself (there are now no atomics left in the UNSYNCHRONIZED fast path). Cc: Leo Liu <[email protected]> v2: - remove comment about visible VRAM (Marek) - don't rely on amdgpu_bo_cpu_map doing an atomic write Reviewed-by: Marek Olšák <[email protected]>
* amd,radeonsi: rename radeon_winsys_cs -> radeon_cmdbufMarek Olšák2018-06-191-1/+1
| | | | Acked-by: Bas Nieuwenhuizen <[email protected]>
* r600: drop a bunch of post-cayman code. (v2)Dave Airlie2017-10-101-42/+19
| | | | | | | | | | | | | Now that Marek has split the two drivers apart, drop a bunch of unnecessary code from the r600 half. There is probably a bunch more hiding in the video code. No piglit regressions on caicos. v2: fix HAVE_LLVM protected code Acked-by: Nicolai Hähnle <[email protected]> Acked-by: Marek Olšák <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* r600: fork and import gallium/radeonMarek Olšák2017-09-261-0/+372
This marks the end of code sharing between r600 and radeonsi. It's getting difficult to work on radeonsi without breaking r600. A lot of functions had to be renamed to prevent linker conflicts. There are also minor cleanups. Acked-by: Dave Airlie <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>