summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/r600
Commit message (Collapse)AuthorAgeFilesLines
* gallium: add facilities for indirect drawingChristoph Bumiller2014-07-021-0/+1
| | | | | | v2: Added comments to util_draw_indirect, clarified and fixed map size. Removed unlikely().
* gallium: add a cap for max vertex streamsIlia Mirkin2014-07-011-0/+2
| | | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* r600g/compute: Defer the creation of the temporary resourceBruno Jiménez2014-06-242-20/+28
| | | | | | | | | | | | | | | For the first use of a buffer, we will only need the temporary resource in the case that a user wants to write/map to this buffer. But in the cases where the user creates a buffer to act as an output of a kernel, then we were creating an unneeded resource, because it will contain garbage, and would be copied to the pool, and destroyed when promoting. This patch avoids the creation and copies of resources in this case. Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Handle failures in compute_memory_pool_finalizeJan Vesely2014-06-241-1/+4
| | | | | Reviewed-by: Bruno Jiménez <[email protected]> Signed-off-by: Jan Vesely <[email protected]>
* r600g/compute: Fix possible endless loop in compute_memory_pool allocations.Jan Vesely2014-06-241-2/+5
| | | | | | | | | | | | The important part is the change of the condition to <= 0. Otherwise the loop gets stuck never actually growing the pool. The change in the aux-need calculation guarantees max 2 iterations, and avoids wasting memory in case a smaller item can't fit into a relatively larger pool. Reviewed-by: Bruno Jiménez <[email protected]> Signed-off-by: Jan Vesely <[email protected]>
* r600: Fix use after free in compute_memory_promote_item.Jan Vesely2014-06-241-1/+2
| | | | | | | | | | The dst pointer needs to be initialized after any calls to compute_memory_grow_pool, as the function might change the pool->vbo pointer. This fixes crashes and assertion failures in two gegl tests. Reviewed-by: Bruno Jiménez <[email protected]> Signed-off-by: Jan Vesely <[email protected]>
* r600g/compute: Use gallium util functions for double listsBruno Jiménez2014-06-202-111/+46
| | | | Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Map only against intermediate buffersBruno Jiménez2014-06-201-6/+4
| | | | | | | | | | | | With this we can assure that mapped buffers will never change its position when relocating the pool. This patch should finally solve the mapping bug. v2: Use the new is_item_in_pool util function, as suggested by Tom Stellard Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Implement compute_memory_demote_itemBruno Jiménez2014-06-202-0/+54
| | | | | | | | | | This function will be used when we want to map an item that it's already in the pool. v2: Use temporary variables to avoid so many castings in functions, as suggested by Tom Stellard Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Avoid problems when promoting items mapped for readingBruno Jiménez2014-06-201-4/+8
| | | | | | | | | | | Acording to the OpenCL spec, it is possible to have a buffer mapped for reading and at read from it using commands or buffers. With this we can keep the mapping (that exists against the temporary item) and read with a kernel (from the item we have just added to the pool) without problems. Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Only move to the pool the buffers marked for promotingBruno Jiménez2014-06-202-60/+91
| | | | Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: divide the item list in twoBruno Jiménez2014-06-202-51/+49
| | | | | | | Now we will have a list with the items that are in the pool (item_list) and the items that are outside it (unallocated_list) Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Add statuses to the compute_memory_itemsBruno Jiménez2014-06-202-1/+18
| | | | | | | | | | These statuses will help track whether the items are mapped or if they should be promoted to or demoted from the pool v2: Use the new is_item_in_pool util function, as suggested by Tom Stellard Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Add an util function to know if an item is in the poolBruno Jiménez2014-06-201-0/+5
| | | | | | | Every item that has been placed in the pool must have start_in_dw different from -1. Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Add an intermediate resource for OpenCL buffersBruno Jiménez2014-06-203-6/+41
| | | | | | | | | | | | | | | | | | | This patch changes completely the way buffers are added to the compute_memory_pool. Before this, whenever we were going to map a buffer or write to or read from it, it would get placed into the pool. Now, every unallocated buffer has its own r600_resource until it is allocated in the pool. NOTE: This patch also increase the GPU memory usage at the moment of putting every buffer in it's place. More or less, the memory usage is ~2x(sum of every buffer size) v2: Cleanup v3: Use temporary variables to avoid so many castings in functions, as suggested by Tom Stellard Reviewed-by: Tom Stellard <[email protected]>
* r600g: fix the max vertex shader input limitMarek Olšák2014-06-191-1/+1
|
* util/u_format: move utility function from r600gGrigori Goronzy2014-06-181-11/+1
| | | | | We need this for radeonsi, and it might be useful for other drivers, too.
* r600g/compute: solve a bug introduced by ↵Bruno Jiménez2014-06-121-1/+1
| | | | | | | | | | | | | | | | | | | 2e01b8b440c1402c88a2755d89f40292e1f36ce5 That commit made possible that the items could be one just after the other when their size was a multiple of ITEM_ALIGNMENT. But compute_memory_prealloc_chunk still looked to leave a gap between items. Resulting in that we got an infinite loop when trying to add an item which would left no space between itself and the next item. Fixes piglit test: cl-custom-r600-create-release-buffer-bug And the test for alignment I have just sent: http://lists.freedesktop.org/archives/piglit/2014-June/011135.html Sorry about this. Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Use %u as the unsigned formatBruno Jiménez2014-06-101-1/+1
| | | | | | | This fixes an issue when running cl-program-bitcoin-phatk piglit test where some of the inputs have negative values Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: align items correctlyBruno Jiménez2014-06-101-4/+5
| | | | | | | | | Now, items whose size is a multiple of 1024 dw won't leave 1024 dw between itself and the following item The rest of the cases is left as it was Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Cleanup of compute_memory_pool.hBruno Jiménez2014-06-101-15/+0
| | | | | | | | | | | | Removed compute_memory_defrag declaration because it seems to be unimplemented. I think that this function would have been the one that solves the problem with fragmentation that compute_memory_finalize_pending has. Also removed comments that are already at compute_memory_pool.c Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Tidy a bit compute_memory_finalize_pendingBruno Jiménez2014-06-101-12/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Explanation of the changes, as requested by Tom Stellard: Let's take need after is calculated as item->size_in_dw+2048 - (pool->size_in_dw - allocated) BEFORE: If need is positive or 0: we calculate need += 1024 - (need % 1024), which is like cealing to the nearest multiple of 1024, for example 0 goes to 1024, 512 goes to 1024 as well, 1025 goes to 2048 and so on. So now need is always possitive, we do compute_memory_grow_pool, check its output and continue. If need is negative: we calculate need += 1024 - (need % 1024), in this case we will have negative numbers, and if need is [-1024:-1] 0, so now we take the else, recalculate need as need = pool->size_in_dw / 10 and need += 1024 - (need % 1024), we do compute_memory_grow_pool, check its output and continue. AFTER: If need is positive or 0: we jump the if, calculate need += 1024 - (need % 1024) compute_memory_grow_pool, check its output and continue. If need is negative: we enter the if, and need is now pool->size_in_dw / 10. Now we calculate need += 1024 - (need % 1024) compute_memory_grow_pool, check its output and continue. Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Add more NULL checksBruno Jiménez2014-06-102-8/+28
| | | | | | | | | In this case, NULL checks are added to compute_memory_grow_pool, so it returns -1 when it fails. This makes necesary to handle such cases in compute_memory_finalize_pending when it is needed to grow the pool Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Adding checks for NULL after CALLOCBruno Jiménez2014-06-101-0/+8
| | | | Reviewed-by: Tom Stellard <[email protected]>
* r600g/compute: Fixing a typo and some indentationBruno Jiménez2014-06-101-2/+2
| | | | Reviewed-by: Tom Stellard <[email protected]>
* r600g,radeonsi: don't use hardware MSAA resolve if dst is fast-clearedMarek Olšák2014-06-031-1/+2
| | | | | | | It doesn't work and our docs say so too. Cc: [email protected] Reviewed-by: Michel Dänzer <[email protected]>
* r600g: BlitFramebuffer should follow render conditionMarek Olšák2014-06-031-5/+6
|
* radeon: add basic register setup for per-sample shadingMarek Olšák2014-06-021-4/+2
| | | | Only for Cayman, SI, CIK.
* radeon: split cayman_emit_msaa_state into 2 functionsMarek Olšák2014-06-021-1/+2
| | | | The other function will be split up from the framebuffer state.
* r600g: use TGSI_PROPERTY to disable viewport and clippingChristoph Bumiller2014-06-029-9/+72
| | | | | | | | | | v2 get rid of magic value, use DEFINES v3 update clip_disable together with vs_position_window_space Big thanks to Marek Olšák! Signed-off-by: David Heidelberger <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* gallium: create TGSI_PROPERTY to disable viewport and clippingChristoph Bumiller2014-06-021-0/+1
| | | | | | Marek v2: add a cap Signed-off-by: Marek Olšák <[email protected]>
* r600g: remove assert on draw with count == 0Christoph Bumiller2014-06-021-1/+0
| | | | Signed-off-by: Marek Olšák <[email protected]>
* r600g: HW bug workaround for TGSI_OPCODE_BREAKCChristoph Bumiller2014-06-023-4/+22
| | | | Signed-off-by: Marek Olšák <[email protected]>
* r600g: implement TGSI_OPCODE_BREAKCChristoph Bumiller2014-06-021-1/+24
| | | | Signed-off-by: Marek Olšák <[email protected]>
* r600g: support all channels of TGSI_FILE_ADDRESSChristoph Bumiller2014-06-021-28/+58
| | | | | | | | It's allowed in SM3. v2: fix multi-component tgsi_r600_arl (FLT_TO_INT is trans-only) Signed-off-by: Marek Olšák <[email protected]>
* r600g: check for PIPE_BIND_BLENDABLE in is_format_supportedChristoph Bumiller2014-06-022-0/+18
| | | | | | v2: added !util_format_is_depth_or_stencil(format) Signed-off-by: Marek Olšák <[email protected]>
* gallium/radeon: link in libradeon.la at target levelEmil Velikov2014-05-151-2/+0
| | | | | | | | | | | | It makes more sense to link the core and common parts of the driver as the target is build. Additionally this will help us drop duplicating symbols for targets that static link mulitple pipe-drivers. Only egl-static needs that currently with more to come. To simplify things a bit add HAVE_GALLIUM_RADEON_COMMON variable. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* gallium/radeon: build only a single common library libradeonEmil Velikov2014-05-151-2/+0
| | | | | | | Just fold libllvmradeon in libradeon. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* radeonsi: Fix anisotropic filtering state setupMichel Dänzer2014-05-141-9/+0
| | | | | | | | | | | | Bring it back in line with r600g. I broke this in the original radeonsi bringup. :( Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78537 Cc: "10.1 10.2" <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
* r600g: simplify framebuffer state size computationMarek Olšák2014-05-101-26/+4
| | | | | | Take the upper bound. The number doesn't have to absolutely correct, only safe. Reviewed-by: Michel Dänzer <[email protected]>
* gallium: add a cap for supporting 4-offset TG4 opcodesIlia Mirkin2014-05-071-1/+2
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: add basic support for ARB_sample_shadingIlia Mirkin2014-04-261-0/+1
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* r600g: fix hang on RV740 by using DX_RASTERIZATION_KILL instead of SX_MISCMarek Olšák2014-04-255-7/+27
| | | | | | | | Changing SX_MISC hangs RV740. When we're at it, let's use DX_RASTERIZATION_KILL on all R700 and later chipsets. Cc: 10.0 10.1 [email protected] Reviewed-by: Alex Deucher <[email protected]>
* r600g: fix for an MSAA hang on RV770Marek Olšák2014-04-253-1/+12
| | | | | Cc: 10.0 10.1 [email protected] Reviewed-by: Alex Deucher <[email protected]>
* r600g: fix for broken CULL_FRONT behavior on R6xxMarek Olšák2014-04-254-61/+64
| | | | | Cc: [email protected] Reviewed-by: Alex Deucher <[email protected]>
* r600g: fix buffer copying on R600-R700Marek Olšák2014-04-251-0/+6
| | | | | | | This fixes broken rendering in DOTA 2. Cc: 10.0 10.1 [email protected] Reviewed-by: Alex Deucher <[email protected]>
* r600g: fix flushing on RV670, RS780, RS880 againMarek Olšák2014-04-251-0/+9
| | | | | Cc: 10.0 10.1 [email protected] Reviewed-by: Alex Deucher <[email protected]>
* r600g: fix edge flags and layered rendering on R600-R700Marek Olšák2014-04-251-2/+4
| | | | | | | We forgot to set these bits. Cc: 10.1 [email protected] Reviewed-by: Alex Deucher <[email protected]>
* r600g,radeonsi: don't skip the context flush if a fence should be returnedMarek Olšák2014-04-181-1/+1
| | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77589
* r600g: Disable LLVM by default at runtime for graphicsMichel Dänzer2014-04-173-5/+5
| | | | | | | | | | | | | | | | | For graphics, the LLVM compiler backend currently has many shortcomings compared to the non-LLVM one. E.g. it can't handle geometry shaders yet, but that's just the tip of the iceberg. So building Mesa with --enable-r600-llvm-compiler is currently not recommended for anyone who doesn't want to work on fixing those issues. However, for protection of users who end up enabling it anyway for some reason, let's disable the LLVM backend at runtime by default. It can be enabled with the environment variable R600_DEBUG=llvm. Cc: "10.1" <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 22:42:54 +0000