summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* auxiliary/os,auxiliary/util: Fix the `‘noreturn’ function does return` ↵José Fonseca2014-04-172-5/+2
| | | | | | | | | | | | | | | | warning. Now that _debug_assert_fail() has the noreturn attribute, it is better that execution truly never returns. Not just for sake of silencing the warning, but because the code at the return IP address may be invalid or lead to inconsistent results. This removes support for the GALLIUM_ABORT_ON_ASSERT debugging environment variable, but between the usefulness of GALLIUM_ABORT_ON_ASSERT and better static code analysis I think better static code analysis wins. Reviewed-by: Brian Paul <[email protected]>
* gallium glsl: Fix crash with piglit ↵Maarten Lankhorst2014-04-171-1/+4
| | | | | | | | | | | | | | fs-deref-literal-array-of-structs.shader_test This allows the following shader code to work without a weird crash: struct Foo { int value[1]; }; int actual_value = Foo[2](Foo(int[1](100)), Foo(int[1](200)))[i].value[0]; Signed-off-by: Maarten Lankhorst <[email protected]>
* nouveau/vdec: small fixes to h264 handlingMaarten Lankhorst2014-04-174-24/+24
| | | | | | | | | | | nouveau_vp3_inter_sizes requires sliec_count as argument just as the other places that call it from h264 code do. Hopefully fixes something. Fix the status_vp code to allow status == 0 too, when processing hasn't started yet. set h264->second_field correctly.
* st/xa: Cache render target surfaceThomas Hellstrom2014-04-171-3/+15
| | | | | | | | | | | | | | | | Otherwise it will trick the gallium driver into thinking that the render target has actually changed (due to different pipe_surface pointing to same underlying pipe_resource). This is really badness for tiling GPUs like adreno. This also appears to fix a rendering error with Motif on vmwgfx. Why that is is still under investigation. Based on an idea by Rob Clark. Cc: "10.0 10.1" <[email protected]> Signed-off-by: Thomas Hellstrom <[email protected]> Reviewed-by: Rob Clark <[email protected]>
* st/xa: scissor to help tilersRob Clark2014-04-174-0/+48
| | | | | | | | | | | | | | Keep track of the maximal bounds of all the operations and set scissor accordingly. For tiling GPU's this can be a big win by reducing the memory bandwidth spent moving pixels from system memory to tile buffer and back. You could imagine being more sophisticated and splitting up disjoint operations. But this simplistic approach is good enough for the common cases. Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]>
* st/xa: remove unneeded argsRob Clark2014-04-175-12/+8
| | | | | Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Thomas Hellstrom <[email protected]>
* glsl: Small optimization for constant conditionalsIago Toral Quiroga2014-04-161-8/+2
| | | | | | | | Once the relevant branch has been identified do not iterate over the instructions in the branch, do a linked list insertion instead to avoid the loop. Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Fix incorrect indentation.Iago Toral Quiroga2014-04-161-793/+782
| | | | Acked-by: Kenneth Graunke <[email protected]>
* meta: Clip src/dest rects in BlitFramebuffer, using the scissorChris Forbes2014-04-172-2/+43
| | | | | | | | | | | | | | | | | Fixes piglit's fbo-blit-stretch test on drivers which use the meta path. (i965: should fix Broadwell, but also fixes Sandybridge/Ivybridge/Haswell since this test falls off the blorp path now due to format conversion) V2: Use scissor instead of just mangling the rects, to avoid texcoord rounding problems. (Thanks Marek) V3: Rebase on Eric's CTSI meta changes; re-add _mesa_update_state in the CTSI path so that _mesa_clip_blit sees the correct bounds. Signed-off-by: Chris Forbes <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77414 Reviewed-by: Anuj Phogat <[email protected]> Tested-by: Anuj Phogat <[email protected]>
* mesa: fix check for dummy renderbuffer in _mesa_FramebufferRenderbufferEXT()Samuel Iglesias Gonsalvez2014-04-161-2/+1
| | | | | | | | | | | | | | | | | | | | According to the spec: <renderbuffertarget> must be RENDERBUFFER and <renderbuffer> should be set to the name of the renderbuffer object to be attached to the framebuffer. <renderbuffer> must be either zero or the name of an existing renderbuffer object of type <renderbuffertarget>, otherwise an INVALID_OPERATION error is generated. This patch changes the previous returned GL_INVALID_VALUE to GL_INVALID_OPERATION. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76894 Cc: [email protected] Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]>
* i965: Don't make instructions with a null dest a barrier to scheduling.Matt Turner2014-04-161-4/+8
| | | | | | | | | | | | | | | | Now that we properly track accumulator dependencies, the scheduler is able to schedule instructions between the mach and mov in the common the integer multiplication pattern: mul acc0, x, y mach null, x, y mov dest, acc0 Since a null destination implies no dependency on the destination, we can also safely schedule instructions (that don't write the accumulator) between the mul and mach. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Change fs_visitor::emit_lrp to use MAC for gen<6Juha-Pekka Heikkila2014-04-161-7/+4
| | | | | | | | | This allows us to emit ADD/MUL/MAC instead of MUL/ADD/MUL/ADD, saving one instruction and two temporary registers. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Juha-Pekka Heikkila <[email protected]>
* i965/fs: Add support for the MAC instruction.Juha-Pekka Heikkila2014-04-162-0/+4
| | | | | | | | | | This allows us to generate the MAC (multiply-accumulate) instruction, which can be used to implement some expressions in fewer instructions than doing a series of MUL and ADDs. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Juha-Pekka Heikkila <[email protected]>
* i965/vec4: Change vec4_visitor::emit_lrp to use MAC for gen<6Juha-Pekka Heikkila2014-04-161-16/+6
| | | | | | | | | This allows us to emit ADD/MUL/MAC instead of MUL/ADD/MUL/ADD, saving one instruction and two temporary registers. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Juha-Pekka Heikkila <[email protected]>
* i965/vec4: Add support for the MAC instruction.Juha-Pekka Heikkila2014-04-163-0/+5
| | | | | | | | | | This allows us to generate the MAC (multiply-accumulate) instruction, which can be used to implement some expressions in fewer instructions than doing a series of MUL and ADDs. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Juha-Pekka Heikkila <[email protected]>
* i965: Add writes_accumulator flagJuha-Pekka Heikkila2014-04-168-35/+131
| | | | | | | | | | | | | | | | | | | | | | | Our hardware has an "accumulator" register, which can be used to store intermediate results across multiple instructions. Many instructions can implicitly write a value to the accumulator in addition to their normal destination register. This is enabled by the "AccWrEn" flag. This patch introduces a new flag, inst->writes_accumulator, which allows us to express the AccWrEn notion in the IR. It also creates a n ALU2_ACC macro to easily define emitters for instructions that implicitly write the accumulator. Previously, we only supported implicit accumulator writes from the ADDC, SUBB, and MACH instructions. We always enabled them on those instructions, and left them disabled for other instructions. To take advantage of the MAC (multiply-accumulate) instruction, we need to be able to set AccWrEn on other types of instructions. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Juha-Pekka Heikkila <[email protected]>
* i965: Add is_accumulator() function.Juha-Pekka Heikkila2014-04-164-0/+28
| | | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Juha-Pekka Heikkila <[email protected]>
* i965: Add reads_accumulator_implicitly() function.Matt Turner2014-04-162-0/+14
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Add error condition for integer formats in glGetTexImage()Anuj Phogat2014-04-161-0/+5
| | | | | | | | | | | | | | OpenGL 4.0 spec, page 306 suggests an INVALID_OPERATION in glGetTexImage if : "format is one of the integer formats in table 3.3 and the internal format of the texture image is not integer, or format is not one of the integer formats in table 3.3 and the internal format is integer." V2: Use helper function _mesa_is_format_integer() Cc: <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Add helper function _mesa_is_format_integer()Anuj Phogat2014-04-162-0/+12
| | | | | | | | This function will be used in the following patch. Cc: <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Fix glGetVertexAttribi(GL_VERTEX_ATTRIB_ARRAY_SIZE)Anuj Phogat2014-04-161-1/+1
| | | | | | | | | | | | | | | mesa currently returns 4 when GL_VERTEX_ATTRIB_ARRAY_SIZE is queried for a vertex array initially set up with size=GL_BGRA. This patch makes changes to return size=GL_BGRA as required by the spec. Fixes Khronos OpenGL CTS test: vertex_array_bgra_basic.test V2: Use array->Format instead of adding a new variable Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Cc: <[email protected]>
* glsl: Fix copy-paste error in linker_warning()Anuj Phogat2014-04-161-1/+1
| | | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* r600g: Disable LLVM by default at runtime for graphicsMichel Dänzer2014-04-173-5/+5
| | | | | | | | | | | | | | | | | For graphics, the LLVM compiler backend currently has many shortcomings compared to the non-LLVM one. E.g. it can't handle geometry shaders yet, but that's just the tip of the iceberg. So building Mesa with --enable-r600-llvm-compiler is currently not recommended for anyone who doesn't want to work on fixing those issues. However, for protection of users who end up enabling it anyway for some reason, let's disable the LLVM backend at runtime by default. It can be enabled with the environment variable R600_DEBUG=llvm. Cc: "10.1" <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* gallivm: fix compilation with llvm 3.5 r206241+Roland Scheidegger2014-04-161-11/+20
| | | | | | | Just adjust to the ever-changing API, pass in MCContext when creating the MCDisassembler. Reviewed-by: Tom Stellard <[email protected]>
* r600g,radeonsi: share some of gfx flush codeMarek Olšák2014-04-164-82/+55
| | | | Reviewed-by: Christian König <[email protected]>
* r600g,radeonsi: share r600_flush_from_stMarek Olšák2014-04-163-34/+17
| | | | Reviewed-by: Christian König <[email protected]>
* r600g: merge r600_flush with r600_context_flushMarek Olšák2014-04-163-45/+33
| | | | Reviewed-by: Christian König <[email protected]>
* radeonsi: merge si_flush with si_context_flushMarek Olšák2014-04-164-38/+33
| | | | | | This also removes si_flush_gfx_ring. Reviewed-by: Christian König <[email protected]>
* gallium/radeon: create and return a fence in the flush functionMarek Olšák2014-04-1620-85/+99
| | | | | | All flush functions get a fence parameter. cs_create_fence is removed. Reviewed-by: Christian König <[email protected]>
* r600g: remove redundant r600_flush_dma_from_winsysMarek Olšák2014-04-161-8/+1
| | | | Reviewed-by: Christian König <[email protected]>
* winsys/radeon: fold cs_set_flush_callback into cs_createMarek Olšák2014-04-168-42/+26
| | | | Reviewed-by: Christian König <[email protected]>
* radeonsi: cleanup redundant computation of flush flags and rename a functionMarek Olšák2014-04-161-8/+9
| | | | Reviewed-by: Christian König <[email protected]>
* r600g: remove redundant r600_flush_from_winsysMarek Olšák2014-04-161-8/+1
| | | | Reviewed-by: Christian König <[email protected]>
* winsys/radeon: remove cs_write_reloc, add simpler cs_get_relocMarek Olšák2014-04-164-29/+23
| | | | | | | The only difference is that it doesn't write to the CS and only returns the index. Reviewed-by: Christian König <[email protected]>
* winsys/radeon: consolidate hash table lookupMarek Olšák2014-04-162-68/+49
| | | | | | I should have done this long ago. Reviewed-by: Christian König <[email protected]>
* util/u_debug: Add noreturn attribute to _debug_assert_fail().José Fonseca2014-04-161-1/+5
| | | | | | | As recommended by http://clang-analyzer.llvm.org/annotations.html#attr_noreturn Reviewed-by: Brian Paul <[email protected]>
* glsl: Properly handle blocks that define the same field name.Iago Toral Quiroga2014-04-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Currently we can have name space collisions between blocks that define the same fields. For example: in block { vec4 Color; } In[]; out block { vec4 Color; } Out; These two blocks will assign the same interface name (block.Color) to the Color field in flatten_named_interface_blocks_declarations.cpp, leading to havoc. This was breaking badly the gl-320-primitive-shading test from ogl-samples. The patch uses the block instance name to avoid collisions, producing names like block.In.Color and block.Out.Color to avoid the name clash. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76394 Reviewed-by: Kenneth Graunke <[email protected]>
* r600g/radeonsi: Map transfer staging texture unsynchronized when possibleMichel Dänzer2014-04-161-0/+2
| | | | | | | | | The transfer staging texture is always freshly allocated, so for write-only transfers we don't need to explicitly wait for the BO to become idle. Squeezes a few hundered MB/s more out of x11perf -shmput500 with glamor. Reviewed-by: Marek Olšák <[email protected]>
* Revert "i965/fs: Only sweep NOPs if register coalescing made progress."Matt Turner2014-04-151-8/+7
| | | | | | This reverts commit f092e8951ce5212ba3cbb382ce3a6666eb6c9bed. Didn't mean to push this...
* i965/fs: Only sweep NOPs if register coalescing made progress.Matt Turner2014-04-151-7/+8
| | | | Otherwise there's nothing to do.
* i965: Fix buffer overruns in MSAA MCS buffer clearing.Eric Anholt2014-04-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This manifested as rendering failures or sometimes GPU hangs in compositors when they accidentally got MSAA visuals due to a bug in the X Server. Today we decided that the problem in compositors was equivalent to a corruption bug we'd noticed recently in resizing MSAA-visual glxgears, and debugging got a lot easier. When we allocate our MCS MT, libdrm takes the size we request, aligns it to Y tile size (blowing it up from 300x300=900000 bytes to 384*320=122880 bytes, 30 pages), then puts it into a power-of-two-sized BO (131072 bytes, 32 pages). Because it's Y tiled, we attach a 384-byte-stride fence to it. When we memset by the BO size in Mesa, between bytes 122880 and 131072 the data gets stored to the first 20 or so scanlines of each of the 3 tiled pages in that row, even though only 2 of those pages were allocated by libdrm. In the glxgears case, the missing 3rd page happened to consistently be the static VBO that got mapped right after the first MCS allocation, so corruption only appeared once window resize made us throw out the old MCS and then allocate the same BO to back the new MCS. Instead, just memset the amount of data we actually asked libdrm to allocate for, which will be smaller (more efficient) and not overrun. Thanks go to Kenneth for doing most of the hard debugging to eliminate a lot of the search space for the bug. Cc: "10.0 10.1" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77207 Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Add support for MSAA resolves from 2D_MS_ARRAY textures.Eric Anholt2014-04-152-17/+49
| | | | | | | | | We don't have any piglit tests for this currently. v2: Use vec3s for the texcoords so it has some hope of working. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Add an accelerated glCopyTexSubImage using glBlitFramebuffer.Eric Anholt2014-04-154-12/+94
| | | | | | | | | | | | | | | You'll note from the previous commits that there's something of a loop here: You call CTSI, which calls BlitFB, then if things go wrong that falls back to CTSI. As a result, meta CTSI reaches over into blitfb to tell it "no, don't try that fallback". v2: Drop the _mesa_update_state(), which was only necessary due to use of _mesa_clip_blit() in _mesa_meta_BlitFramebuffer() in another patch series. v3: Drop an _EXT suffix I copy-and-pasted. Reviewed-by: Ian Romanick <[email protected]> (v2) Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Add support for CUBE_MAP_ARRAY to generatemipmap.Eric Anholt2014-04-152-1/+5
| | | | | | | | | | I added support to bind_fbo_image in the process of building meta CopyTexSubImage, and found that it broke generatemipmap because previously we would just throw a GL error there and then end up with an incomplete FBO and fallback. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Infer bind_fbo_image parameters from an incoming image.Eric Anholt2014-04-153-6/+13
| | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Move bind_fbo_image() code back to meta.c, to reuse it elsewhere.Eric Anholt2014-04-153-34/+36
| | | | | | | | | I need to do the same code again for CopyTexSubImage(). v2: Drop incorrect, not-terribly-useful comment (review by Ken) Reviewed-by: Ian Romanick <[email protected]> (v1) Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Refactor the BlitFramebuffer depth CopyTexImage fallback.Eric Anholt2014-04-152-138/+2
| | | | | | | | | This avoids a ReadPixels() if there's accelerated CopyTexImage present. It now requires GLSL as opposed to just fragment programs, but we don't have any drivers that do ARB_fp but not GLSL. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* meta: Refactor the BlitFramebuffer color CopyTexImage fallback.Eric Anholt2014-04-151-52/+41
| | | | | | | | | | | | | | | | | | | There shouldn't be anything special about copying out a subset of the src rb to a temp before texturing from it, so just do it when we're figuring out our src texture binding. This drops Anuj's change to copy an extra border of 1 pixel around the src area. I can't see how that change could be valid, and presumably if there's some filtering problem at edges we just need to set the right wrap mode. v2: Don't fall back to swrast on non-2D/RECT/2D_MS textures when we can still CopyTexSubImage. Fixes a segfault regression on i965 with gl-3.2-layered-rendering-blit. Reviewed-by: Ian Romanick <[email protected]> (v1) Reviewed-by: Kenneth Graunke <[email protected]> (v1) Tested-by: Anuj Phogat <[email protected]>
* meta: Drop blit src size fallback.Eric Anholt2014-04-151-10/+0
| | | | | | | | | | | | | I think we can assert that renderbuffer size is <= maximum 2D texture size. Our source coordinates should have already been clipped to the src renderbuffer size, but haven't actually (so we could potentially have trouble if there's scaling, and we're in the CopyTexImage path that tries to use src size). However, this texture size dependency was blocking the next refactors, so I'm not sure if we want to go ahead with this series before we get the clipping sorted out or not. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Avoid dependency hints on math opcodesMike Stroyan2014-04-151-0/+8
| | | | | | | | | | | Putting NoDDClr and NoDDChk dependency control on instruction sequences that include math opcodes can cause corruption of channels. Treat math opcodes like send opcodes and suppress dependency hinting. Signed-off-by: Mike Stroyan <[email protected]> Tested-by: Tony Bertapelli <[email protected]> Cc: [email protected] Reviewed-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 02:24:15 +0000