summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/llvmpipe
Commit message (Collapse)AuthorAgeFilesLines
* llvmpipe: initialize default fb correctly in setupRoland Scheidegger2017-06-241-0/+4
| | | | | | | | | | | | | | | | If lp_setup_bind_framebuffer() is never called, then setup fb x1/y1 was not correctly initialized. This can happen if there's never a fb set - both cso and llvmpipe would consider setting this with no cbufs and no zsbuf a redundant change and therefore it would never get set. We rely on this setup fb rect being initialized correctly for the tri intersect tests, throwing away tris which don't intersect. Not initializing it meant we'd then say it intersected, and we'd try to bin that despite that we have no actual tiles to bin it to, leading to assertion failures (pretty harmless since tile 0/0 always exists nevertheless as tiles are statically allocated, albeit that should change at some point). (Note probably not an issue with gl state tracker) Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe:fix using 32bit rasterization mistakenly, causing overflowsRoland Scheidegger2017-06-234-31/+43
| | | | | | | | | | | | | We use the bounding box (triangle extents) to figure out if 32bit rasterization could potentially overflow. However, we used the bounding box which already got rounded up to 0 for negative coords for this, which is incorrect, leading to overflows and hence bogus rendering in some of our private use. It might be possible to simplify this somehow (we're now using 3 different boxes for binning) but I don't quite see how. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: fill in debug vertex info for tri rasterizationRoland Scheidegger2017-06-231-1/+1
| | | | | | | | | This is pretty useful for debugging rasterization issues, so turn it on based on DEBUG (the actual existence of the fields is also conditionalized on DEBUG, lines fill it out the same too). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallium: add PIPE_CAP_BINDLESS_TEXTURESamuel Pitoiset2017-06-141-0/+1
| | | | | | | | | Whether bindless texture operations are supported by the underlying driver. Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* llvmpipe: Match pipe_context::render_condition prototype.Jose Fonseca2017-06-132-5/+5
| | | | To silence compiler warnings. Trivial.
* gallium: Add a cap to check if the driver supports ARB_post_depth_coverageLyude2017-06-021-0/+1
| | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* llvmpipe: add LP_NEW_GS flag for updating vertex infoRoland Scheidegger2017-05-271-0/+1
| | | | | | | | | | The vertex information we compute here is really dependent on the last stage before FS. It just happened to work most of the time because new GS tend to come with new VS and/or FS... (The LP_NEW_GS flag was previously set but never used.) Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallium: add PIPE_CAP_ALLOW_MAPPED_BUFFERS_DURING_EXECUTIONMarek Olšák2017-05-171-0/+1
| | | | | | for skipping mapped-buffer checking in every GL draw call Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium: add PIPE_CAP_CAN_BIND_CONST_BUFFER_AS_VERTEXMarek Olšák2017-05-101-0/+1
| | | | | | | The next patch will use it. This is really for svga and GL2-level drivers. Tested-by: Edmondo Tommasina <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* gallium: remove pipe_index_buffer and set_index_bufferMarek Olšák2017-05-103-24/+6
| | | | | | | | | | | | | | pipe_draw_info::indexed is replaced with index_size. index_size == 0 means non-indexed. Instead of pipe_index_buffer::offset, pipe_draw_info::start is used. For indexed indirect draws, pipe_draw_info::start is added to the indirect start. This is the only case when "start" affects indirect draws. pipe_draw_info::index is a union. Use either index::resource or index::user depending on the value of pipe_draw_info::has_user_indices. v2: fixes for nine, svga
* gallium: decrease the size of pipe_vertex_buffer - 24 -> 16 bytesMarek Olšák2017-05-102-5/+6
|
* gallium: add PIPE_CAP_TGSI_TES_LAYER_VIEWPORTNicolai Hähnle2017-04-141-0/+1
| | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Edward O'Callaghan <[email protected]>
* llvmpipe: remove unused subpixel_snap() and fixed_to_float()Samuel Pitoiset2017-04-131-6/+3
| | | | | | | | | | | | | | | | Fixes the following Clang warnings. lp_setup_tri.c:55:1: warning: unused function 'subpixel_snap' [-Wunused-function] subpixel_snap(float a) ^ lp_setup_tri.c:61:1: warning: unused function 'fixed_to_float' [-Wunused-function] fixed_to_float(int a) ^ v2: - do not remove subpixel_snap() (use !PIPE_ARCH_SSE instead) Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: add PIPE_CAP_TGSI_BALLOTNicolai Hähnle2017-04-051-0/+1
| | | | Reviewed-by: Marek Olšák <[email protected]>
* gallium: add sparse buffer interface and capabilityNicolai Hähnle2017-04-051-0/+1
| | | | | | | v2: - explain the resource_commit interface in more detail Reviewed-by: Marek Olšák <[email protected]>
* gallium: Add a cap to check if the driver supports fill_rectangleLyude2017-03-311-0/+1
| | | | | | | | Changes since v1: - Add pipe caps for etnaviv, freedreno, swr and virgl Signed-off-by: Lyude <[email protected]> Reviewed-by: Ilia Mirkin <[email protected]>
* gallium: add PIPE_CAP_TGSI CLOCKNicolai Hähnle2017-03-311-0/+1
| | | | | Reviewed-by: Samuel Pitoiset <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium: add PIPE_CAP_TGSI_TEX_TXF_LZMarek Olšák2017-03-151-0/+1
|
* gallium/util: replace pipe_thread_setname() with u_thread_setname()Timothy Arceri2017-03-121-1/+1
| | | | | | | They do the same thing we just moved the function to be accessible to all of Mesa. Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_thread_create() with u_thread_create()Timothy Arceri2017-03-121-1/+1
| | | | | | | They do the same thing we just moved the function to be accessible to all of Mesa. Reviewed-by: Marek Olšák <[email protected]>
* gallium: s/uint/enum pipe_shader_type/ for set_constant_buffer()Brian Paul2017-03-081-1/+1
| | | | Reviewed-by: Edward O'Callaghan <[email protected]>
* llvmpipe: s/unsigned/enum pipe_shader_type/Brian Paul2017-03-081-1/+1
| | | | Reviewed-by: Edward O'Callaghan <[email protected]>
* gallium: s/unsigned/enum pipe_shader_type/ for pipe_screen::get_shader_param()Brian Paul2017-03-081-1/+3
| | | | Reviewed-by: Edward O'Callaghan <[email protected]>
* gallium/util: replace pipe_thread_wait() with thrd_join()Timothy Arceri2017-03-071-1/+1
| | | | | | | | | Replace done using: find ./src -type f -exec sed -i -- \ 's:pipe_thread_wait(\([^)]*\)):thrd_join(\1, NULL):g' {} \; Reviewed-by: Plamena Manolova <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: remove PIPE_THREAD_ROUTINE()Timothy Arceri2017-03-071-1/+2
| | | | | | | | | | | | | This was made unnecessary with fd33a6bcd7f12. This was mostly done with: find ./src -type f -exec sed -i -- \ 's:PIPE_THREAD_ROUTINE(\([^,]*\), \([^)]*\)):int\n\1(void \*\2):g' {} \; With some small manual tidy ups. Reviewed-by: Plamena Manolova <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_condvar with cnd_tTimothy Arceri2017-03-071-1/+1
| | | | | | pipe_condvar was made unnecessary with fd33a6bcd7f12. Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_thread with thrd_tTimothy Arceri2017-03-071-1/+1
| | | | | | | | pipe_thread was made unnecessary with fd33a6bcd7f12. V2: fix compile error in u_queue.c Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_mutex_unlock() with mtx_unlock()Timothy Arceri2017-03-073-4/+4
| | | | | | | | | | pipe_mutex_unlock() was made unnecessary with fd33a6bcd7f12. Replaced using: find ./src -type f -exec sed -i -- \ 's:pipe_mutex_unlock(\([^)]*\)):mtx_unlock(\&\1):g' {} \; Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_mutex_lock() with mtx_lock()Timothy Arceri2017-03-073-4/+4
| | | | | | | | | | replace pipe_mutex_lock() was made unnecessary with fd33a6bcd7f12. Replaced using: find ./src -type f -exec sed -i -- \ 's:pipe_mutex_lock(\([^)]*\)):mtx_lock(\&\1):g' {} \; Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_mutex_destroy() with mtx_destroy()Timothy Arceri2017-03-073-3/+3
| | | | | | | | | | pipe_mutex_destroy() was made unnecessary with fd33a6bcd7f12. Replace was done with: find ./src -type f -exec sed -i -- \ 's:pipe_mutex_destroy(\([^)]*\)):mtx_destroy(\&\1):g' {} \; Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_mutex_init() with mtx_init()Timothy Arceri2017-03-073-3/+3
| | | | | | | | | | pipe_mutex_init() was made unnecessary with fd33a6bcd7f12. Replace was done using: find ./src -type f -exec sed -i -- \ 's:pipe_mutex_init(\([^)]*\)):(void) mtx_init(\&\1, mtx_plain):g' {} \; Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_mutex with mtx_tTimothy Arceri2017-03-073-3/+3
| | | | | | pipe_mutex was made unnecessary with fd33a6bcd7f12. Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_condvar_broadcast() with cnd_broadcast()Timothy Arceri2017-03-071-1/+1
| | | | | | | pipe_condvar_broadcast() was made unnecessary with fd33a6bcd7f12. Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_condvar_wait() with cnd_wait()Timothy Arceri2017-03-071-1/+1
| | | | | | | pipe_condvar_wait() was made unnecessary with fd33a6bcd7f12. Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_condvar_destroy() with cnd_destroy()Timothy Arceri2017-03-071-1/+1
| | | | | | | pipe_condvar_destroy() was made unnecessary with fd33a6bcd7f12. Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium/util: replace pipe_condvar_init() with cnd_init()Timothy Arceri2017-03-071-1/+1
| | | | | | | pipe_condvar_init() was made unnecessary with fd33a6bcd7f12. Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium: remove PIPE_CAP_USER_INDEX_BUFFERSMarek Olšák2017-02-251-1/+0
| | | | | | | | all drivers support it Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Tested-by: Brian Paul <[email protected]> (VMware driver only)
* llvmpipe: enable clear_texture with util_clear_textureLars Hamre2017-02-242-2/+4
| | | | | | | | Passes all corresponding piglit tests. Signed-off-by: Lars Hamre <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Edward O'Callaghan <[email protected]>
* gallium: set pipe_context uploaders in drivers (v3)Marek Olšák2017-02-141-0/+9
| | | | | | | | | | | | | | | Notes: - make sure the default size is large enough to handle all state trackers - pipe wrappers don't receive transfer calls from stream_uploader, because pipe_context::stream_uploader points directly to the underlying driver's stream_uploader (to keep it simple for now) v2: add error handling to nv50, nvc0, noop v3: set const_uploader Reviewed-by: Nicolai Hähnle <[email protected]> Tested-by: Edmondo Tommasina <[email protected]> (v1) Tested-by: Charmaine Lee <[email protected]>
* gallium: add separate PIPE_CAP_INT64_DIVMODIlia Mirkin2017-02-091-0/+1
| | | | | | | | | | | Nouveau does not currently have logic to implement this as a library function. Even though such a library could be written, there's no big advantage to do it that way for now given that int64 is a very uncommon use-case. Allow a driver to expose INT64 without supporting division and modulo operations. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* gallium: turn PIPE_SHADER_CAP_DOUBLES into a screen capabilityNicolai Hähnle2017-02-021-0/+1
| | | | | | | | | | | | | | | | | | | Make the cap consistent with PIPE_CAP_INT64. Aside from the hypothetical case of using draw for vertex shaders (and actually caring about doubles...), every implementation supports doubles either nowhere or everywhere. Also, st/mesa didn't even check the cap correctly in all supported shader stages. While at it, add a missing LLVM version check for 64-bit integers in radeonsi. This is conservative: judging by the log, LLVM 3.8 might be sufficient, but there are probably bugs that have been fixed since then. v2: fix clover (Marek) Reviewed-by: Marek Olšák <[email protected]>
* llvmpipe: Use LLVMDumpModule, not DumpModule.Bas Nieuwenhuizen2017-01-291-1/+1
| | | | | | | Forgot the prefix ... Fixes: 0fca80b3db64dc1d004f78e22b9de86a07e9de96 Signed-off-by: Bas Nieuwenhuizen <[email protected]>
* various: Fix missing DumpModule with recent LLVM.Bas Nieuwenhuizen2017-01-291-1/+7
| | | | | | | | | | | | | | Since LLVM revision 293359 DumpModule gets only implemented when either a debug build or LLVM_ENABLE_DUMP is set. This patch adds a direct replacement for the function for radv and radeonsi, However, as I don't know a good place to put common LLVM code for all three I inlined the implementation for LLVMPipe. v2: Use the new code for LLVM 3.4+ instead of LLVM 5+ & fixed indentation Signed-off-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: enable int64 on radeonsi, llvmpipe, softpipeNicolai Hähnle2017-01-271-1/+1
| | | | | | | | | All of these have had support for the TGSI opcodes since before most of the glsl compiler work landed. Also update the docs accordingly, including the missing note about i965. Reviewed-by: Marek Olšák <[email protected]>
* gallium: Add integer 64 capabilityDave Airlie2017-01-271-0/+1
| | | | | | | | | v1.1: move to using a normal CAP. (Marek) v2: fill in the cap everywhere Signed-off-by: Dave Airlie <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium: add PIPE_CAP_TGSI_MUL_ZERO_WINSIlia Mirkin2017-01-231-0/+1
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Axel Davy <[email protected]>
* gallium: add PIPE_CAP_TGSI_FS_FBFETCHIlia Mirkin2017-01-161-0/+1
| | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* llvmpipe: do transpose/untwiddle after conversion for 8bit formatsRoland Scheidegger2017-01-061-7/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generally we should do tranpose after conversion, if the format has less than 32 bits per channel (if it has 32 bits, conversion is going to be a no-op anyway...). This is obviously because there's less vectors to deal with. Though the advantage for 16 bit formats isn't that big, and in fact with AVX there isn't really any (as the 32bit unpacks can be done with 256bit, but the smaller ones cannot, although that would change again with proper AVX2 support). Only makes sense for 2d and not 1d cases. And to keep things easy, only handle 1,2 and 4 channels (rgbx is just fine). For rgba unorm8 format the backend conversion sums up to these instruction totals (not counting the movs for SSE2 due to 2-op syntax - generally every 2 unpacks need an additional mov). SSE2 AVX transpose: 32 unpack 16 unpack untwiddle: 0 8 (128bit low/high permutes) convert: 16 mul + 16 cvt 8 mul + 8 cvt 32->8bit: 12 pack 8 (128bit extract) + 12 pack When doing transpose/untwiddle afterwards we get: convert: 16 mul + 16 cvt 8 mul + 8 cvt 32->8bit: 12 pack 8 (128bit extract) + 12 pack transpose/untwiddle 12 unpack 12 unpack So for SSE2, this drops 20 unpacks (total instruction count 76->56) whereas for AVX it replaces the 16 256bit unpacks with 8 128bit ones and drops the 8 lo/hi permutes (in total 60->48). (Albeit to be fair, the permutes could be dropped even when doing the transpose first, they are extremely pointless but we'd need to be able to tell lp_build_conv to reorder the vectors, for AVX2 we're going to need to be able to tell lp_build_conv about ordering in any case.) (With different ordering going into conversion, it would be possible to do 4 unpacks + 4 pshufbs instead of 12 unpacks, but that might not be better, and not all cpus can do it. Proper AVX2 support should eliminate the 8 128bit extracts, reduce these 12 packs to 6 and the 12 unpacks to 2 pshufb + 2 permq ideally (+ 2 final 128bit extracts).) Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: use alpha from already converted color if possibleRoland Scheidegger2017-01-062-18/+54
| | | | | | | | | | | | | For rgbx formats, there is no point in doing alpha conversion again (and with different tranpose even, so llvm can't eliminate it). Albeit it looks like there's some minimal changes needed in the blend code (found by code inspection, no test seemed to complain) if we do this - the blend factors are already sanitized if we have no destination alpha, however for src_alpha_saturate it looks like it still might make a difference (note that we forced has_alpha to true before for some formats and nothing complained, but this seems safer). Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: use scalar load instead of vectors for small vectors in fs backendRoland Scheidegger2017-01-061-6/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | llvm has _huge_ problems trying to load things like <4 x i8> vectors and stitching such loads together to form 128bit vectors. My understanding of the problem is that the type legalizer tries to extend that to really a <4 x i32> vector and not a <16 x i8> vector with the 4 elements first then followed by padding, so the shuffles for then combining things together are more or less impossible - you can in fact see the pmovzxd llvm generates. Pre-4.0 llvm just gives up on it completely and does a 30+ pextrb/pinsrb sequence instead. It looks like current llvm has fixed this behavior (my guess would be due to better shuffle combination and load/shuffle folds), but we can avoid this by just loading as <1 x i32> values, combine that and only cast at the end. (I suspect it might also work if we'd pad the loaded vectors immediately before shuffling them together, instead of directly stitching 2 such vectors together pairwise before combining the pair. But this _might_ lose the ability to load the values directly into their right place in the vector with pinsrd.). But using 32bit values is probably easier for llvm as it will never give it funny ideas how the vector should look like. (This is possibly only a problem for 1x8bit formats, since 2x8bit will end up fetching 64bit hence only two vectors are stitched together, not 4, but we use the same strategy anyway.) Reviewed-by: Jose Fonseca <[email protected]>