summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers/llvmpipe
Commit message (Collapse)AuthorAgeFilesLines
* llvmpipe: implement PIPE_QUERY_SO_STATISTICSZack Rusin2013-04-102-0/+21
| | | | | | | | | | We were missing the implementation of PIPE_QUERY_SO_STATISTICS query, this change implements it on top of the existing facilities. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: Work without sse2 if llvm is new enoughAdam Jackson2013-04-051-2/+3
| | | | | | | | At least on llvm 3.2 this appears to work fine. Tested on an Athlon XP 2600+, which has sse and 3dnow but not sse2. Reviewed-by: Jose Fonseca <[email protected]> Signed-off-by: Adam Jackson <[email protected]>
* draw/llvmpipe: allow independent so attachments to the vsZack Rusin2013-04-032-9/+27
| | | | | | | | | | | | | | When geometry shaders are present, one needs to be able to create an empty geometry shader with stream output that needs to be resolved later and attached to the currently bound vertex shader. Lets add support for it to llvmpipe and draw. draw allows attaching independent stream output info to any vertex shader and llvmpipe resolves at draw time which vertex shader the given empty geometry shader should be linked to. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* llvmpipe: reset so buffers when not appendingZack Rusin2013-04-031-0/+6
| | | | | | | | | We need to reset the internal state of the so buffers or we'll keep appending even though we're not supposed to. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* gallium: add PIPE_CAP_QUERY_PIPELINE_STATISTICSChristoph Bumiller2013-04-031-0/+2
| | | | Reviewed-by: Marek Olšák <[email protected]>
* llvmpipe: use triangle subdivision to avoid fixed-point overflow issuesBrian Paul2013-04-013-0/+186
| | | | | | | | | | | | If we're drawing to a surface that's 2048 x 2048 pixels or larger there's danger of fixed-point overflow in the triangle rasterization code. That leads to various rendering glitches. Rather than implement some intricate changes to the rasterization code, simply subdivide triangles into smaller subtriangles to avoid the issue. Only do this when the drawing surface is larger than 2048 by 2048. Reviewed-by: José Fonseca <[email protected]>
* llvmpipe: add 'f' suffix to 1.0 in fixed_to_float()Brian Paul2013-03-281-1/+1
|
* llvmpipe/draw: Fix texture sampling in geometry shadersZack Rusin2013-03-275-9/+62
| | | | | | | | | We weren't correctly propagating the samplers and sampler views when they were related to geometry shaders. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* gallium/llvm: implement geometry shaders in the llvm pathsZack Rusin2013-03-271-2/+2
| | | | | | | | | This commits implements code generation of the geometry shaders in the SOA paths. All the code is there but bugs are likely present. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* gallivm: init vars to silence warningsBrian Paul2013-03-251-2/+2
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Fix assertions with assignment instead of comparison.Vinson Lee2013-03-241-2/+2
| | | | | | | Fixes assign instead of compare defects reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallium,st/mesa: don't use blit-based transfers with software rasterizersMarek Olšák2013-03-231-0/+2
| | | | | | | | | The blit-based paths for TexImage, GetTexImage, and ReadPixels aren't very fast with software rasterizer. Now Gallium drivers have the ability to turn them off. Reviewed-by: Brian Paul <[email protected]> Tested-by: Brian Paul <[email protected]>
* llvmpipe: add EXT_packed_float render target format supportRoland Scheidegger2013-03-222-2/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New conversion code to handle conversion from/to r11g11b10 AoS to/from SoA floats, and also add code for conversion from rgb9e5 AoS to float SoA (which works pretty much the same as r11g11b10 except for the packing). (This code should also be used for texture sampling instead of relying on u_format conversion but it's not yet, so rgb9e5 is unused.) Unfortunately a crazy amount of hacks is necessary to get the conversion code running in llvmpipe's generate_unswizzled_blend, which isn't well suited for formats where the storage representation has nothing to do with what's needed for blending (moreover, the conversion will convert from packed AoS values, which is the storage format, to float SoA values, because this is much more natural for the conversion, and likewise from SoA values to packed AoS values - but the "blend" (which includes trivial things like partial mask) works on AoS values, so incoming fs values will go SoA->AoS, values from destination will go packed AoS->SoA->AoS, then do blend, then AoS->SoA->packed AoS which probably isn't the most efficient way though the shuffles are probably bearable). Passes piglit fbo-blending-formats (with GL_EXT_packed_float parameter), still need to verify Inf/NaNs (where most of the complexity in the conversion comes from actually). v2: drop the (very bogus) rgb9e5 part, and do component extraction in the helper code for r11g11b10 to float conversion, making the code slightly more compact (suggested by Jose), now that there are no other callers left this works quite well. (Could do the same for the opposite way but it's less than ideal there, final part of packing needs to be done in caller anyway and there'd be another conditional.) v3: minor style and comment fixes. Also fix a potential issue with negative zero being potentially returned by max(src, zero) as we don't have well-defined min/max behavior (fortunately no additonal cost). Reviewed-by: Jose Fonseca <[email protected]>
* gallium: add TGSI_SEMANTIC_TEXCOORD,PCOORD v3Christoph Bumiller2013-03-201-0/+1
| | | | | | | | | | | | | | | This makes it possible to identify gl_TexCoord and gl_PointCoord for drivers where sprite coordinate replacement is restricted. The new PIPE_CAP_TGSI_TEXCOORD decides whether these varyings should be hidden behind the GENERIC semantic or not. With this patch only nvc0 and nv30 will request that they be used. v2: introduce a CAP so other drivers don't have to bother with the new semantic v3: adapt to introduction gl_varying_slot enum
* llvmpipe: don't assert when trying to render to surfaces with multiple layersRoland Scheidegger2013-03-142-2/+3
| | | | | | | instead just warn when creating the surface, rendering will simply happen to first layer. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Fix geometry shader token leak.José Fonseca2013-03-131-0/+1
| | | | Trivial. Matches softpipe's code.
* llvmpipe: remove the power of two sizeof(struct cmd_block) assertionBrian Paul2013-03-071-7/+0
| | | | | | | It fails on 32-bit systems (I only tested on 64-bit). Power of two size isn't required, so just remove the assertion. Reviewed-by: José Fonseca <[email protected]>
* llvmpipe: fix incorrect 'j' array index in dummy texture codeBrian Paul2013-03-061-3/+3
| | | | | | Use 0 instead. Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: remove unused cmd_block_list structBrian Paul2013-03-061-4/+0
|
* llvmpipe: add some scene limit sanity check assertionsBrian Paul2013-03-061-0/+22
| | | | | | Note: This is a candidate for the stable branches. Reviewed-by: José Fonseca <[email protected]>
* llvmpipe: tweak CMD_BLOCK_MAX and LP_SCENE_MAX_SIZEBrian Paul2013-03-061-2/+8
| | | | | | | | | | | | | | | | | | | | We advertise a max texture/surfaces size of 8K x 8K but the old values for these limits didn't actually allow us to handle that surface size. For 8K x 8K we'll have 16384 bins. Each bin needs at least one cmd_block object which was 2192 bytes in size. Since 16384 * 2192 exceeded LP_SCENE_MAX_SIZE we'd silently fail in lp_scene_new_data_block() and not draw the complete scene. By reducing CMD_BLOCK_MAX to 29 we get nice 512-byte cmd_blocks. And by increasing LP_SCENE_MAX_SIZE to 9 MB we can allocate enough command blocks for 8K x 8K, plus a few regular data blocks. Fixes the (improved) piglit fbo-maxsize test. Note: This is a candidate for the stable branches. Reviewed-by: José Fonseca <[email protected]>
* llvmpipe: don't assert on illegal surface creation.Roland Scheidegger2013-03-022-4/+4
| | | | | | | | | | | | 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: bump glsl version to 140Roland Scheidegger2013-03-021-1/+1
| | | | | | | | | | | | | texel offsets should have been the last missing feature for 130, and in fact 140 as well (last there were texture buffers). In any case we still don't do OpenGL 3.0 (missing MSAA which will be difficult, plus EXT_packed_float, ARB_depth_buffer_float and EXT_framebuffer_sRGB). v2: bump to 140 instead - we have everything except we crash when not writing to gl_Position (but softpipe crashes as well) so let's just say this is a bug instead. Also (by Dave Airlie's suggestion) update llvm-todo.txt. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: check buffers in llvmpipe_is_resource_referenced.Roland Scheidegger2013-02-283-8/+24
| | | | | | | | | | | 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-284-47/+61
| | | | | | | | | | 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: (trivial) get rid of old function prototypes.Roland Scheidegger2013-02-251-7/+0
| | | | | llvmpipe_init_screen/context_texture_funcs have long been replaced with the respective "resource" funcs.
* llvmpipe: support GL_ARB_texture_buffer_object/GL_ARB_texture_buffer_rangeRoland Scheidegger2013-02-256-103/+177
| | | | | | | | | | | | | | | | | | | | 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: rename polygon offset fields to something more specificBrian Paul2013-02-222-8/+11
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: add missing checks for polygon offset point/line modesBrian Paul2013-02-221-0/+6
| | | | | | | | | | | The llvm pipeline handles regular filled triangle offsets, but it doesn't handle offsets for triangles drawn in point or line mode. Fixes failures found with new piglit polygon-mode-offset test. Note: This is a candidate for the stable branches. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe/build: add DLOPEN_LIBS and PTHREAD_LIBS to the lp_test_* targetsAndreas Boll2013-02-221-5/+12
| | | | | | | | | | Fixes undefined symbols. NOTE: This is a candidate for the 9.1 branch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61052 Tested-by: Vinson Lee <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: Fix rendering into PIPE_FORMAT_X8*_UNORM.Roland Scheidegger2013-02-221-15/+31
| | | | | | | | Mesa state tracker recently started using PIPE_FORMAT_X8B8G8R8_UNORM, causing segfaults in texture-packed-formats, because swizze[chan] was 0xff for padding channel (X). 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-205-49/+47
| | | | | | | | 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 lp_resource_copy using more than one 3d sliceRoland Scheidegger2013-02-201-84/+86
| | | | | | | | | | | | These used to be illegal a very long time ago, then for some more time nothing really emitted these so this code path wasn't hit. Just trivially iterate over box->depth. (Might be worth refactoring at some point since nowadays all the code doesn't really do much except for depth textures.) This fixes https://bugs.freedesktop.org/show_bug.cgi?id=61093 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
* gallivm: fix issues with trunc/round/floor/ceil with no arch roundingRoland Scheidegger2013-02-161-0/+12
| | | | | | | | | | | | | | | | | | | | The emulation of these if there's no rounding instruction available is a bit more complicated than what the code did. In particular, doing fp-to-int/int-to-fp will not work if the exponent is large enough (and with NaNs, Infs). Hence such values need to be filtered out and the original value returned in this case (which fortunately should always be exact). This comes at the expense of performance (if your cpu doesn't support rounding instructions). Furthermore, floor/ifloor/ceil/iceil were affected by precision issues for values near negative (for floor) or positive (for ceil) zero, fix that as well (fixing this issue might not actually be slower except for ceil/iceil if the type is not signed which is probably rare - note iceil has no callers left in any case). Also add some new rounding test values in lp_test_arit to actually test for that stuff (which previously would have failed without sse41). This fixes https://bugs.freedesktop.org/show_bug.cgi?id=59701.
* llvmpipe: implement dual source blendingRoland Scheidegger2013-02-125-93/+210
| | | | | | | | | | | | | link up the fs outputs and blend inputs, and make sure the second blend source is correctly loaded and converted (which is quite complex). There's a slight refactoring of the monster generate_unswizzled_blend() function where it makes sense to factor out alpha conversion (which needs to run twice for dual source blend). This passes piglit arb_blend_func_extended tests. v2: remove new but ultimately not used function... Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: remove lp_swizzled_cbufAdhemerval Zanella2013-02-113-16/+0
| | | | | | Ununsed since 75da95c5. Reviewed-by: Adam Jackson <[email protected]>
* gallivm: fix up size queries for dx10 sviewinfo opcodeRoland Scheidegger2013-02-081-0/+2
| | | | | | | | | | | | | | | Need to calculate the number of mip levels (if it would be worthwile could store it in dynamic state). While here, the query code also used chan 2 for the lod value. This worked with mesa state tracker but it seems safer to use chan 0. Still passes piglit textureSize (with some handwaving), though the non-GL parts are (largely) untested. v2: clarify and expect the sviewinfo opcode to return ints, not floats, just like the OpenGL textureSize (dx10 supports dst modifiers with resinfo). Also simplify some code. Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: first steps of adding dual source blend supportRoland Scheidegger2013-02-084-27/+57
| | | | | | | | | | | This adds support of the additional blending factors to the blend function itself, and also enables testing of it in lp_test_blend (which passes). Still need to add the glue code of linking fs shader outputs to blend inputs in llvmpipe, and probably need to add special handling if destination doesn't include alpha (which lp_test_blend doesn't test). Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: refactoring of visibility counter handlingRoland Scheidegger2013-02-085-20/+56
| | | | | | | | | There can be other per-thread data than just vis_counter, so pass a struct around instead (some of our non-public code uses this already and this difference is a major cause of merge pain). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* llvmpipe: remove extraneous const qualifierBrian Paul2013-02-062-2/+2
|
* gallium: handle unhandled PIPE_CAP_TEXTURE_BUFFER_OFFSET_ALIGNMENTAndreas Boll2013-02-041-0/+1
| | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60098 Signed-off-by: Brian Paul <[email protected]>
* llvmpipe: Don't advertise S8_UNORM (with feeble attempt at supporting it).José Fonseca2013-01-292-36/+46
| | | | | | | | | | | | | | S8_UNORM was inadvertedly supported together with Z16_UNORM. I tried to update the code to accomodate stencil-only -- it seemed a simple thing to do -- but "fbo-stencil clear GL_STENCIL_INDEX8" still fails, and it's not worth debugging. Therefore although this change tries to update for S8_UNORM, it also disables it completely. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: Fix deferred depth writes for Z16_UNORM.José Fonseca2013-01-291-1/+6
| | | | | | | | | | This special path hadn't been exercised by my earlier testing, and mask values weren't being properly truncated to match the values. This change fixes that. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: Support Z16_UNORM as depth-stencil format.José Fonseca2013-01-294-22/+43
| | | | | | | | | | Simply by adjusting the vector element width after/before reading/writing the depth-stencil values. Ran several GL_DEPTH_COMPONENT16 piglit tests without regressions. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm,draw,llvmpipe: mass rename of unit->texture_unit/sampler_unitRoland Scheidegger2013-01-281-16/+16
| | | | | | | | | | | Make it obvious what "unit" this is (no change in functionality). draw still uses "unit" in places where it changes the shader by adding texture sampling itself - it seems like this can't work with shaders using dx10-style sample opcodes (can't mix gl-style and dx10-style sample instructions in a shader). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: split sampler and texture stateRoland Scheidegger2013-01-289-84/+225
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Split the sampler interface to use separate sampler and texture (sampler_view) state. This is needed to support dx10-style sampling instructions. This is not quite complete since both draw/llvmpipe don't really track textures/samplers independently yet, as well as the gallivm code not quite using the right sampler or texture index respectively (but it should work for the sampling codes used by opengl). We are however losing some optimizations in the process, apply_max_lod will no longer work, and we potentially could end up with more (unnecessary) recompiles (if switching textures with/without mipmaps only so it shouldn't be too bad). v2: don't use different callback structs for sampler/sampler view functions (which just complicates things), fix up sampling code to actually use the right texture or sampler index, and similar for llvmpipe/draw actually distinguish between samplers and sampler views. v3: fix more of PIPE_MAX_SAMPLER / PIPE_MAX_SHADER_SAMPLER_VIEWS mismatches (both in draw and llvmpipe), based on feedback from José get rid of unneeded static sampler derived state.(which also fixes the only 2 piglit regressions due to a forgotten assignment), fix comments based on Brian's feedback. v4: remove some accidental unrelated whitespace changes Reviewed-by: José Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: turn on integer texture supportRoland Scheidegger2013-01-181-6/+16
| | | | | | | | | | Now that things mostly seem to work enable those formats. Some formats cause crashes (notably RGB8 variants) so switch these off (these crashes are not specific to INT/UINT variants but the state tracker doesn't use them for UNORM etc. formats so it went unnoticed so far). Reviewed-by: Brian Paul <[email protected]> Reviewed-by: José Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 06:38:35 +0000