aboutsummaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/llvmpipe
Commit message (Collapse)AuthorAgeFilesLines
* softpipe,llvmpipe: mark BPTC formats as unsupportedIlia Mirkin2014-08-121-0/+5
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe/tests: automake: link against libmesautil.laEmil Velikov2014-08-051-5/+6
| | | | | | | Or the build will fail due to unresolved symbols. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* llvmpipe: implement support for cube map arraysRoland Scheidegger2014-08-055-4/+16
| | | | | | | | 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]>
* gallium: Move sRGB <-> RGB handling to libmesautilJason Ekstrand2014-08-041-1/+1
| | | | | Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* llvmpipe: don't store number of layers per levelRoland Scheidegger2014-08-012-78/+50
| | | | | | | | | | | | | | | | 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]>
* dri: Add a new capabilities for drivers that can't share buffersGiovanni Campagna2014-07-301-1/+1
| | | | | | | | | | | | | | | | | | | The kms-dri swrast driver cannot share buffers using the GEM, so it must tell the loader to disable extensions relying on that, without disabling the image DRI extension altogether (which would prevent the loader from working at all). This requires a new gallium capability (which is queried on the pipe_screen and for swrast drivers it's forwarded to the winsys), and requires a new version of the DRI image extension. [Emil Velikov] - Rebased on top of gallium-dri megadrivers. - Drop PIPE_CAP_BUFFER_SHARE and sw_winsys::get_param hook. The can_share_buffer cap is set at InitScreen. We use a different InitScreen (and thus value for the cap) function for kms_dri, due to deeper differences originating from dri megadrivers. Signed-off-by: Emil Velikov <[email protected]>
* gallium: rename PIPE_CAP_TGSI_VS_LAYER to also have _VIEWPORTIlia Mirkin2014-07-031-1/+1
| | | | | | | | | Now that this cap is used to determine the availability of both, adjust its name to reflect the new reality. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* llvmpipe: get rid of llvmpipe_get_texture_tile_linearRoland Scheidegger2014-07-023-107/+17
| | | | | | | | | | | | | | 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-022-52/+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-024-65/+7
| | | | | | | | | | | 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-024-33/+19
| | | | | | | 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-024-6/+6
| | | | | | | Since switching to non-swizzled rendering we only have "normal", aka linear, offsets. Reviewed-by: Brian Paul <[email protected]>
* gallium: add facilities for indirect drawingChristoph Bumiller2014-07-022-0/+8
| | | | | | 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]>
* gallium: add an index argument to create_queryIlia Mirkin2014-07-011-1/+2
| | | | | | Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Roland Scheidegger <[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: 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]>
* 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]>
* llvmpipe: (trivial) drop "unswizzled" from some function namesRoland Scheidegger2014-05-312-28/+30
| | | | | | | This made sense when swizzled storage layout was used for rendering to tiles. But nowadays the name just adds confusion (and makes for long lines). Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: fix crash when not all attachments are populated in a fbRoland Scheidegger2014-05-311-3/+9
| | | | | | | | | | | | Framebuffers can have NULL attachments since a while. llvmpipe handled that properly for lp_rast_shade_quads_mask but it seems the change didn't make it to lp_rast_shade_tile. This fixes piglit fbo-drawbuffers-none test (though I need to increase the FB_SIZE from 32 to 256 so the tris cover some tiles fully). https://bugs.freedesktop.org/show_bug.cgi?id=79421 Cc: "10.1 10.2" <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: honor the render_condition_enable bit in blits.Roland Scheidegger2014-05-311-0/+3
| | | | | | | This fixes piglit nv_conditional_render-blitframebuffer. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: do IR counting for shader cache management after optimization.Roland Scheidegger2014-05-191-2/+2
| | | | | | | | | | | 2ea923cf571235dfe573c35c3f0d90f632bd86d8 had the side effect of IR counting now being done after IR optimization instead of before. Some quick analysis shows that there's roughly 1.5 times more IR instructions before optimization than after, hence the effective shader cache size got quite a bit smaller. Could counter this with an increase of the instruction limit but it probably makes more sense to count them after optimizations, so move that code. Reviewed-by: Brian Paul <[email protected]>
* gallivm: give more verbose names to modulesRoland Scheidegger2014-05-167-16/+21
| | | | | | | | | When we had just one module "gallivm" was an appropriate name. But now we have modules containing all functions for a particular variant, so give it a corresponding name (this is really just for helping debugging). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: improve setup shader names (for debugging)Roland Scheidegger2014-05-151-38/+40
| | | | | | | | | | | | | The setup shaders were composed of both a fs shader number and a variant number. But since they aren't tied to a particular fragment shader, the former was a fixed zero while the latter was also always zero because it was never assigned. So, similar to what the fs code does, use a ever increasing number to give it a more catchy name (unlike fragment shaders though where this number is for each explicitly created shader, we just use it for the implicitly created variants). And while here, fix whitespace a bit. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: kill off llvmpipe_variant_countRoland Scheidegger2014-05-154-20/+4
| | | | | | | Unused except it was increased for both fs and setup shader variants created. Probably some leftover from ages ago. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Delete unneeded LLVM stuff earlier.José Fonseca2014-05-147-34/+16
| | | | | | Same as Frank's change to draw module but for llvmpipe module. Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm,draw,llvmpipe: Remove support for versions of LLVM prior to 3.1.José Fonseca2014-05-141-28/+0
| | | | | | | Older versions haven't been tested probably don't work anyway. But more importantly, code supporting it is hindering further work. Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: change LP_MAX_SHADER_INSTRUCTIONS limit definition.Roland Scheidegger2014-05-081-1/+3
| | | | | | | | | | When the limit was changed to be defined in terms of LP_MAX_SHADER_VARIANTS (75f1fea14f524ef05e980d825fda3ae226ae2ffe) when it was increased, this inadvertently lowered the limit in some branches (that have a lower LP_MAX_SHADER_VARIANTS number) when merged. So, make sure the limit is always at least the number it once was. Reviewed-by: Jose Fonseca <[email protected]>
* gallium: add a cap for supporting 4-offset TG4 opcodesIlia Mirkin2014-05-071-0/+1
| | | | | 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]>
* llvmpipe: fix clearing of individual color buffers in a fbRoland Scheidegger2014-04-256-163/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: (trivial) use correct LP_MIN_VECTOR_ALIGN define for alignment.Roland Scheidegger2014-04-251-1/+1
| | | | | | Currently it's the same value. Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: Advertise GLSL 3.30.José Fonseca2014-04-241-1/+1
| | | | | | | | | | According to Roland all TGSI support is there in theory. In practice there are a few piglit failures and crashes, as this hadn't been tested before. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: add a way to query min/max texture gather offsetsIlia Mirkin2014-04-101-0/+2
| | | | | | | | Defaults to providing the same offsets as MIN/MAX_TEXEL_OFFSET. For nvc0, the offset can be -32/31. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium: add support for LODQ opcodes.Dave Airlie2014-04-071-0/+1
| | | | | | | | | This opcode provide support for GL_ARB_texture_query_lod, Signed-off-by: Dave Airlie <[email protected]> [imirkin: rebase, docs update] Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* llvmpipe: remove no-op checks in sampler, sampler_view functionsBrian Paul2014-04-031-14/+0
| | | | | Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* mesa/soft/llvmpipe: add fake MSAA supportDave Airlie2014-04-021-0/+2
| | | | | | | | This adds a gallium cap that allows us to fake GL3.0 by not exposing MSAA on sw rendering. It also forces the extra extensions needed for GL3.2. Signed-off-by: Dave Airlie <[email protected]>
* llvmpipe: Fix llvmpipe_create_gs_state.Zack Rusin2014-03-261-3/+5
| | | | | | | Revert unintended behaviour change from commit b995a010e688bc4d4557e973e5e28091c378e881. Tested-by: José Fonseca <[email protected]>
* llvmpipe: Simplify vertex and geometry shaders.José Fonseca2014-03-255-70/+33
| | | | | | | | | | | | Eliminate lp_vertex_shader, as it added nothing over draw_vertex_shader. Simplify lp_geometry_shader, as most of the incoming state is unneeded. (We could also just use draw_geometry_shader if we were willing to peek inside the structure.) Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Zack Rusin <[email protected]>
* llvmpipe: add support for b5g6r5_srgbRoland Scheidegger2014-03-212-4/+36
| | | | | | | | | | | | | The conversion code for srgb was tuned for n x 4x8bit AoS -> 4 x nxfloat SoA (and vice versa), fix this to handle also 16bit 565-style srgb formats. Still not really all that generic, things like r10g10b10a2_srgb or r4g4b4a4_srgb wouldn't work (the latter trivial to fix, the former would not require more work to not crash but near certainly need some higher precision calculation) but not needed right now. The code is not fully optimized for this (could use more direct calculation instead of expanding to 8-bit range first) but should be good enough. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Tighten check for alpha-only formatsRichard Sandiford2014-03-201-1/+1
| | | | | | | | | | | The AoS version of ld_build_blend_factor was assuming that if the first channel was alpha, there were no rgb components. Fixes glean/blendFunc on System z. No piglit regressions on x86_64. The shortcut is still used in tests like spec/ARB_framebuffer_object/ fbo-alpha. Signed-off-by: Richard Sandiford <[email protected]>
* gallium: allow setting of the internal stream output offsetZack Rusin2014-03-071-6/+6
| | | | | | | | | | | | | | | | D3D10 allows setting of the internal offset of a buffer, which is in general only incremented via actual stream output writes. By allowing setting of the internal offset draw_auto is capable of rendering from buffers which have not been actually streamed out to. Our interface didn't allow. This change functionally shouldn't make any difference to OpenGL where instead of an append_bitmask you just get a real array where -1 means append (like in D3D) and 0 means do not append. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* gallium: the other drivers don't support ARB_buffer_storageMarek Olšák2014-02-251-0/+1
| | | | Reviewed-by: Fredrik Höglund <[email protected]>
* gallium: add texture gather support to gallium (v3)Dave Airlie2014-02-251-0/+2
| | | | | | | | | | | | | | | | | | | | | This adds support to gallium for a TG4 instruction, and two CAPs. The first CAP is required for GL_ARB_texture_gather. The second CAP is required to expose GL_ARB_gpu_shader5. However so far we haven't found any hardware that natively exposes the textureGatherOffsets feature from GL, so just lower it for now. If hardware appears for this we can add another CAP to allow TG4 to take 4 offsets. v2: add component selection src and a cap to say hw can do it. (st can use to help control GL_ARB_gpu_shader5/GLSL 4.00). Add docs. v3: rename to SM5, add docs. Reviewed-by: Roland Scheidegger <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* gallium: add geometry shader output limitsGrigori Goronzy2014-02-091-0/+3
| | | | | | | | v2: adjust limits for radeonsi and llvmpipe v3: add documentation Cc: "10.1" <[email protected]> Signed-off-by: Marek Olšák <[email protected]>
* gallium: remove PIPE_CAP_MAX_COMBINED_SAMPLERSMarek Olšák2014-02-041-2/+0
| | | | | | | This can be derived from the shader caps. All GPUs from ATI/AMD, NVIDIA, and INTEL have separate texture slots for each shader stage.
* llvmpipe: fix denorm handling for r11g11b10_float format when blendingRoland Scheidegger2014-01-311-2/+15
| | | | | | | | The code re-enabling denorms for small float formats did not recognize this format due to format handling hacks (mainly, the lp_type doesn't have the floating bit set). Reviewed-by: Jose Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 14:31:07 +0000