summaryrefslogtreecommitdiffstats
path: root/src/gallium/drivers
Commit message (Collapse)AuthorAgeFilesLines
* svga: remove support for shader model 2.0Brian Paul2011-10-119-374/+25
| | | | | | We've been requiring SM 3.0 all along so this just removes unused code. Reviewed-by: Jose Fonseca <[email protected]>
* softpipe: add integer supportDave Airlie2011-10-115-44/+146
| | | | | | | This adds support to the clear and tile caches for integer storage and clearing, avoiding any floating paths. Signed-off-by: Dave Airlie <[email protected]>
* gallium: rename ZS stencil type to UINT (v2)Dave Airlie2011-10-1134-108/+108
| | | | | | | | | | these are never USCALED, always UINT in reality. taken from some work by Christoph Bumiller v2: fixup formatting of table + tabs Signed-off-by: Dave Airlie <[email protected]>
* llvmpipe: don't support rendering to sRGB surfacesBrian Paul2011-10-111-1/+2
| | | | Fixes https://bugs.freedesktop.org/show_bug.cgi?id=34199
* i915g: fix warning about void pointer arithmeticBrian Paul2011-10-111-1/+1
|
* i915g: Remove duplicated comment.Stéphane Marchesin2011-10-101-1/+0
|
* i915g: Update TODO once more.Stéphane Marchesin2011-10-101-4/+1
|
* r600g: drop force int type workaroundDave Airlie2011-10-104-28/+5
| | | | | | | now that we have integer texture types I can drop this workaround so that copies of values is done properly (as floats would fail on some corner cases). Signed-off-by: Dave Airlie <[email protected]>
* r600g: add integer texture/render integer formats for r600/700.Dave Airlie2011-10-101-2/+60
| | | | | | with these I can drop the force int type hack. Signed-off-by: Dave Airlie <[email protected]>
* i915g: Update the TODO with another idea.Stéphane Marchesin2011-10-101-0/+2
|
* i915g: Enable instanced drawing.Stéphane Marchesin2011-10-101-1/+1
|
* r600g: uarl fixes.Dave Airlie2011-10-092-18/+43
| | | | Not 100% sure these are correct yet
* r600g: enable integer shader cap for evergreen.Dave Airlie2011-10-091-0/+3
| | | | | | | Will get to adding r600/r700/cayman support, have it mostly written on another PC. Signed-off-by: Dave Airlie <[email protected]>
* nouveau: hide some debugging messages behind environment variableMarcin Slusarz2011-10-095-5/+17
| | | | | They spam console, but are not very useful - hide them behind NOUVEAU_MESA_DEBUG environment variable.
* nv50,nvc0: avoid unnecessary flushesMarcin Slusarz2011-10-094-4/+4
| | | | | Relocations don't consume pushbuffer space, so there is no need to ensure there is any space in pushbuffer.
* nouveau: fix fence hangMarcin Slusarz2011-10-095-14/+28
| | | | | | | | | | | | | | | | | | | | | If there is not enough space in pushbuffer for fence emission (nouveau_fence_emit -> nv50_screen_fence_emit -> MARK_RING), the pushbuffer is flushed, which through flush_notify -> nv50_default_flush_notify -> nouveau_fence_update marks currently emitting fence as flushed. But actual emission is done after this mark. So later when there is a need to wait on this fence and pushbuffer was not flushed in between, fence wait will never finish causing application to hang. To fix this, introduce new fence state between AVAILABLE and EMITTED, set it before emission and handle it everywhere. Additionally obtain fence sequence numbers after possible flush in MARK_RING, because we want to emit fences in correct order. Reviewed-by: Christoph Bumiller <[email protected]> Note: This is a candidate for the 7.11 branch.
* r600g/eg: add integer types supportDave Airlie2011-10-093-10/+66
| | | | | | | | adds handling for int texture/vertices to evergreen. TODO r600/700 support. Signed-off-by: Dave Airlie <[email protected]>
* u_blitter: add integer clear supportDave Airlie2011-10-092-4/+5
| | | | | | | | | | | We need add a new set of fragment shader variants, along with new vertex elements for signed and unsigned clears. The new fragment shader variants are due to the integers values requiring CONSTANT interpolation. The new vertex element descriptions are for passing the clear color as an unsigned or signed integer value. Signed-off-by: Dave Airlie <[email protected]>
* i915g: Remove another TODO item which was done a while ago.Stéphane Marchesin2011-10-081-3/+0
|
* i915g: Remove a TODO item.Stéphane Marchesin2011-10-081-1/+0
|
* i915g: Fix comment.Stéphane Marchesin2011-10-081-1/+1
|
* i915g: Implement vertex textures.Stéphane Marchesin2011-10-084-62/+230
|
* i915g: Silence warning.Stéphane Marchesin2011-10-081-1/+1
|
* i915g: Remove old heuristic flusing remains.Stéphane Marchesin2011-10-081-20/+0
|
* i915g: Cleanup caps code a bit.Stéphane Marchesin2011-10-081-7/+6
|
* gallium: add initial pure integer support (v2)Dave Airlie2011-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This add support for unsigned/signed integer types via adding a 'pure' bit in the format description table. It adds 4 new u_format get/put hooks, for get/put uint and get/put sint so that accessors can get native access to the integer bits. This is used to avoid precision loss via float converting paths. It doesn't add any float fetchers for these types at the moment, GL doesn't require float fetching from these types and I expect we'll introduce a lot of hidden bugs if we start allowing such conversions without an API mandating it. It adds all formats from EXT_texture_integer and EXT_texture_rg. 0 regressions on llvmpipe here with this. (there is some more follow on code in my gallium-int-work branch, bringing softpipe and mesa to a pretty integer clean state) v2: fixup python generator to get signed->unsigned and unsigned->signed fetches working. Signed-off-by: Dave Airlie <[email protected]>
* r300g: remove unused r300_resource::tex_offsetMarek Olšák2011-10-085-16/+6
|
* r300g: disable stream output on SWTCL chipsetsMarek Olšák2011-10-081-1/+1
| | | | Unimplemented and not so useful for this driver.
* i915g: Add two new unsupported PIPE_CAPs.Stéphane Marchesin2011-10-071-0/+2
|
* i915g: handle seperate stencil clearDaniel Vetter2011-10-071-0/+10
| | | | Signed-off-by: Daniel Vetter <[email protected]>
* i915g: actually try to clear 16bit depth bufsDaniel Vetter2011-10-071-1/+1
| | | | | | ... with the right value. Signed-off-by: Daniel Vetter <[email protected]>
* i915g: hw can't fastclear both depth and color when bbp doesn't matchDaniel Vetter2011-10-071-29/+93
| | | | | | | | Do it in two passes in that case. v2: Don't forget to handle stencil clears. Signed-off-by: Daniel Vetter <[email protected]>
* i915g: disable scissor in fast clearDaniel Vetter2011-10-071-4/+6
| | | | | | Docs say this is obeyed. Signed-off-by: Daniel Vetter <[email protected]>
* i915g: add some obscure sampler formatsDaniel Vetter2011-10-071-1/+3
| | | | | | 4bit palette ftw! Signed-off-by: Daniel Vetter <[email protected]>
* i915g: fixup clear params emissionDaniel Vetter2011-10-071-1/+8
| | | | | | | | | | | | | | | | | Docs say that default shader input color input need to be spec as ARGB8888. And a clear rect prim essentially uses this value instead of default diffuse. Depth on the other hands is an ieee 32 bit float. Clear stencil is U8. Completely different are the clear values for zone init prims. These are speced in the actual output pixel layout (and need to be repeated for 16 bit formats). Clear up the confusion by adding some comments. v2: Retain the target swizzling support added by Stephan Marchesin. Signed-off-by: Daniel Vetter <[email protected]>
* i915g: make fixup swizzle into a real hw stateDaniel Vetter2011-10-073-41/+45
| | | | | | This way it can be reused in the fastclear path. Signed-off-by: Daniel Vetter <[email protected]>
* i915g: Announce GL 2.0.Stéphane Marchesin2011-10-061-1/+1
| | | | We leave the debug code in place to troubleshoot issues while we complete the transition. That code might be removed after that.
* i915g: Silence warning.Stéphane Marchesin2011-10-061-1/+1
| | | | We still need to investigate LIS7 though.
* i915g: Fix comment.Stéphane Marchesin2011-10-051-1/+1
|
* llvmpipe: Fix the 4 planes (lines) case properly.José Fonseca2011-10-052-16/+33
| | | | | | | | 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: Ensure the 16x16 special rasterization path does not touch outside ↵José Fonseca2011-10-054-5/+31
| | | | | | | | | | | | | | the tile. llvmpipe has a few special rasterization paths for triangles contained in 16x16 blocks, but it allows the 16x16 block to be aligned only to a 4x4 grid. Some 16x16 blocks could actually intersect the tile if the triangle is 16 pixels in one dimension but 4 in the other, causing a buffer overflow. The fix consists of budging the 16x16 blocks back inside the tile.
* softpipe: fix Z interpolation invariance bugBrian Paul2011-10-041-1/+10
| | | | | | | | | We want quad/pixel Z values to be interpolated exactly the same for multi-pass algorithms. Because of how the optimized Z-test code is written, we can't cull the first quad in a run even if it's totally killed. See the comment for more info. NOTE: This is a candidate for the 7.11 branch.
* softpipe: add check for DO_PSTIPPLE_IN_HELPER_MODULEBrian Paul2011-10-041-0/+2
| | | | | We only want to generate the fragment shader variant that does stippling if DO_PSTIPPLE_IN_HELPER_MODULE is being used.
* r300g: fix rendering with a non-zero index bias in draw_elements_immediateMarek Olšák2011-10-041-1/+3
| | | | NOTE: This is a candidate for the stable branches.
* r600g: fix parsing TGSI declarationsMarek Olšák2011-10-041-2/+2
| | | | It was a lucky coincidence that it worked.
* r300/compiler: Fix error in OMOD optimizationTom Stellard2011-10-021-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | Classic compiler mistake. In the example below, the OMOD optimization was combining instructions 4 and 10, but since there was an instruction (#8) in between them that wrote to the same registers as instruction 10, instruction 11 was reading the wrong value. Example of the mistake: Before OMOD: 4: MAD temp[0].y, temp[3]._y__, const[0]._x__, const[0]._y__; ... 8: ADD temp[2].x, temp[1].x___, -temp[4].x___; ... 10: MUL temp[2].x, const[1].y___, temp[0].y___; 11: FRC temp[5].x, temp[2].x___; After OMOD: 4: MAD temp[2].x / 8, temp[3]._y__, const[0]._x__, const[0]._y__; ... 8: ADD temp[2].x, temp[1].x___, -temp[4].x___; ... 11: FRC temp[5].x, temp[2].x___; https://bugs.freedesktop.org/show_bug.cgi?id=41367
* r300/compiler: Rewrite source swizzles when using OMODTom Stellard2011-10-021-1/+6
|
* r300/compiler: Fix rc_normal_rewrite_writemask()Tom Stellard2011-10-021-5/+4
| | | | This function had not been updated to use conversion swizzles.
* r300/compiler: Use consistent src swizzles for transcendent instructionsTom Stellard2011-10-025-6/+33
| | | | | | | | | | | | | | | Source swizzles for transcendent instructions were being stored in the X channel regardless of what channel the instruction was writing. This was causing problems for some helper functions that were expecting source swizzles to occupy channels corresponding to the instruction's writemask. This commit makes transcendent instructions follow the same convention as normal instructions for representing source swizzles. Previous behavior: LG2 temp[0].y, input[0].x___; Current behavior: LG2 temp[0].y, input[0]._x__;
* r600g: fix a compiler warningMarek Olšák2011-09-301-0/+1
|
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-28 00:08:56 +0000