aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/radeon
Commit message (Collapse)AuthorAgeFilesLines
* radeonsi: Initial geometry shader supportMichel Dänzer2014-01-292-0/+2
| | | | | | | Partly based on the corresponding r600g work by Vadim Girlin and Dave Airlie. Reviewed-by: Marek Olšák <[email protected]>
* r600g,radeonsi: Don't set resource_create in r600_common_screen_init()Tom Stellard2014-01-281-1/+0
| | | | | | | | r600g and radeonsi have different implementations of resource_create. https://bugs.freedesktop.org/show_bug.cgi?id=74139 Reviewed-by: Marek Olšák <[email protected]>
* r600g,radeonsi: consolidate remaining obviously duplicated pipe_screen codeMarek Olšák2014-01-282-4/+22
| | | | | Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600g,radeonsi: consolidate get_compute_paramMarek Olšák2014-01-282-0/+161
| | | | | | | v2: added fprintf to r600_get_llvm_processor_name Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600g,radeonsi: consolidate get_paramf and get_video_paramMarek Olšák2014-01-282-0/+70
| | | | | | | | | | radeonsi now reports PIPE_VIDEO_CAP_SUPPORTS_PROGRESSIVE = true if UVD support isn't available. It's what all the other drivers do. Also, some #include directives were missing in radeon_uvd.h. Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600g,radeonsi: consolidate variables for CS tracingMarek Olšák2014-01-281-0/+4
| | | | | Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600g,radeonsi: consolidate get_timestamp, get_driver_query_infoMarek Olšák2014-01-281-0/+33
| | | | | | | This enables more queries for the Gallium HUD with radeonsi. Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600g,radeonsi: consolidate get_name and get_vendor queriesMarek Olšák2014-01-281-0/+50
| | | | | Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* radeon: place context-related functions first in r600_pipe_common.cMarek Olšák2014-01-281-79/+87
| | | | | | | To follow the unwritten convention of r600g and radeonsi. Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600g,radeonsi: consolidate the contents of r600_resource.cMarek Olšák2014-01-283-9/+34
| | | | | Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600g: remove a no-op while loopMarek Olšák2014-01-281-1/+1
| | | | | | | | | | | for (;;) { } while (); I was surprised to see such a statement. Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600g: convert query emission code to radeon_emitMarek Olšák2014-01-281-50/+50
| | | | | Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600g: only emit NOP relocations for queries if VM is disabledMarek Olšák2014-01-283-23/+19
| | | | | Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* r600g: move queries to drivers/radeonMarek Olšák2014-01-285-0/+922
| | | | | Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* radeon: More missing stdio.h includes.José Fonseca2014-01-231-0/+2
|
* radeon: Adding missing stdio.h include.José Fonseca2014-01-231-0/+1
| | | | | | Became apparent with the C11 thread changes. Unfortunately I didn't have all dependencies to build the driver, and only noticed this issue on build server.
* r600g,radeonsi: if discarding whole buffer range, discard whole resource insteadMarek Olšák2014-01-231-0/+8
| | | | | | | Also set the unsynchronized flag if the whole resource was discarded to avoid doing buffer-busy checks again. Reviewed-by: Michel Dänzer <[email protected]>
* radeon: Move gfx/dma cs cleanup to r600_common_context_cleanupAaron Watry2014-01-161-0/+7
| | | | | | | | | | | The radeonsi code was not cleaning up either of these items leading to leaked memory. v2: Move cleanup to r600_common_context_cleanup instead of duplicating the logic for SI CC: "10.0" <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* radeonsi: disable HTILE for 1D-tiled depth-stencil buffersMarek Olšák2014-01-061-0/+5
| | | | Reviewed-by: Michel Dänzer <[email protected]>
* radeon/llvm: Free target data at end of optimizationAaron Watry2013-12-231-0/+1
| | | | | | Reviewed-by: Tom Stellard <[email protected]> CC: "10.0" <[email protected]>
* radeon/compute: Stop leaking LLVMContexts in radeon_llvm_parse_bitcodeAaron Watry2013-12-232-12/+12
| | | | | | | | | | | | | | | | | | | Previously we were creating a new LLVMContext every time that we called radeon_llvm_parse_bitcode, which caused us to leak the context every time that we compiled a CL program. Sadly, we can't dispose of the LLVMContext at the point that it was being created because evergreen_launch_grid (and possibly the SI equivalent) was assuming that the context used to compile the kernels was still available. Now, we'll create a new LLVMContext when creating EG/SI compute state, store it there, and pass it to all of the places that need it. The LLVM Context gets destroyed when we delete the EG/SI compute state. Reviewed-by: Tom Stellard <[email protected]> CC: "10.0" <[email protected]>
* radeon: Allocate htile buffer for SI in r600_texture.Andreas Hartmetz2013-12-121-15/+67
|
* radeon: rearrange r600_texture and related code a bit.Andreas Hartmetz2013-12-122-33/+33
| | | | | This should make the differences and similarities between color and depth buffer handling more clear.
* r600g,radeonsi: consolidate buffer code, add handling of DISCARD_RANGE for SIMarek Olšák2013-12-123-0/+199
| | | | | | | | This adds 2 optimizations for radeonsi: - handling of DISCARD_RANGE - mapping an uninitialized buffer range is automatically UNSYNCHRONIZED Reviewed-by: Michel Dänzer <[email protected]>
* r600g,radeonsi: add common interface for buffer invalidationMarek Olšák2013-12-121-0/+4
| | | | | | This will be used by common code in the next commit. Reviewed-by: Michel Dänzer <[email protected]>
* r600g,radeonsi: consolidate some debug flagsMarek Olšák2013-12-122-0/+5
| | | | Reviewed-by: Michel Dänzer <[email protected]>
* r600g,radeonsi: share flags has_cp_dma and has_streamoutMarek Olšák2013-12-121-0/+2
| | | | Reviewed-by: Michel Dänzer <[email protected]>
* radeon: move some functions to r600_buffer_common.cMarek Olšák2013-12-124-130/+161
| | | | | | | | Reviewed-by: Michel Dänzer <[email protected]> Reviewed-by: Christoph Brill <[email protected]> v2: Renamed r600_buffer.c to r600_buffer_common.c. The stupid build system doesn't allow 2 files of the same name in different directories.
* winsys/radeon: set/get the scanout flag with the tiling ioctlsMarek Olšák2013-12-121-4/+5
| | | | | | | | | | | | | | | If we assume that all buffers allocated by the DDX are scanout, a new flag that says "this is not scanout" has to be added to support the non-scanout buffers and maintain backward compatibility. This fixes bad rendering on Wayland. The flag is defined as: #define RADEON_TILING_R600_NO_SCANOUT RADEON_TILING_SWAP_16BIT AFAIK, RADEON_TILING_SWAP_16BIT is not used on SI. Reviewed-by: Michel Dänzer <[email protected]>
* r600/llvm: Allow arbitrary amount of temps in tgsi to llvmVincent Lejeune2013-12-072-4/+45
|
* gallium/radeon: use PRIu64 macro for printing uint64_tEmil Velikov2013-12-032-4/+6
| | | | | Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* radeon/compute: Unconditionally inline all functions v2Tom Stellard2013-11-251-2/+20
| | | | | | | | | | | We need to do this until function calls are supported. v2: - Fix loop conditional https://bugs.freedesktop.org/show_bug.cgi?id=64225 CC: "10.0" <[email protected]>
* radeonsi: implement MSAA for CIKMarek Olšák2013-11-231-3/+7
| | | | | | There are also some changes to the printfs. Reviewed-and-Tested-by: Michel Dänzer <[email protected]>
* radeonsi: enable 2D tiling on CIKMarek Olšák2013-11-231-4/+0
| | | | | | libdrm does the DRM version check and decides if 2D tiling is used. Reviewed-and-Tested-by: Michel Dänzer <[email protected]>
* drivers/radeon: remove unused CXXFLAGS, LLVM_CPP_FILESEmil Velikov2013-11-181-4/+0
| | | | | | | | | | | | | | | | | | The above two variables are unused as of commit commit 024fe6852a76f33d7e2afc5621340e387c381bb0 Author: Tom Stellard <[email protected]> Date: Tue Apr 2 10:42:50 2013 -0700 radeon/llvm: Use LLVM C API for compiling LLVM IR to ISA v2 which removed the only cpp file from drivers/radeon, but missed to remove the CXXFLAGS. The sequential commit reintroduced and empty LLVM_CPP_FILES. Lets cleanup and remove both. Signed-off-by: Emil Velikov <[email protected]>
* gallium/drivers: compact compiler flags into Automake.incEmil Velikov2013-11-161-11/+11
| | | | | | | | | | * minimise flags duplication * distingush between VISIBILITY C and CXX flags * set only required flags - C and/or CXX v2: add LLVM_CFLAGS back to AM_CFLAGS (add missing backslash) Signed-off-by: Emil Velikov <[email protected]>
* radeon/llvm: Free elf_buffer after useAaron Watry2013-11-151-0/+1
| | | | | | | | Prevents a memory leak. v2: Remove null check CC: "10.0" <[email protected]>
* radeon/llvm: Free created llvm memory bufferAaron Watry2013-11-151-0/+1
| | | | | | | | v2: Fix indentation Reviewed-by: Tom Stellard <[email protected]> CC: "10.0" <[email protected]>
* radeon/llvm: Free libelf resourcesAaron Watry2013-11-151-0/+3
| | | | | | | | v2: Fix indentation Reviewed-by: Tom Stellard <[email protected]> CC: "10.0" <[email protected]>
* radeon/llvm: fix spelling errorAaron Watry2013-11-151-1/+1
| | | | | | Reviewed-by: Tom Stellard <[email protected]> CC: "10.0" <[email protected]>
* r600/llvm: Store inputs in function argumentsVincent Lejeune2013-11-111-0/+1
|
* radeon/llvm: Specify the DataLayout when running optimizationsTom Stellard2013-10-301-0/+4
| | | | | Without DataLayout, a lot of optimization passes aren't run and the ones that are don't work as well.
* vl/h264: split fields into SPS/PPSChristian König2013-10-281-30/+29
| | | | | | Add alot of missing fields as well. Signed-off-by: Christian König <[email protected]>
* radeon/uvd: fix H264 chroma format handlingChristian König2013-10-281-1/+15
| | | | Signed-off-by: Christian König <[email protected]>
* r600g,radeonsi: use fences provided by the winsysMarek Olšák2013-10-251-0/+30
|
* radeon: use staging for mapping linear texturesGrigori Goronzy2013-10-131-0/+6
| | | | | | | | Textures that likely reside in VRAM, are mapped for reading and don't require direct mapping should be staged into GTT, to avoid bad performance. This fixes readback performance of VDPAU surfaces. Reviewed-by: Marek Olšák <[email protected]>
* radeon/llvm: show LLVM disassembly when availableJay Cornwall2013-10-122-0/+8
| | | | | | | | With code dump enabled LLVM may generate disassembly during compilation. Show this disassembly when available and prefer it to SI bytecode dump. Reviewed-by: Tom Stellard <[email protected]> Signed-off-by: Jay Cornwall <[email protected]>
* radeon/uvd: disable VC-1 simple/main profileGrigori Goronzy2013-10-091-1/+3
| | | | | | | | It doesn't work (decodes to garbage) with most videos on UVD 3.0. Worse yet, it often results in random memory corruption or GPU hangs. Rumor has it only the newest UVD hardware could do it anyway. Reviewed-by: Christian König <[email protected]>
* radeon/uvd: try to fix VC-1 decodingGrigori Goronzy2013-10-091-33/+38
| | | | | | | | | | | | | The DPB size calculations seem to be off; there is various random corruption happening, even with advanced profile. Always assuming a minimum number of references appears to fix it, similarly to H.264. This might overallocate the DPB. Also clean up the SPS/PPS field setup so that it matches VC-1 specifications better. With these changes, all advanced profile VC-1 files I could get my hand on work fine. Reviewed-by: Christian König <[email protected]>
* radeon/uvd: fix video format reportingGrigori Goronzy2013-10-091-2/+5
| | | | | | | | | | UVD can only support NV12 in the case of hardware decoding, but we can still use all other formats for software decoding. Use the UNKNOWN profile to signal that we're not interesting in hardware decoding. v2: use profile instead of entrypoint Reviewed-by: Christian König <[email protected]>