aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/llvmpipe/lp_texture.c
Commit message (Collapse)AuthorAgeFilesLines
* gallium: Replace u_simple_list.h with util/simple_list.hEric Anholt2015-01-281-1/+1
| | | | | | | The code was exactly the same, except util/ has c++ guards and a struct simple_node declaration. Reviewed-by: Marek Olšák <[email protected]>
* llvmpipe: remove special case for PIPE_TEXTURE_CUBE in llvmpipe_texture_layout()Brian Paul2014-09-301-3/+6
| | | | | | | layers (aka array_size) should be 6 for cube textures so we don't need to special-case it. But add an assertion just to be safe. Reviewed-by: Ilia Mirkin <[email protected]>
* llvmpipe: implement support for cube map arraysRoland Scheidegger2014-08-051-1/+2
| | | | | | | | This just covers the resource side of things, not the actual sampling. Here things are trivial as cube map arrays are identical to 2d arrays in all respects. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: don't store number of layers per levelRoland Scheidegger2014-08-011-76/+48
| | | | | | | | | | | | | | | | This could be recalculated, though it turns out the only use of it after resource allocation is for calculating whole resource size (for scene size accounting though that isn't quite ideal neither). Thus, instead just store the whole resource size and drop it (saving a couple bytes of storage per resource). It makes things simpler too. Note that for the accounting winsys resources always come back with size 0 but this is unchanged (we don't actually know the size in any case). Also reformat llvmpipe_texture_layout (drop unneded indentation). v2: adapt to previous changes. Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: integrate memory allocation into llvmpipe_texture_layoutRoland Scheidegger2014-08-011-45/+29
| | | | | | | | | | | | | | | Seems pointless to just duplicate some of the calculations (the calculation of actual memory used compared to what was predicted in llvmpipe_texture_layout actually could have differed slightly in some cases due to different alignment rules used though this should have been of no consequence). v2: keep the previous mip alignment of MAX2(64, cacheline). This was added for ARB_map_buffer_alignment - I'm not convinced it's needed for textures, but it was supposed to be cleanup without functional change. Also replace div with 64bit mul / comparison. Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: get rid of impossible code in alloc_image_dataRoland Scheidegger2014-08-011-26/+13
| | | | | | | Only used for non display target resources. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: get rid of llvmpipe_get_texture_tile_linearRoland Scheidegger2014-07-021-30/+2
| | | | | | | | | | | | | | Because the layout is always linear this didn't really do much any longer - at some point this triggered per-tile swizzled->linear conversion. The x/y coords were ignored too. Apart from triggering conversion, this also invoked alloc_image_data(), which could only actually trigger mapping of display target resources. So, instead just call resource_map in the callers (which also gives the ability to unmap again). Note that mapping/unmapping of display target resources still isn't really all that clean (map/unmap may be unmatched, and all such mappings use the same pointer thus usage flags are a lie). Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: get rid of llvmpipe_get_texture_imageRoland Scheidegger2014-07-021-47/+1
| | | | | | | | The only caller left used it only for non display target textures, hence it was really the same as llvmpipe_get_texture_image_address - it also had a usage flag but this was ignored anyway. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: get rid of llvmpipe_get_texture_image_allRoland Scheidegger2014-07-021-23/+0
| | | | | | | | | | | Once used for invoking swizzled->linear conversion for all needed images. But we now have a single allocation for all images in a resource, thus looping through all slices is rather pointless, conversion doesn't happen neither. Also simplify the sampling setup code to use the mip_offsets array in the resource directly - if the (non display target) resource exists its memory will already be allocated as well. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: allocate regular texture memory upfrontRoland Scheidegger2014-07-021-0/+7
| | | | | | | | | | | The deferred allocation doesn't really make much sense anymore, since we no longer allocate swizzled/linear memory in chunks and not per level / slice neither. This means we could fail resource creation a bit more (could already fail in theory anyway) but should not fail maps later (right now, callers can't deal with neither really). Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: get rid of linear_img structRoland Scheidegger2014-07-021-23/+16
| | | | | | | Just use a tex_data pointer directly - the description was no longer correct neither. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: (trivial) rename linear_mip_offsets to mip_offsetsRoland Scheidegger2014-07-021-3/+3
| | | | | | | Since switching to non-swizzled rendering we only have "normal", aka linear, offsets. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: Fix zero-division in llvmpipe_texture_layout()Takashi Iwai2014-06-251-1/+1
| | | | | | | | | | | Fix the crash of "gnome-control-center info" invocation on QEMU where zero height is passed at init. (sroland: simplify logic by eliminating the div altogether, using 64bit mul.) Fixes: https://bugzilla.novell.com/show_bug.cgi?id=879462 Cc: "10.2" <[email protected]>
* llvmpipe: Use alignment of 64 instead of 16 for buffer allocationSiavash Eliasi2014-01-291-3/+3
| | | | | | v2: Changed allocation alignment of llvmpipe_displaytarget_layout. Reviewed-by: Ian Romanick <[email protected]>
* s/Tungsten Graphics/VMware/José Fonseca2014-01-171-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tungsten Graphics Inc. was acquired by VMware Inc. in 2008. Leaving the old copyright name is creating unnecessary confusion, hence this change. This was the sed script I used: $ cat tg2vmw.sed # Run as: # # git reset --hard HEAD && find include scons src -type f -not -name 'sed*' -print0 | xargs -0 sed -i -f tg2vmw.sed # # Rename copyrights s/Tungsten Gra\(ph\|hp\)ics,\? [iI]nc\.\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./g /Copyright/s/Tungsten Graphics\(,\? [iI]nc\.\)\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./ s/TUNGSTEN GRAPHICS/VMWARE/g # Rename emails s/[email protected]/[email protected]/ s/[email protected]/[email protected]/g s/jrfonseca-at-tungstengraphics-dot-com/jfonseca-at-vmware-dot-com/ s/jrfonseca\[email protected]/[email protected]/g s/keithw\[email protected]/[email protected]/g s/[email protected]/[email protected]/g s/thomas-at-tungstengraphics-dot-com/thellstom-at-vmware-dot-com/ s/[email protected]/[email protected]/ # Remove dead links s@Tungsten Graphics (http://www.tungstengraphics.com)@Tungsten Graphics@g # C string src/gallium/state_trackers/vega/api_misc.c s/"Tungsten Graphics, Inc"/"VMware, Inc"/ Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: move create_surface/destroy_surface functions to lp_surface.cRoland Scheidegger2013-06-071-58/+1
| | | | | | | Believe it or not but these two are actually the first two functions which really belong in this file nowadays. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: add support for layered renderingRoland Scheidegger2013-06-071-4/+2
| | | | | | | | | | | | | | | | 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 1d resources from 4x4 to 4x1Roland Scheidegger2013-06-051-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For rendering to buffers, we cannot have any y alignment. So make sure that tile clear commands only clear up to the fb width/height, not more (do this for all resources actually as clearing more seems pointless for other resources too). For the jit fs function, skip execution of the lower half of the fragment shader for the 4x4 stamp completely, for depth/stencil only load/store the values from the first row (replace other row with undef). For the blend function, also only load half the values from fs output, replace the rest with undefs so that everything still operates on the full 4x4 block to keep code the same between 4x1 and 4x4 (except for load/store of course which also needs to skip (store) or replace these values with undefs (load))., at the cost of slightly less optimal code being produced in some cases. Also reduce 1d and 1d array alignment too, because they can be handled the same as buffers so don't need to waste memory. v2: don't try to run special blend code for 4x1, (very) slightly less complexity if we just use the same code as for 4x4 which may or may not make it easier to optimize in the future (as we care a lot more about 4x4 performance than 1d). v2: don't use undef values for unused fs src outputs with llvm 3.1 as it apparently can trigger a bug in llvm. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: fix bogus assertions for buffer surfacesRoland Scheidegger2013-06-011-2/+2
| | | | | | | | | | One of the assertion made no sense for buffer rendertargets (due to the union), so drop it. (The same assertion is present already in the path for texture surfaces later.). v2: make assertion completely accurate (suggested by Jose). Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: reduce alignment requirement for resources from 64x64 to 4x4Roland Scheidegger2013-05-311-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | 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: get rid of tiled/linear layout remainsRoland Scheidegger2013-05-291-171/+26
| | | | | | | Eliminate the rest of the no longer needed layout logic. (It is possible some code could be simplified a bit further still.) Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: get rid of unused tiled/linear logicRoland Scheidegger2013-05-181-343/+45
| | | | | | | | | We do rendering to linear color buffers for quite some time, and since switching to linear depth buffers all the tiled/linear logic was unused. So get rid of (most) of it - there's still some LAYOUT_NONE things and late allocation of resources which probably could be simplified. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Take in consideration all current constant buffers when mapping.José Fonseca2013-04-181-3/+9
| | | | | Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Zack Rusin <[email protected]>
* llvmpipe: don't assert when trying to render to surfaces with multiple layersRoland Scheidegger2013-03-141-0/+3
| | | | | | | instead just warn when creating the surface, rendering will simply happen to first layer. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: don't assert on illegal surface creation.Roland Scheidegger2013-03-021-1/+2
| | | | | | | | | | | | Since c8eb2d0e829d0d2aea6a982620da0d3cfb5982e2 llvmpipe checks if it's actually legal to create a surface. The opengl state tracker doesn't quite obey this so for now just warn instead of assert. Also warn instead of disabled assert when creating sampler views (same reasoning). Addresses https://bugs.freedesktop.org/show_bug.cgi?id=61647. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: check buffers in llvmpipe_is_resource_referenced.Roland Scheidegger2013-02-281-1/+10
| | | | | | | | | | | Now that buffers can be used as textures or render targets make sure they aren't skipped. Fix suggested by Jose Fonseca. v2: added a couple of assertions so we can actually guarantee we check the resources and don't skip them. Also added some comments that this is actually a lie due to the way the opengl buffer api works.
* llvmpipe: support rendering to buffer render targets.Roland Scheidegger2013-02-281-11/+33
| | | | | | | | | | Unfortunately not usable from OpenGL, and no cap bit. Pretty similar to a 1d texture, though allows specifying a start element. v2: also fix up renderbuffer width (which will get promoted to fb width) to be the number of elements Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: support GL_ARB_texture_buffer_object/GL_ARB_texture_buffer_rangeRoland Scheidegger2013-02-251-29/+7
| | | | | | | | | | | | | | | | | | | | This also fixes not honoring first/last_layer view parameters for array textures, plus not honoring last_level view parameter for all textures (neither is really used by OpenGL). This mostly passes piglit arb_texture_buffer_object tests (it needs, however, glsl 140 version override, plus GL 3.1 override, the latter only because mesa does not allow ARB_tbo in non-core contexts). Most arb_texture_buffer_object tests pass, with the exception of arb_texture_buffer_object-formats. With "arb" parameter it passes most weirdo formats before it segfaults in the state tracker, this looks to be some issue with using legacy formats in core context (fails the same in softpipe). With "core" parameter it passes with "fs", however fails with "vs" (for most formats). This will be fixed later (debugging shows we're completely missing the shader recompile depending on format). v2: based on Jose's feedback, fix comments, variable/function names. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Fix creation of shared and scanout textures.John Kåre Alsaker2013-02-231-1/+3
| | | | | | NOTE: This is a candidate for the stable branches. Signed-off-by: José Fonseca <[email protected]>
* llvmpipe: simplify buffer allocation logic.Roland Scheidegger2013-02-221-7/+5
| | | | | | | | | Now with buffer formats clarification don't need all that logic any longer. (Note that it never would have worked in any case, because blockwidth and blockheight were swapped any allocation with multi-byte format would have had zero size.) Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: lp_resource_copy cleanupRoland Scheidegger2013-02-201-2/+1
| | | | | | | | We don't need to flush resources for each layer, and since we don't actually care about layer at all in the flush function just drop the parameter. Also we can use util_copy_box instead of repeated util_copy_rect. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: fix handling of 0 x 0 framebuffer sizeBrian Paul2013-02-191-2/+2
| | | | | | | Bump up the size to 1 x 1. This fixes a number of potential failure points in the code. See also http://bugs.freedesktop.org/show_bug.cgi?id=61012
* gallium: remove pipe_surface::usageMarek Olšák2012-12-121-1/+0
| | | | | | Not really used by anybody now. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: support pipe_resource-based constant buffersBrian Paul2012-12-111-1/+5
| | | | | | | | | | | | | | | | Before this we only supported user-based constant buffers. First, we basically plumb pipe_constant_buffer objects through llvmpipe rather than pipe_resource objects. Second, update llvmpipe_set_constant_buffer() and try_update_scene_state() so they understand both resource- and user-based constant buffers. The problem with user constant buffers is the potential for use-after-free, as seen in some WebGL tests. The next patch will flip the switch for resource-based const buffers. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: support array texturesRoland Scheidegger2012-11-291-2/+10
| | | | | | | | | | This adds array (1d,2d) texture support to llvmpipe. Though probably should do something about 1d array textures requiring gobs of memory (this issue is not strictly limited to arrays but it is probably worse there). Initial code by Jakob Bornecrantz <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* llvmpipe: Eliminate color buffer swizzling.José Fonseca2012-11-291-107/+0
| | | | | | | | | | | | Now dead code. Also had to remove the show_tiles/show_subtiles because now the color buffers are always stored in their native format, so there is no longer an easy way to paint the tile sizes. Depth-stencil buffers are still swizzled. Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: Only advertise unswizzled formats.José Fonseca2012-11-291-17/+6
| | | | | | | | | | | | | | Update llvmpipe_is_format_supported and llvmpipe_is_format_unswizzled so that only the formats that we can render without swizzling are advertised. We can still render all D3D10 required formats except PIPE_FORMAT_R11G11B10_FLOAT, which needs to be implemented in a future opportunity. Removal of rendertarget swizzling will be done in a subsequent change. Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: Update llvmpipe_is_format_unswizzled to reflect latest changes.James Benton2012-11-281-9/+0
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Unswizzled rendering.James Benton2012-11-281-0/+67
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: always allocate whole miptrees not individual levelsRoland Scheidegger2012-11-121-58/+76
| | | | | | | | This is preparation work for using mip level offsets + base_ptr for texture sampling instead of per-mip pointers. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* gallium: unify transfer functionsMarek Olšák2012-10-111-62/+42
| | | | | | | | | | | | | | "get_transfer + transfer_map" becomes "transfer_map". "transfer_unmap + transfer_destroy" becomes "transfer_unmap". transfer_map must create and return the transfer object and transfer_unmap must destroy it. transfer_map is successful if the returned buffer pointer is not NULL. If transfer_map fails, the pointer to the transfer object remains unchanged (i.e. doesn't have to be NULL). Acked-by: Brian Paul <[email protected]>
* llvmpipe: fix overflow bug in total texture size computationBrian Paul2012-09-201-2/+16
| | | | | | | | | | | | | | | | v2: use uint64_t for the total_size variable, per Jose. Also add two earlier checks for exceeding the max texture size. For example a 1K^3 RGBA volume would overflow the lpr->image_stride variable. Use simple algebra to avoid overflow in intermediate values. So instead of "x * y > z" use "x > z / y". This should work if we happen to be on a platform that doesn't have 64-bit types. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: implement the new can_create_resource() functionBrian Paul2012-09-171-5/+23
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* Remove useless checks for NULL before freeingMatt Turner2012-09-051-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Same as earlier commit, except for "FREE" This patch has been generated by the following Coccinelle semantic patch: // Remove useless checks for NULL before freeing // // free (NULL) is a no-op, so there is no need to avoid it @@ expression E; @@ + FREE (E); + E = NULL; - if (unlikely (E != NULL)) { - FREE(E); ( - E = NULL; | - E = 0; ) ... - } @@ expression E; type T; @@ + FREE ((T) E); + E = NULL; - if (unlikely (E != NULL)) { - FREE((T) E); ( - E = NULL; | - E = 0; ) ... - } @@ expression E; @@ + FREE (E); - if (unlikely (E != NULL)) { - FREE (E); - } @@ expression E; type T; @@ + FREE ((T) E); - if (unlikely (E != NULL)) { - FREE ((T) E); - } Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: Bump the maximum texture size (in pixels).José Fonseca2012-08-281-0/+6
| | | | | | | | | | But cap the size in bytes, to avoid depleting the whole system memory, with humongus textures. Tested with max-texture-size piglit test. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* gallium: remove user_buffer_create from the interfaceMarek Olšák2012-05-121-2/+0
| | | | Nothing uses it now.
* gallium: remove pipe_resource::user_ptrMarek Olšák2012-04-301-1/+0
| | | | It's unused now.
* gallium: add void *user_buffer to pipe_constant_bufferMarek Olšák2012-04-301-1/+1
| | | | This reduces CPU overhead when updating constants.
* gallium: add user_ptr in pipe_resourceMarek Olšák2012-04-241-0/+1
| | | | I need to access the pointer in st/mesa when I only have pipe_resource.
* Revert "gallium: add flag PIPE_TRANSFER_MAP_PERMANENTLY"Marek Olšák2012-03-051-4/+0
| | | | | | | This reverts commit 0950086376b1c8b7fb89eda81ed7f2f06dee58bc. It was decided to refactor the transfer API instead of adding workarounds to address the performance issues.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-05 01:20:29 +0000