summaryrefslogtreecommitdiffstats
path: root/src/gallium
Commit message (Collapse)AuthorAgeFilesLines
* ilo: re-emit states that involve resourcesChia-I Wu2013-06-134-21/+23
| | | | | | | Even with hardware contexts, since we do not pin resources, we have to re-emit the states so that the resources are referenced (by cp->bo) and their offsets are updated in case they are moved. This also allows us to elimiate cp flush in is_bo_busy().
* ilo: fix for util_blitter_clear() changesChia-I Wu2013-06-131-4/+1
| | | | It has been broken since 17350ea979b883662573dac136cd9efb49938210.
* mesa: Fix bug in unclamped float to ubyte conversion.Manfred Ernst2013-06-121-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: The IEEE float optimized version of UNCLAMPED_FLOAT_TO_UBYTE in macros.h computed incorrect results for inputs in the range 0x3f7f0000 (=0.99609375) to 0x3f7f7f80 (=0.99803924560546875) inclusive. 0x3f7f7f80 is the IEEE float value that results in 254.5 when multiplied by 255. With rounding mode "round to closest even integer", this is the largest float in the range 0.0-1.0 that is converted to 254 by the generic implementation of UNCLAMPED_FLOAT_TO_UBYTE. The IEEE float optimized version incorrectly defined the cut-off for mapping to 255 as 0x3f7f0000 (=255.0/256.0). The same bug was present in the function float_to_ubyte in u_math.h. Fix: The proposed fix replaces the incorrect cut-off value by 0x3f800000, which is the IEEE float representation of 1.0f. 0x3f7f7f81 (or any value in between) would also work, but 1.0f is probably cleaner. The patch does not regress piglit on llvmpipe and on i965 on sandy bridge. Tested-by Stéphane Marchesin <[email protected]> Reviewed-by Stéphane Marchesin <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* st/dri: if flushing a drawable, don't set reason=SWAPBUFFERSMarek Olšák2013-06-131-1/+1
| | | | | | 0 means SWAPBUFFERS. Reviewed-by: Brian Paul <[email protected]>
* st/dri: resolve the back buffer only in SwapBuffersMarek Olšák2013-06-131-3/+3
| | | | Reviewed-by: Brian Paul <[email protected]>
* st/dri: manually swap MSAA front and back buffers in SwapBuffersMarek Olšák2013-06-131-0/+25
| | | | Reviewed-by: Brian Paul <[email protected]>
* st/dri: always copy new DRI front and back buffers to corresponding MSAA buffersMarek Olšák2013-06-131-0/+27
| | | | | | | | This commit fixes these piglit tests with an MSAA visual forced on: - read-front - glx-copy-sub-buffer Reviewed-by: Brian Paul <[email protected]>
* st/dri: refactor dri_msaa_resolveMarek Olšák2013-06-133-12/+15
| | | | | | The generic blit will be used by the following commit. Reviewed-by: Brian Paul <[email protected]>
* st/dri: reuse depth-stencil and MSAA resources after DRI2 invalidate eventMarek Olšák2013-06-131-26/+78
| | | | | | | | | | Page flipping generates an invalidate event every frame, causing reallocations of all private resources (MSAA and depth-stencil). Reusing the resources may improve performance (especially under memory pressure). Reviewed-by: Brian Paul <[email protected]>
* st/dri: fix MSAA resolving of buffers with height > widthMarek Olšák2013-06-131-2/+2
| | | | Reviewed-by: Brian Paul <[email protected]>
* r600g: upsample and downsample MSAA resources for transfersMarek Olšák2013-06-131-79/+141
| | | | | | | | | | | We did downsample (=resolve) MSAA resources to make ReadPixels work with MSAA GLX visuals, which was enough for read-only color-only transfers. This commit makes write color transfers and depth-stencil transfers work in a similar manner. It does downsampling in transfer_map and upsampling in transfer_unmap. Reviewed-by: Brian Paul <[email protected]>
* gallium/u_format: add a new helper for initializing pipe_blit_info::maskMarek Olšák2013-06-132-25/+29
| | | | Reviewed-by: Brian Paul <[email protected]>
* gallium/u_blitter: make clearing independent of the colorbuffer formatMarek Olšák2013-06-135-49/+7
| | | | | | | There isn't any difference between 32_FLOAT and 32_*INT in vertex fetching. Both of them don't do any format conversion. Reviewed-by: Brian Paul <[email protected]>
* gallium/u_blitter: make clearing independent of the number of bound colorbuffersMarek Olšák2013-06-137-59/+43
| | | | | | We can use the fragment shader TGSI property WRITES_ALL_CBUFS. Reviewed-by: Brian Paul <[email protected]>
* gallium/util: make WRITES_ALL_CBUFS optional in the passthrough fragment shaderMarek Olšák2013-06-135-7/+13
| | | | Reviewed-by: Brian Paul <[email protected]>
* util: new util_fill_box helperRoland Scheidegger2013-06-133-39/+62
| | | | | | | | | Use new util_fill_box helper for util_clear_render_target. (Also fix off-by-one map error.) v2: handle non-zero z correctly in new helper Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: (trivial) remove duplicated code block (including comment)Roland Scheidegger2013-06-131-7/+0
|
* winsys/intel: make struct intel_bo alias drm_intel_boChia-I Wu2013-06-121-122/+50
| | | | | | | | There is really nothing in struct intel_bo, and having it alias drm_intel_bo makes the winsys impose almost zero overhead. We can make the overhead gone completely by making the functions static inline, if needed.
* winsys/intel: reorganize functionsChia-I Wu2013-06-121-249/+249
| | | | Move functions around to match the order of the declarations in the header.
* ilo: update winsys interfaceChia-I Wu2013-06-123-63/+66
| | | | | | The motivation is to kill tiling and pitch in struct intel_bo. That requires us to make tiling and pitch not queryable, and be passed around as function parameters.
* ilo: get rid of function tables in winsysChia-I Wu2013-06-1220-656/+557
| | | | | We are moving toward making struct intel_bo alias drm_intel_bo. As a first step, we cannot have function tables.
* ilo: access bo size directlyChia-I Wu2013-06-121-2/+2
| | | | buf->bo_size is readily avaiable, no need to go via buf->bo->get_size().
* ilo: remove unnecessary tex_set_bo/buf_set_boChia-I Wu2013-06-121-42/+18
| | | | Merge the bodies to tex_create_bo/buf_create_bo respectively.
* draw: implement distance cullingZack Rusin2013-06-108-31/+198
| | | | | | | | | | | Works similarly to clip distance. If the cull distance is negative for all vertices against a specific plane then the primitive is culled. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallium: add a cull distance semanticZack Rusin2013-06-105-2/+20
| | | | | | | | | | | | | cull distance is analogous to clip distance. If a register is given this semantic, then the values in it are assumed to be a float32 distance to a plane. Primitives will be completely discarded if the plane distance for all of the vertices in the primitive are < 0. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: fix clipper invocation statisticsZack Rusin2013-06-105-6/+33
| | | | | | | | | | | | | We need to figure out the number of invocations of the clipper before the emit, because in the emit we are after clipping where the number of primitives will be equal to number of clipper invocations minus the clipped primitives. So our computations were always off by the number of clipped primitives. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: enable user plane clipping when clipdistance is usedZack Rusin2013-06-102-7/+20
| | | | | | | | | | | | | | | | | Draw depended on clip_plane_enable being set in the rasterizer to use clipdistance registers for clipping. That's really unfriendly because it requires that rasterizer state to have variants for every shader out there. Instead of depending on the rasterizer lets extract the info from the available state: if a shader writes clipdistance then we need to use it and we need to clip using a number of planes equal to the number of writen clipdistance components. This way clipdistances just work. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* draw: make sure clipdistances work with geometry shadersZack Rusin2013-06-106-2/+22
| | | | | | | | | | | we were always fetching the info from the vertex shader, but if geometry shader is present it should be used as the source of that info. Signed-off-by: Zack Rusin <[email protected]> Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* winsys/radeon: add env var to disable VM on Cayman/TrinityAlex Deucher2013-06-101-0/+2
| | | | | | | | | | | Set env var RADEON_VA=0 to disable VM on Cayman/Trinity. Useful for debugging. Note: this is a candidate for the 9.1 branch. Signed-off-by: Alex Deucher <[email protected]> Reviewed-by: Tom Stellard <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* draw: Add A8R8G8B8 to draw_print_arraysRichard Sandiford2013-06-101-0/+7
| | | | | Reviewed-by: Adam Jackson <[email protected]> Signed-off-by: Richard Sandiford <[email protected]>
* draw: Fix type mismatch between draw_private.h and LLVMRichard Sandiford2013-06-101-1/+1
| | | | | | | | | | | | | | | draw_vertex_buffer declared the size field to be a size_t, but the LLVM code used an int32 instead. This caused problems on big-endian 64-bit targets, because the first 32-bit chunk of the 64-bit size_t was always 0. In one sense size_t seems like a good choice for a size, so one fix would have been to try to get the LLVM code to use the equivalent of size_t too. However, in practice, the size is taken from things like ~0 or width0, both of which are int-sized, so it seemed simpler to make the size field int-sized as well. Reviewed-by: Adam Jackson <[email protected]> Signed-off-by: Richard Sandiford <[email protected]>
* util: Use sizeof(void *) rather than 0 as the fallback cache line sizeRichard Sandiford2013-06-101-0/+5
| | | | | | | | Without this, llvmpipe ends up giving a zero size to all uncompressed textures on non-x86 systems, since align() cannot handle a 0 alignment. Reviewed-by: Adam Jackson <[email protected]> Signed-off-by: Richard Sandiford <[email protected]>
* llvmpipe: Use saturating add/sub for UNORM formatsRichard Sandiford2013-06-101-0/+8
| | | | | | | | | | | | | | | | | | lp_build_add and lp_build_sub have fallback code for cases that cannot be handled by known intrinsics. For UNORM formats, this code was using modulo rather than saturating arithmetic. This fixes some rendering issues for a gnome session on System z. It also fixes various piglit tests on z, such as spec/ARB_color_buffer_float/GL_RGBA8-render. The patch deliberately doesn't tackle the more complicated SNORM case. Tested against piglit on x86_64 and System z with no regressions. Reviewed-by: Adam Jackson <[email protected]> Signed-off-by: Richard Sandiford <[email protected]>
* nvc0: fix up video buffer alignment requirementsMaarten Lankhorst2013-06-081-5/+3
| | | | Signed-off-by: Maarten Lankhorst <[email protected]>
* freedreno: better scissor fixRob Clark2013-06-085-28/+43
| | | | | | Actually respect rasterizer state. Signed-off-by: Rob Clark <[email protected]>
* freedreno: gmem bypassRob Clark2013-06-087-30/+168
| | | | | | | | | | | | | The GPU (at least a3xx, but I think also a2xx) can render directly to memory, bypassing tiling. Although it can't do this if blend, depth, and a few other features of the pipeline are enabled. This direct memory mode can be faster for some sorts of operations, such as simple blits. In particular, this significantly speeds up XA by avoiding to pull the entire dest pixmap into GMEM, render tiles, and write it all back out again. This should also speed up resource copy-region and blit. Signed-off-by: Rob Clark <[email protected]>
* freedreno: add a3xx supportRob Clark2013-06-0835-3/+8955
| | | | | | | | | | | | | | | | | | | | The adreno a3xx GPU is found in newer snapdragon devices, such as the nexus4. The a3xx is GLESv3 and OpenCL capable, although that is not enabled yet in gallium. Compared to a2xx, it introduces an entirely new unified shader ISA, and re-shuffles all or nearly all of the registers. The good news is that (for the most part) the registers are more orthogonal, not combining unrelated state in a single register. And that there is a lot more flexibility, so we don't need to patch and re-emit the shader like we did on a2xx. The shader compiler is currently quite dumb, there would be a lot of room for improvement with an optimizing pass. Despite that, with the a320 in my nexus4 it seems to be ~2-3x faster compared to the a220 in my HP touchpad. Signed-off-by: Rob Clark <[email protected]>
* freedreno: prepare for a3xxRob Clark2013-06-0849-2008/+2798
| | | | | | | | Split the parts that are specific to adreno a2xx series GPUs from the parts that will be in common with a3xx, so that a3xx support can be added more cleanly. Signed-off-by: Rob Clark <[email protected]>
* gallivm: work around slow code generated for interleaving 128bit vectorsRoland Scheidegger2013-06-081-0/+22
| | | | | | | | | | | | | | | We use 128bit vector interleave for untwiddling in the blend code (with 256bit vectors). llvm generates terrible code for this for some reason, so instead of generating a shuffle for 2 128bit vectors use a extract/insert shuffle instead (it only seems to matter we're not using 128bit wide vectors for the shuffle). This decreases instruction count of the blend code generated for a rgba8 render target without blending from 169 to 113 with llvm 3.1 and from 136 to 114 in llvm 3.2/3.3, and I got a ~8% (llvm 3.1) and ~5% (3.2/3.3) performance improvement in gears. (The generated code is still not terribly good as we could actually avoid the interleaving completely but llvm can't know this.) Reviewed-by: Jose Fonseca <[email protected]>
* st/xlib: Flush the front buffer before doing CopySubBufferStéphane Marchesin2013-06-071-0/+4
| | | | | | | | | We flush pending rendering before running CopySubBuffer, which ensures that the right bits get to the screen. NOTE: This is a candidate for stable release branches. Reviewed-by: Brian Paul <[email protected]>
* st/xlib: Fix upside down coordinates for CopySubBufferStéphane Marchesin2013-06-071-1/+1
| | | | | | | | The coordinates need to be inverted between glX and gallium. NOTE: This is a candidate for stable release branches. Reviewed-by: Brian Paul <[email protected]>
* util: add comment about bogus transfer flagsRoland Scheidegger2013-06-071-0/+1
|
* util: fix util_clear_render_target and util_clear_depth_stencil layer handlingRoland Scheidegger2013-06-071-87/+103
| | | | | | | These functions must clear all bound layers, not just the first. Reviewed-by: Jose Fonseca <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: move create_surface/destroy_surface functions to lp_surface.cRoland Scheidegger2013-06-072-59/+59
| | | | | | | 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-0715-110/+195
| | | | | | | | | | | | | | | | 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]>
* gallium/docs: fix up transfer description for 1d arrays, add cube map arraysRoland Scheidegger2013-06-071-5/+4
| | | | | | | | | | | Transfers always use z/depth for layers no matter if it's a 1d or 2d array texture, we don't follow OpenGL's crazyness there. Luckily this appears to only be a doc bug, everyone doing the right thing already. While here also document z/depth parameter for cube map arrays. v2: fix typo spotted by Eric Anholt Reviewed-by: Jose Fonseca <[email protected]>
* ilo: fix textureSize() for single-layered array texturesChia-I Wu2013-06-081-2/+18
| | | | | We returned 0 instead of 1 for the number of layers when the array texutre is single-layered. This fixed it on GEN7+.
* util: add util_resource_is_array_texture()Chia-I Wu2013-06-081-1/+19
| | | | | | | | Checking if array_size is greater than 1 is not enough for single-layered array textures. Signed-off-by: Chia-I Wu <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* gallium: Remove draw_arrays() and draw_arrays_instanced() functionsArnas Milasevicius2013-06-072-51/+0
| | | | | | | | Moved draw_arrays() to st_draw_feedback.c and removed draw_arrays_instanced(). draw_arrays() was used by nobody else. Now there's just one "draw" entrypoint into the draw module. Signed-off-by: Brian Paul <[email protected]>
* tgsi: replace tgsi_file_names tgsi_file_names[] with tgsi_file_name() functionBrian Paul2013-06-077-18/+30
| | | | | | | | | This change came from the discovery that the STATIC_ASSERT to check that the number of register file strings didn't actually work. Similar changes could be made for the other string arrays in tgsi_string.c Reviewed-by: Jose Fonseca <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-20 22:48:05 +0000