aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/llvmpipe/lp_rast.h
Commit message (Collapse)AuthorAgeFilesLines
* llvmpipe: fix lp_rast_plane alignment on 32bitRoland Scheidegger2016-03-151-0/+6
| | | | | | | | | | | | Some rasterization code relies (for sse) on the first and third planes (but not the second for now) being 128bit aligned, and we didn't get that on 32bit - I mistakenly thought the 64bit number in the struct would get the thing aligned to 64bit even on 32bit archs. Stephane Marchesin really figured this out. Reviewed-by: Jose Fonseca <[email protected]> CC: <[email protected]>
* llvmpipe: use vector loads for (optimized) tri raster funcsRoland Scheidegger2016-02-021-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | When we switched to 64bit rasterization, we could no longer use straight aligned loads for loading the plane data. However, what the code actually does for loading 3 planes, is 12 scalar loads + 9 unpacks, and then there's another 8 unpacks for the transpose we need (!). It would be possible to do the (scalar) loads of course already transposed (at least saving the additional unpacks), however instead just use (un)aligned vector loads, and recalculate the eo values, which is much less instructions (note in case of the triangle_32_3_4 case, the eo values are not even used, making the scalar loads + unpacks for them all the more pointless). This drops execution time of the triangle_32_3_4 function considerably, albeit it doesn't really make a measurable difference (for small tris we're essentially limited by vertex throughput in any case), for triangle_32_3_16 it's essentially noise (the loop is more costly than the initial code there). (I'm thinking about just ditching storing the eo values in the plane data, so could switch back to using aligned planes, however right now they are still used in the other raster functions dealing with planes with scalar code. Also not touching the ppc code, might not be that bad there in any case.) Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: don't store eo as 64bit intRoland Scheidegger2016-01-081-1/+1
| | | | | | | | | | | eo, just like dcdx and dcdy, cannot overflow 32bit. Store it as unsigned though just in case (it cannot be negative, but in theory twice as big as dcdx or dcdy so this gives it one more bit). This doesn't really change anything, albeit it might help minimally on 32bit archs. Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* gallium: replace INLINE with inlineIlia Mirkin2015-07-211-9/+9
| | | | | | | | | | | | | | | | Generated by running: git grep -l INLINE src/gallium/ | xargs sed -i 's/\bINLINE\b/inline/g' git grep -l INLINE src/mesa/state_tracker/ | xargs sed -i 's/\bINLINE\b/inline/g' git checkout src/gallium/state_trackers/clover/Doxyfile and manual edits to src/gallium/include/pipe/p_compiler.h src/gallium/README.portability to remove mentions of the inline define. Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Marek Olšák <[email protected]>
* llvmpipe: increase number of queries which can be binned simultaneously to 64Roland Scheidegger2014-06-131-1/+1
| | | | | | | | | | | Gallium (but not OpenGL) does allow nesting of queries, but there's no limit specified (d3d10 has no limit neither). Nevertheless, for practical purposes we need some limit in llvmpipe, otherwise we'd need more complex handling of queries as we need to keep track of all binned queries (this only affects queries which gather data past setup). A limit of 16 is too small though, while 64 would suffice. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: fix clearing of individual color buffers in a fbRoland Scheidegger2014-04-251-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GL (3.0) allows you to clear individual color buffers in a fb. In fact for fbs containing both int and float/normalized color buffers this is required (because the clearing values are otherwise undefined if applied to all buffers). The gallium interface was changed a while ago, but llvmpipe ignored it (hence doing such individual clears always resulted in clearing all buffers, plus some assorted asserts due to the mixed fbs). So change the clear command to indicate the buffer to be cleared. Also, because indicating the buffer to be cleared would have made lp_rast_arg_cmd larger which is unacceptable (we're trying to shrink it some day) allocate the clear value in the scene and just pass a pointer. There's several advantages and disadvantages here: + clearing individual buffers works (we could also actually bin such clears now if they'd come through clear_render_target() if the surface is in the current fb, though we didn't do this before for the single rb case and still don't try). + since there's one clear per rb, we do the format conversion in setup rather than per bin. Aside from the (drop in the ocean...) performance advantage this means that clearing to very small values (that is, denormal when converted to the format) should work for small float (fp16 etc.) formats, as the util code couldn't handle it correctly before (because cpu denorms are disabled when executing the bin commands, screwing up the magic conversion and flushing the values to 0, though this was not verified). - there's some overhead for traditional old-style clear-all MRT cases, since there's one rast clear command per rb instead of one for all rbs. This fixes https://bugs.freedesktop.org/show_bug.cgi?id=76976. v2: get rid of the ugly manual memcpy stuff and just use union util_color. This is 32 bytes instead of 16 but as the allocation is per scene we can live with those additional 16 bytes (and the additional 128 bytes in the setup context), which makes the code much more obvious. Suggested by Brian. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: clamp fragment shader depth write to the current viewport depth range.Matthew McClure2013-12-091-1/+1
| | | | | | | | | | | | | | | | | With this patch, generate_fs_loop will clamp any fragment shader depth writes to the viewport's min and max depth values. Viewport selection is determined by the geometry shader output for the viewport array index. If no index is specified, then the default viewport index is zero. Semantics for this path can be found in draw_clamp_viewport_idx and lp_clamp_viewport_idx. lp_jit_viewport was created to store viewport information visible to JIT code, and is validated when the LP_NEW_VIEWPORT dirty flag is set. lp_rast_shader_inputs is responsible for passing the viewport_index through the rasterizer stage to fragment stage (via lp_jit_thread_data). Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* llvmpipe: support 8bit subpixel precisionZack Rusin2013-11-251-11/+36
| | | | | | | | | | | | | 8 bit precision is required by d3d10 but unfortunately requires 64 bit rasterizer. This commit implements 64 bit rasterization with full support for 8bit subpixel precision. It's a combination of all individual commits from the llvmpipe-rast-64 branch. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: abstract the code to set number of subpixel bitsZack Rusin2013-10-091-0/+9
| | | | | | | | | | As we're moving towards expanding the number of subpixel bits and the width of the variables used in the computations we need to make this code a bit more centralized. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* Revert "llvmpipe: increase number of subpixel bits to eight"Zack Rusin2013-09-241-11/+1
| | | | | | | | | This reverts commit 755c11dc5e94f17097c186edaaa39d818396f14c. We agreed that this is band-aid that's not very useful and the proper solution is to rewrite the rasterization algo so that it operates on 64 bit values. Signed-off-by: Zack Rusin <[email protected]>
* llvmpipe: increase number of subpixel bits to eightZack Rusin2013-09-231-1/+11
| | | | | | | | | | | | | Unfortunately d3d10 requires a lot higher precision (e.g. wgf11clipping tests for it). The smallest number of precision bits with which it passes is 8. That means that we need to decrease the maximum length of an edge that we can handle without subdivision by 4 bits. Abstracted the code a bit to make it easier to change once to switch to 64bit rasterization. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: Remove lp_rast_get_num_threads().José Fonseca2013-07-221-3/+0
| | | | | | Never called. Trivial.
* llvmpipe: add support for nested / overlapping queriesRoland Scheidegger2013-06-261-0/+2
| | | | | | | | | | | | | | | | OpenGL doesn't support this but d3d10 does. It is a bit of a pain as it is necessary to keep track of queries still active at the end of a scene, which is also why I cheat a bit and limit the amount of simultaneously active queries to (arbitrary) 16 (simplifies things because don't have to deal with a real list that way). I can't think of a reason why you'd really want large numbers of overlapping/nested queries so it is hopefully fine. (This only affects queries which need to be binned.) v2: don't copy remainder of array when deleting an entry simply replace the deleted entry with the last one (order doesn't matter). Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: add support for layered renderingRoland Scheidegger2013-06-071-1/+1
| | | | | | | | | | | | | | | | Mostly just make sure the layer parameter gets passed through to the right places (and get clamped, can do this at setup time), fix up clears to clear all layers and disable opaque optimization. Luckily don't need to touch the jitted code. (Clears invoked via pipe's clear_render_target method will not work however since the pipe_util_clear function used for it doesn't handle clearing multiple layers yet.) v2: per Brian's suggestion, prettify var initialization and add some comments, add assertion for impossible layer specification for surface. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: reduce alignment requirement for resources from 64x64 to 4x4Roland Scheidegger2013-05-311-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | The overallocation was very bad especially for things like 1d array textures which got blown up by a factor of 64. (Even ordinary smallish 2d textures benefit a lot from this, a mipmapped 64x64 rgba8 texture previously used 7*16kB = 112kB instead of now ~22kB.) 4x4 is chosen because this is the size the jit functions run on, so making it smaller is going to be a bit more complicated. It is actually not strictly 4x4 pixel, since we'd want to avoid situations where different threads are rendering to the same cacheline so we keep cacheline size alignment in x direction (often 64bytes). To make this work introduce new task width/height parameters and make sure clears don't clear the whole tile if it's a partial tile. Likewise, the rasterizer may produce fragments outside the 4x4 blocks present in a tile, so don't call the jit function for them. This does not yet fix rendering to buffers (which cannot have any y alignment at all), and 1d/1d array textures are still overallocated by a factor of 4. v2: replace magic number 4 with LP_RASTER_BLOCK_SIZE, fix size of buffers allocated (needed in case we render to them). Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: handle z32s8x24 depth/stencil formatRoland Scheidegger2013-05-181-3/+3
| | | | | | | We need to split up the depth and stencil values in this case, and there's some new logic required to handle float depth and stencil simultaneously. Also make sure we get the 64bit zs clear values and masks propagated correctly.
* llvmpipe: fix clearing integer color buffersRoland Scheidegger2013-01-101-1/+1
| | | | | | | | | | | | | We get int/uint clear color value in this case, and util_pack_color can't handle these formats at all (even if it could, float input color isn't what we want). Pass through the color union appropriately and handle the packing ourselves (as I couldn't think of a good generic util solution). This gets piglit fbo_integer_precision_clear and fbo_integer_readpixels_sint_uint from the ext_texture_integer test group from segfault to pass (which only leaves fbo-blending from that group not working). v2: fix up comments
* llvmpipe: Unswizzled rendering.James Benton2012-11-281-1/+1
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Fix the 4 planes (lines) case properly.José Fonseca2011-10-051-0/+16
| | | | | | | | The previous change was not effective for lines, because there is no 4 planes 4x4 block rasterization path: it is handled by the 16x16 block case too, and the 16x16 block was not being budged as it should. This fixes assertion failures on line rasterization.
* llvmpipe: don't store plane.ei value in binned dataKeith Whitwell2010-10-151-3/+0
| | | | Further reduce the size of a binned triangle.
* llvmpipe: slightly shrink the size of a binned triangleKeith Whitwell2010-10-151-11/+19
|
* llvmpipe: don't pass frontfacing as a floatKeith Whitwell2010-10-151-1/+1
|
* llvmpipe: reintroduce SET_STATE binner commandKeith Whitwell2010-10-151-3/+3
| | | | But bin lazily only into bins which are receiving geometry.
* llvmpipe: try to do more of rast_tri_3_16 with intrinsicsKeith Whitwell2010-10-121-7/+9
| | | | | | | | There was actually a large quantity of scalar code in these functions previously. This tries to move more into intrinsics. Introduce an sse2 mm_mullo_epi32 replacement to avoid sse4 dependency in the new rasterization code.
* llvmpipe: add rast_tri_4_16 for small lines and pointsKeith Whitwell2010-10-081-5/+6
|
* llvmpipe: Cleanup depth-stencil clears.José Fonseca2010-10-061-2/+2
| | | | Only cosmetic changes. No actual practical difference.
* llvmpipe: s/boolean/unsigned/ in bitfield to silence warningBrian Paul2010-09-151-2/+2
| | | | | Using non-int types for bitfields is a gcc extension. The size of the struct is not effected by this change.
* llvmpipe: introduce tri_3_4 for tiny trianglesKeith Whitwell2010-09-121-7/+9
|
* llvmpipe: rasterization debugging helpersKeith Whitwell2010-09-071-0/+7
|
* llvmpipe: use opcodes instead of function pointers in binsKeith Whitwell2010-09-071-54/+23
| | | | Also, move some state from rasterizer struct to the scene.
* llvmpipe: rearrange queriesKeith Whitwell2010-09-071-2/+1
|
* llvmpipe: enforce fixed memory limit on scenesKeith Whitwell2010-09-071-0/+1
|
* llvmpipe: clean up deferred zstencil clearsKeith Whitwell2010-09-071-7/+8
|
* llvmpipe: rework fences and queriesKeith Whitwell2010-09-071-0/+11
|
* llvmpipe: move whole-tile emit into a functionKeith Whitwell2010-09-071-0/+1
|
* llvmpipe: eliminate tri->dx, tri->dy valuesKeith Whitwell2010-08-271-5/+0
| | | | Use an internal struct for line setup information.
* llvmpipe: update line rasterization code to current masterKeith Whitwell2010-08-271-0/+5
|
* llvmpipe: native rasterization for linesHui Qi Tay2010-08-271-1/+3
| | | | | Rasterize lines directly by treating them as 4-sided polygons. Still need to check the exact pixel rasteration.
* llvmpipe: special case triangles which fall in a single 16x16 blockKeith Whitwell2010-08-151-0/+4
| | | | | Check for these and route them to a dedicated handler with one fewer levels of recursive rasterization.
* llvmpipe: remove all traces of step arrays, pos_tablesKeith Whitwell2010-08-151-5/+0
| | | | | No need to calculate these values any longer, nor to store them in the bin data. Improves isosurf a bit more, 115->123 fps.
* llvmpipe: Remove redundant alignments.José Fonseca2010-07-141-1/+1
| | | | | | | The lp_rast_shader_inputs' alignment is irrelevant now that it contains pointers instead of actual data. Likewise, lp_rast_triangle's size alignment is meaningless.
* llvmpipe: eliminate the set_state rasterizer commandKeith Whitwell2010-07-131-3/+2
| | | | | | Just put a pointer to the state in the tri->inputs struct. Remove some complex logic for eliminating unused statechanges in bins at the expense of a slightly larger triangle struct.
* llvmpipe: pass mask into fragment shaderKeith Whitwell2010-07-131-34/+48
| | | | | | | | | Move this code back out to C for now, will generate separately. Shader now takes a mask parameter instead of C0/C1/C2/etc. Shader does not currently use that parameter and rasterizes whole pixel stamps always.
* Merge branch 'gallium-newclear'Roland Scheidegger2010-06-031-2/+14
|\ | | | | | | | | Conflicts: src/gallium/state_trackers/python/p_context.i
| * llvmpipe: adapt to clear interface changesRoland Scheidegger2010-05-291-2/+14
| | | | | | | | | | with some newfangled code, should support separate depth/stencil clears. Needs some testing.
* | llvmpipe: Pass the fs variant to the rasterizer.José Fonseca2010-05-301-6/+2
|/
* llvmpipe: implement occlusion queryQicheng Christopher Li2010-05-061-0/+8
| | | | | | | OpenGL occlusion queries work now. The Mesa demos, glean test and piglit tests all pass. A few enhancements are possible in the future. -Brian Signed-off-by: Brian Paul <[email protected]>
* llvmpipe: Move the determination of the number of threads to the screen.José Fonseca2010-04-241-1/+1
|
* Merge the lp-surface-tiling branch into master.Brian Paul2010-04-161-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This branch implemented dual representations of texture/drawing surfaces: one in the conventional linear layout and the other the tiled layout which is used by the fragment shader pipe. Per-tile flags indicate the layout of each image tile. In many situations this lets us avoid converting image data between the two layouts. Squashed commit of the following: commit 563a7e3cc552fdcfcaf9ac0d4b1683c3ba2ae732 Author: Brian Paul <[email protected]> Date: Thu Apr 8 14:48:21 2010 -0600 llvmpipe: convert points/lines to triangles with draw module This isn't the most efficient way to render points/lines but it allows us to run more tests. commit a8aa763e8a717533f2b13bb6ea53cbccbede68c9 Author: Brian Paul <[email protected]> Date: Thu Apr 8 14:47:28 2010 -0600 llvmpipe: call llvmpipe_get_texture_tile() for depth/stencil The returned pointer isn't used, but the tile status/layout info gets updated. Helps to fix glReadPixels(DEPTH / STENCIL). commit 463bc64af266194acbea71cd52e26a79b8c8a260 Author: Brian Paul <[email protected]> Date: Thu Apr 8 10:58:48 2010 -0600 llvmpipe: add store_color to debug cmd_names list commit 784cc73fb334a9d7b7c93cbd8a1445cdf742ff58 Author: Brian Paul <[email protected]> Date: Thu Apr 8 10:57:43 2010 -0600 llvmpipe: fix debug build commit 792c93171ec075664f55720ffed397ac2834a4fc Author: Brian Paul <[email protected]> Date: Thu Apr 8 10:49:01 2010 -0600 llvmpipe: fix cube mapping commit 882b1035db88c3dd8aebe28dc971ac30a9ee39e3 Author: Brian Paul <[email protected]> Date: Thu Apr 8 09:53:30 2010 -0600 llvmpipe: remove some older/unused code commit b807d32b23145301e8842824664d9f06b9c5502e Author: Brian Paul <[email protected]> Date: Thu Apr 8 09:29:50 2010 -0600 llvmpipe: silence warning commit 7b337e64fec92836ccdf9d96216289dd58418e35 Author: Brian Paul <[email protected]> Date: Wed Apr 7 17:06:08 2010 -0600 llvmpipe: clean-up, comments in lp_surface_copy() commit c52fa36f249cc652fa8d5fdd94d6574127c08c41 Author: Brian Paul <[email protected]> Date: Wed Apr 7 16:51:42 2010 -0600 llvmpipe: overhaul tiled/linear memory management Now we keep per-tile layout info (linear vs. tiled (or neither or both) and convert from one layout to the other on demand. commit 4a50ccfd470547c9be0704005818a87014e9c0e9 Author: Brian Paul <[email protected]> Date: Wed Apr 7 16:51:27 2010 -0600 llvmpipe: added tile read/write counters commit b7d0ea9c687ac8773b083791623826fa604adf21 Author: Brian Paul <[email protected]> Date: Mon Apr 5 14:54:04 2010 -0600 llvmpipe: rename some functions commit ee45c6e5b95cbd3c8cccc9aa4d45d8aef11e20c4 Author: Brian Paul <[email protected]> Date: Mon Apr 5 14:42:15 2010 -0600 llvmpipe: re-org some get block/tile pointer code commit 26ce97c16c0b6520ff1538803baa772d8c3b1280 Author: Brian Paul <[email protected]> Date: Mon Apr 5 14:34:13 2010 -0600 llvmpipe: disable bad assertions commit 5c670481248c4d46f87f13bf3af5655925e7002d Author: Brian Paul <[email protected]> Date: Fri Apr 2 16:36:11 2010 -0600 llvmpipe: add a special-case optimization to lp_surface_copy() Be more efficient when copying tiled image to linear image. Before, the fallback path was always converting the whole source image to linear. Now we can convert just a sub region. commit faa684645e64d6024b3a11e4e08da825e8220b2e Author: Brian Paul <[email protected]> Date: Fri Apr 2 16:15:16 2010 -0600 llvmpipe: assorted texture and tile/line conversion code change s The tiled/linear conversion functions take x/y positions now to allow converting only sub-regions. More texture-related helper functions. commit baad81ec5318d44bfac1e37c7643afc0836607bb Author: Brian Paul <[email protected]> Date: Tue Mar 30 13:18:40 2010 -0600 llvmpipe: convert tiled->linear upon PIPE_FLUSH_SWAPBUFFERS If we know we're about to do a swapbuffers we should immediately convert the tiled color tiles to linear instead of later in llvmpipe_texture_unmap() since we can take advantage of threading/ parallelism here. commit 928dd41256811daeddb7506a49a34dbad04beaf8 Author: Brian Paul <[email protected]> Date: Tue Mar 30 09:16:58 2010 -0600 llvmpipe: polish-up the llvmpipe_flush() code commit dd6014abcf86c517d159b8175e0eaeb167ea2ef6 Author: Brian Paul <[email protected]> Date: Tue Mar 30 09:15:17 2010 -0600 llvmpipe: SETUP_x enum clean-up commit 0b1ce6da2b28a41f3389685ab93e10b43c950f5d Author: Brian Paul <[email protected]> Date: Fri Mar 26 10:43:37 2010 -0600 llvmpipe: remove unused vars commit 4562663480f88162ed4452cb05569eecb67f9f39 Author: Brian Paul <[email protected]> Date: Fri Mar 26 10:31:55 2010 -0600 llvmpipe: cope with non-existant color/depth buffers The fragment jit functions always grab these pointers, even if they're not used. commit df4329edbaf204ed501f1eac0698b8198178f9af Author: Brian Paul <[email protected]> Date: Thu Mar 25 15:20:15 2010 -0600 llvmpipe: do all render target surface mapping/unmapping in the rast code commit 3d0c25d5ba8b8f61e8366d4c97324e45d526ff41 Author: Brian Paul <[email protected]> Date: Thu Mar 25 14:31:21 2010 -0600 llvmpipe: map z/stencil buffer on demand like color buffers Plus lots of code clean-up and loose ends taken care of. commit c3b6fddd788aef09b4b84b843b7b1272231151e8 Author: Brian Paul <[email protected]> Date: Thu Mar 25 13:15:03 2010 -0600 llvmpipe: remove unused write_zstencil field commit 63374d97836926a6357e9d6dd24a509a8e155c56 Author: Brian Paul <[email protected]> Date: Thu Mar 25 09:45:59 2010 -0600 llvmpipe: add missing lp_rast_end() call Fixes crash on window resize when LP_NUM_THREADS=0. commit 92fe9952161cc06f6edc58778e9e5a8b9ea447dc Author: Brian Paul <[email protected]> Date: Wed Mar 24 10:15:19 2010 -0600 llvmpipe: add tiled/linear conversion for 16-bit Z images commit 6605fa28c147f30df351da0e4413cab33e4db5da Author: Brian Paul <[email protected]> Date: Tue Mar 23 16:06:41 2010 -0600 llvmpipe: implement tiled/linear conversion for Z/stencil images commit 804528d84ffa292ef9d49d3666cdd3fa099ff3ff Author: Brian Paul <[email protected]> Date: Tue Mar 23 16:05:45 2010 -0600 llvmpipe: added texture stride comment commit 66a88c012edf670c4ac887a912f02dcff93266dd Author: Brian Paul <[email protected]> Date: Tue Mar 23 16:04:07 2010 -0600 llvmpipe: remove unused vars commit e2ca8d1328316dc8b36d5f688c16d109e49a6870 Author: Brian Paul <[email protected]> Date: Mon Mar 22 18:53:11 2010 -0600 llvmpipe: checkpoint WIP: overhaul texture/surface mapping Conversion between tiled and linear surfaces is working everywhere now. The LP_TEXTURE_READ/READ_WRITE/WRITE_ALL flags let us avoid unnecessary image layout conversions. Still some loose ends, temporary/debug code, etc. Need to implement tiled/linear conversion for depth/stencil images. commit f2730a03839ee8984c1f537b7cbebba24961397a Author: Brian Paul <[email protected]> Date: Mon Mar 22 14:41:58 2010 -0600 llvmpipe: rename/repurpose lp_rast_store_color() commit e192a47552c5d20d2caef452ca7697e2cd852c9b Author: Brian Paul <[email protected]> Date: Mon Mar 22 14:38:51 2010 -0600 llvmpipe: remove lp_rast_load_color() commit 3cff0bde4b4ab980e1c3e812700419091527c76b Author: Brian Paul <[email protected]> Date: Mon Mar 22 14:11:38 2010 -0600 llvmpipe: remove/consolidate texture image code commit 3a2f08b6a550c69ef5e874f482be30252cbf8bfa Author: Brian Paul <[email protected]> Date: Fri Mar 19 17:03:14 2010 -0600 llvmpipe: checkpoint WIP: directly render to tiled texture buffers We're now directly writing colors into the tiled texture image buffers. This is a checkpoint commit with lots of dead code and temporary hacks. Everything will get cleaned up eventually. commit c5ca987e03870849514d4e3c99af143722a09695 Author: Brian Paul <[email protected]> Date: Fri Mar 19 16:41:14 2010 -0600 llvmpipe: refactor code, create tile_pixel_offset() commit 2133e8273e937cbac09cd7264d6ce53af9764ddb Author: Brian Paul <[email protected]> Date: Fri Mar 19 14:55:11 2010 -0600 llvmpipe: pass LP_TEXTURE_LINEAR/TILED flags around commit b9b9d4b82b01f4588721fdc8444740f859b4a021 Author: Brian Paul <[email protected]> Date: Fri Mar 19 14:51:05 2010 -0600 llvmpipe: checkpoint WIP: hanlde co-existing tiled/linear texture data Cube maps are temporarily broken, maybe other things. commit 4cd322e6889940b5f155fcb69041b685b9ef9273 Author: Brian Paul <[email protected]> Date: Fri Mar 19 11:34:43 2010 -0600 progs/demos: add other modes/patterns to dissolve demo
* gallivm/llvmpipe: added lp_rast_shader_inputs::facing and pass throughBrian Paul2010-03-181-0/+2
| | | | | | | | | | The triangle rasterizer sets this field to indicate front/back-facing. It gets passed into the generated fragment code as another parameter. Used now for stencil front/back selection but will also be used for fragment shaders in general (see TGSI_SEMANTIC_FACE). With this commit two-sided stenciling mostly works but there's still a bug or two...
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-07 15:19:11 +0000