[Mesa-dev] [Bug 75061] bug in clearing color buffer

https://bugs.freedesktop.org/show_bug.cgi?id=75061 Michel Dänzer changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop

Re: [Mesa-dev] [PATCH 1/2] mesa: Add core API support for GL_ARB_stencil_texturing (from 4.3).

Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] i965: Implement ARB_stencil_texturing on Gen8+.

On Sun, Feb 23, 2014 at 9:59 PM, Kenneth Graunke wrote: > On earlier hardware, we had to implement math in the shader to translate > Y-tiled or untiled coordinates to W-tiled coordinates (which is what > BLORP does today in order to texture from stencil buffers). > > On Broadwell, we can simply st

[Mesa-dev] [PATCH 2/2] i965: Implement ARB_stencil_texturing on Gen8+.

On earlier hardware, we had to implement math in the shader to translate Y-tiled or untiled coordinates to W-tiled coordinates (which is what BLORP does today in order to texture from stencil buffers). On Broadwell, we can simply state that it's W-tiled in SURFACE_STATE, and adjust the pitch. Thi

[Mesa-dev] [PATCH 1/2] mesa: Add core API support for GL_ARB_stencil_texturing (from 4.3).

While the GL_ARB_stencil_texturing extension does not allow the creation of stencil textures, it does allow shaders to sample stencil values stored in packed depth/stencil textures. Specifically, applications can call glTexParameter* with a pname of GL_DEPTH_STENCIL_TEXTURE_MODE and value of eithe

Re: [Mesa-dev] [PATCH 4/4] glsl: Delete LRP_TO_ARITH lowering pass flag.

Series is Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Don't try to use the hardware blitter for multisampled miptrees.

On 02/21/2014 08:20 PM, Paul Berry wrote: > On 21 February 2014 19:15, Kenneth Graunke > wrote: > > The blitter is completely ignorant of MSAA buffer layouts, so any > attempt to use BLT paths with MSAA buffers is likely to break > spectacularly. > >

Re: [Mesa-dev] [PATCH 19/25] gallium/i915: handle query_renderer caps

On Sat, Feb 22, 2014 at 5:22 AM, Emil Velikov wrote: > On 22/02/14 03:33, Stéphane Marchesin wrote: > > On Fri, Feb 21, 2014 at 7:04 PM, Emil Velikov >wrote: > > > >> Implementation is a verbatim copy from the classic driver. > >> > >> This introduces a driver dependency on libdrm-intel, as the w

[Mesa-dev] [PATCH 1/4] i965/vec4: Add a brw->gen >= 6 assertion in three-source emitters.

Three source instructions didn't exist until Gen6. vec4_generator has assertions to catch this, but catching it in the visitor provides a nicer backtrace. Cc: "10.1" Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 1 + 1 file changed, 1 insertion(+) diff --

[Mesa-dev] [PATCH 2/4] i965/vec4: Handle ir_triop_lrp on Gen4-5 as well.

When the vec4 backend encountered an ir_triop_lrp, it always emitted an actual LRP instruction, which only exists on Gen6+. Gen4-5 used lower_instructions() to decompose ir_triop_lrp at the IR level. Since commit 8d37e9915a3b21 ("glsl: Optimize open-coded lrp into lrp."), we've had an bug where l

[Mesa-dev] [PATCH 4/4] glsl: Delete LRP_TO_ARITH lowering pass flag.

Tt's kind of a trap---calling do_common_optimization() after lower_instructions() may cause opt_algebraic() to reintroduce ir_triop_lrp expressions that were lowered, effectively defeating the point. Because of this, nobody uses it. Cc: "10.1" Signed-off-by: Kenneth Graunke --- src/glsl/ir_opt

[Mesa-dev] [PATCH 3/4] i965: Stop lowering ir_triop_lrp.

Both the vector and scalar backends now support it natively, so there's no point in lowering it. Cc: "10.1" Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_shader.cpp | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp b/src/mesa/drive

Re: [Mesa-dev] [PATCH 21/25] gallium/r300/r600/radeonsi: handle query_renderer caps

On Sam, 2014-02-22 at 03:04 +, Emil Velikov wrote: > > diff --git a/src/gallium/drivers/radeonsi/si_pipe.c > b/src/gallium/drivers/radeonsi/si_pipe.c > index 4e6478c..adbc981 100644 > --- a/src/gallium/drivers/radeonsi/si_pipe.c > +++ b/src/gallium/drivers/radeonsi/si_pipe.c > @@ -341,6 +341,

Re: [Mesa-dev] [PATCH] i965: Avoid dependency hints on math opcodes

On Wed, Feb 12, 2014 at 9:25 PM, Ian Romanick wrote: > On 02/12/2014 06:59 PM, Matt Turner wrote: >> On Wed, Feb 12, 2014 at 4:24 PM, wrote: >>> From: Mike Stroyan >>> >>> Putting NoDDClr and NoDDChk dependency control on instruction >>> sequences that include math opcodes can cause corruptio

Re: [Mesa-dev] [RFC 08/27] i965/fs: Configure w-tiled stencil surfaces as y-tiled on gen6/7

On Sat, Feb 22, 2014 at 03:48:40PM +0200, Pohjolainen, Topi wrote: > On Sat, Feb 22, 2014 at 11:05:34AM +0200, Topi Pohjolainen wrote: > > Signed-off-by: Topi Pohjolainen > > --- > > src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 28 > > ++-- > > 1 file changed, 26 insert

[Mesa-dev] [PATCH] pipe-loader: wrap pipe_loader_sw_probe_xlib within HAVE_PIPE_LOADER_XLIB

The above function implies using the the xlib winsys, which has additional library dependencies that should not be forced. Make the software xlib pipe loader optional thus avoid all the dependency hell. A user that wishes to use the particular pipe-loader would need to set the following within con

Re: [Mesa-dev] [PATCH] i965: Don't forget to subtract mt->first_level in minify calls.

Kenneth Graunke writes: > This fixes fbo-clear-formats GL_ARB_depth_texture on Ironlake, which > regressed since commit f128bcc7c293013f4b44e4b661638333de0077c2 > ("i965: Drop mt->levels[].width/height.") intel_miptree_copy_slice was > calling minify(.., 7) on a 2x2 texture with mt->first_level

Re: [Mesa-dev] [PATCH] targets/opencl: resolve undefined symbols at link time

Emil Velikov writes: > Current automake build does not try to resolve undefined > symbols thus we could end up with a broken library. > > Signed-off-by: Emil Velikov Looks good to me, Reviewed-by: Francisco Jerez > --- > src/gallium/targets/opencl/Makefile.am | 1 + > 1 file changed, 1 inser

Re: [Mesa-dev] [Intel-gfx] [PATCH] i965: Use default contexts when possible.

On Thu, Jan 02, 2014 at 07:50:35PM -1000, Ben Widawsky wrote: > Will full PPGTT support it can be assumed that every file descriptor > gets its own hardware context. As such, there is no need to allocate > anew context in order to use the features provided by hardware contexts. > Eliminating this e

[Mesa-dev] [PATCH] targets/opencl: resolve undefined symbols at link time

Current automake build does not try to resolve undefined symbols thus we could end up with a broken library. Signed-off-by: Emil Velikov --- src/gallium/targets/opencl/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/targets/opencl/Makefile.am b/src/gallium/targets/op

Re: [Mesa-dev] [PATCH 13/25] gallium: Introduce max_gl*version pipe-caps

On 22/02/14 21:46, Roland Scheidegger wrote: > > > - Original Message - >> From: "Emil Velikov" >> To: "Roland Scheidegger" , mesa-dev@lists.freedesktop.org >> Cc: "emil l velikov" >> Sent: Saturday, February 22, 2014 2:02:08 PM >> Subject: Re: [Mesa-dev] [PATCH 13/25] gallium: Introduc

Re: [Mesa-dev] [PATCH 07/25] dri/nouveau: add GLX_MESA_query_renderer support

On 23/02/14 07:24, Pekka Paalanen wrote: > On Sat, 22 Feb 2014 03:03:57 + > Emil Velikov wrote: > >> v2: nv04-2x cards support upto opengl 1.3. >> v3: Include correct headers. >> >> Signed-off-by: Emil Velikov >> --- >> src/mesa/drivers/dri/nouveau/nouveau_screen.c | 83 >>

Re: [Mesa-dev] [PATCH] mesa: add missing DebugMessageControl types

To make reviewing easier here is the relevant piece of the spec "Tokens accepted or provided by the parameters of DebugMessageControl and DEBUGPROC, and the parameter of GetDebugMessageLog: DEBUG_TYPE_PUSH_GROUP0x8269 DEBUG_TYPE_POP_GROUP

[Mesa-dev] [Bug 75061] bug in clearing color buffer

https://bugs.freedesktop.org/show_bug.cgi?id=75061 --- Comment #10 from Maxim --- Any progress? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop