Re: [Mesa-dev] [RFC] r600g: evergreen/cayman tessellation support

On 2015-12-04 14:03, Dieter Nützel wrote: Am 03.12.2015 19:57, schrieb Dave Airlie: On 4 Dec 2015 03:01, "Aaron Watry" wrote: Hi Dave (and others), I cloned your fdo r600g-tess-submit branch and gave it a spin on CEDAR (Radeon 5400, kernel 4.3.0) with Heaven, and ran into a few issues. Jus

Re: [Mesa-dev] AppVeyor: Build failed: mesa 39

On 04/12/15 03:21, Roland Scheidegger wrote: Am 04.12.2015 um 03:58 schrieb AppVeyor: Build mesa 39 failed Commit 51140f452a by Roland Scheidegger on 12/4/2015 2:42 AM: draw: fix clipping of layer/v

[Mesa-dev] A few misc cleanups using Coccinelle semantic scripts

`Write one patch run everywhere.' These hopefully get a chunk of the churn (sorry about that) out the way for more interesting Coccinelle semantic patching of mesa. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/ma

[Mesa-dev] [PATCH 4/7] gallium/winsys: Make use of ARRAY_SIZE macro

Signed-off-by: Edward O'Callaghan --- src/gallium/winsys/amdgpu/drm/amdgpu_surface.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_surface.c b/src/gallium/winsys/amdgpu/drm/amdgpu_surface.c index 3006bd1..4c837a8 100644 --- a/src/g

[Mesa-dev] [PATCH 1/7] gallium/drivers/nouveau: Make use of ARRAY_SIZE macro

Signed-off-by: Edward O'Callaghan --- src/gallium/drivers/nouveau/nv30/nv30_transfer.c | 2 +- src/gallium/drivers/nouveau/nv50/nv50_state.c | 6 +++--- src/gallium/drivers/nouveau/nv50/nv50_state_validate.c | 3 +-- src/gallium/drivers/nouveau/nv50/nv84_video_bsp.c | 2 +- sr

[Mesa-dev] [PATCH 3/7] gallium/drivers/svga: Make use of ARRAY_SIZE macro

Signed-off-by: Edward O'Callaghan --- src/gallium/drivers/svga/svga_state_tss.c | 2 +- src/gallium/drivers/svga/svgadump/svga_shader_op.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/svga/svga_state_tss.c b/src/gallium/drivers/svga/svga_sta

[Mesa-dev] [PATCH 5/7] gallium/aux../u_mm.c: Fix zero integer literal to pointer comparison

Signed-off-by: Edward O'Callaghan --- src/gallium/auxiliary/util/u_mm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/util/u_mm.c b/src/gallium/auxiliary/util/u_mm.c index 2069b56..bd4c4e1 100644 --- a/src/gallium/auxiliary/util/u_mm.c +++ b/src/galliu

[Mesa-dev] [PATCH 2/7] gallium/drivers/llvmpipe: Make use of ARRAY_SIZE macro

Signed-off-by: Edward O'Callaghan --- src/gallium/drivers/llvmpipe/lp_test_blend.c | 6 +++--- src/gallium/drivers/llvmpipe/lp_test_conv.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/gallium/drivers/llvmpipe/lp_test_blend.c b/src/gallium/drivers/llvmpipe/lp_test_b

[Mesa-dev] [Bug 79688] [dri3] Latest git breaks PRIME Offloading to Nouveau GPU

https://bugs.freedesktop.org/show_bug.cgi?id=79688 --- Comment #20 from Axel Davy --- Should this bug report be closed ? DRI3 has complete DRI_PRIME support now. Also I'm not sure why you do post these benchmarks here. Is there some hidden message about something not working right ? -- You are

[Mesa-dev] [Bug 79688] [dri3] Latest git breaks PRIME Offloading to Nouveau GPU

https://bugs.freedesktop.org/show_bug.cgi?id=79688 --- Comment #19 from poma --- = GLX VSync DRI3 NOUVEAU = /etc/X11/xorg.conf.d/nouveau-dri3.conf Section "Device" Identifier "nvidia0" Driver "nouveau" Option "DRI" "3" EndSection Xorg.0.log: NOUVEAU(0): DRI3 on EXA enab

[Mesa-dev] [Bug 79688] [dri3] Latest git breaks PRIME Offloading to Nouveau GPU

https://bugs.freedesktop.org/show_bug.cgi?id=79688 --- Comment #18 from poma --- = GLX VSync DRI3 INTEL = /etc/X11/xorg.conf.d/intel-dri3.conf Section "Device" Identifier "intel0" Driver "intel" Option "DRI" "3" EndSection Xorg.0.log: intel(0): direct rendering: DRI2 DR

[Mesa-dev] [Bug 79688] [dri3] Latest git breaks PRIME Offloading to Nouveau GPU

https://bugs.freedesktop.org/show_bug.cgi?id=79688 --- Comment #17 from poma --- = GLX VSync DRI2 INTEL = # LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: OpenDriver: trying /usr/lib64/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so ATTENTION: default value of optio

[Mesa-dev] [Bug 79688] [dri3] Latest git breaks PRIME Offloading to Nouveau GPU

https://bugs.freedesktop.org/show_bug.cgi?id=79688 --- Comment #16 from poma --- = XPresent VSync DRI3 NOUVEAU = /etc/X11/xorg.conf.d/nouveau-dri3.conf Section "Device" Identifier "nvidia0" Driver "nouveau" Option "DRI" "3" EndSection Xorg.0.log: NOUVEAU(0): DRI3 on EXA

[Mesa-dev] [Bug 79688] [dri3] Latest git breaks PRIME Offloading to Nouveau GPU

https://bugs.freedesktop.org/show_bug.cgi?id=79688 --- Comment #15 from poma --- = XPresent VSync DRI3 INTEL = /etc/X11/xorg.conf.d/intel-dri3.conf Section "Device" Identifier "intel0" Driver "intel" Option "DRI" "3" EndSection Xorg.0.log: intel(0): direct rendering: DR

[Mesa-dev] [Bug 79688] [dri3] Latest git breaks PRIME Offloading to Nouveau GPU

https://bugs.freedesktop.org/show_bug.cgi?id=79688 --- Comment #14 from poma --- = XPresent VSync DRI2 NOUVEAU = # DRI_PRIME=1 LIBGL_DEBUG=verbose vblank_mode=0 glxgearslibGL: OpenDriver: trying /usr/lib64/dri/tls/nouveau_dri.so libGL: OpenDriver: trying /usr/lib64/dri/nouveau_dri.so libGL: Ca

[Mesa-dev] [Bug 79688] [dri3] Latest git breaks PRIME Offloading to Nouveau GPU

https://bugs.freedesktop.org/show_bug.cgi?id=79688 --- Comment #13 from poma --- = XPresent VSync DRI2 INTEL = # LIBGL_DEBUG=verbose vblank_mode=0 glxgears libGL: OpenDriver: trying /usr/lib64/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so ATTENTION: default value of

[Mesa-dev] [Bug 79688] [dri3] Latest git breaks PRIME Offloading to Nouveau GPU

https://bugs.freedesktop.org/show_bug.cgi?id=79688 --- Comment #12 from poma --- Some of the results with recent Mesa 3D on Optimus/Prime # xrandr --listproviders Providers: number : 1 Provider 0: id: 0x48 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 5 associated provi

[Mesa-dev] AppVeyor: Build completed: mesa 40

Build mesa 40 completed Commit b715e6d528 by Jason Ekstrand on 11/26/2015 8:05 AM: i965/vec4: Stop pretending to support indirect output stores\n\nSince we're using nir_lower_outputs_to_temporaries to shadow all our\noutputs, it's impossible to actually get an

Re: [Mesa-dev] [PATCH] r600g: fix outputing to non-0 buffers for stream 0.

On 4 December 2015 at 14:25, Dave Airlie wrote: > From: Dave Airlie > > This fixes: > arb_transform_feedback3-ext_interleaved_two_bufs_gs > arb_transform_feedback3-ext_interleaved_two_bufs_gs_max > transform-feedback-builtins actually ignore this, I didn't notice it break the xfb-streams cases.

[Mesa-dev] [PATCH] r600g: fix outputing to non-0 buffers for stream 0.

From: Dave Airlie This fixes: arb_transform_feedback3-ext_interleaved_two_bufs_gs arb_transform_feedback3-ext_interleaved_two_bufs_gs_max transform-feedback-builtins --- src/gallium/drivers/r600/r600_shader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers

[Mesa-dev] r600 tess branches updated

Hey all, I've pushed an updated version of the r600g tess support to my r600g-tess-submit branch. I'm in two minds whether we need to spam the list again, I think I've included all the review feedback so far, thanks to everyone that looked. The major changes since the last posting are: use 24-

Re: [Mesa-dev] [PATCH 02/10] i965/vec4: Get rid of the nir_inputs array

On Tue, Dec 1, 2015 at 11:56 PM, Kenneth Graunke wrote: > On Wednesday, November 25, 2015 08:55:54 PM Jason Ekstrand wrote: >> It's not really buying us anything at this point. It's just a way of >> remapping one offset namespace onto another. We can just use the location >> namespace the whole

Re: [Mesa-dev] AppVeyor: Build failed: mesa 39

Am 04.12.2015 um 03:58 schrieb AppVeyor: > > Build mesa 39 failed > > > Commit 51140f452a by Roland Scheidegger on > 12/4/2015 2:42 AM: > draw: fix clipping of layer/vp index outputs\n\nThis was just pla

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #43 from Roland Scheidegger --- (In reply to bellamorte42 from comment #42) > I'm not sure I follow your logic. The code compiles fine on its own. The > code compiles fine under a variety of optimizations. A single optimization > c

Re: [Mesa-dev] [RFC] r600g: evergreen/cayman tessellation support

Am 03.12.2015 19:57, schrieb Dave Airlie: On 4 Dec 2015 03:01, "Aaron Watry" wrote: Hi Dave (and others), I cloned your fdo r600g-tess-submit branch and gave it a spin on CEDAR (Radeon 5400, kernel 4.3.0) with Heaven, and ran into a few issues. Just grab r600g-tess-staging -submit only wor

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #42 from bellamort...@gmail.com --- I'm not sure I follow your logic. The code compiles fine on its own. The code compiles fine under a variety of optimizations. A single optimization causes a segfault. =it's the codes fault? -- Y

[Mesa-dev] AppVeyor: Build failed: mesa 39

Build mesa 39 failed Commit 51140f452a by Roland Scheidegger on 12/4/2015 2:42 AM: draw: fix clipping of layer/vp index outputs\n\nThis was just plain broken. It used always the value from v0 (for vp_index)\nbut would pass the value from the provoking vertex to

Re: [Mesa-dev] [PATCH 10/10] vc4/nir: Use the new unified io intrinsics

On Thu, Dec 3, 2015 at 9:03 PM, Eric Anholt wrote: > Jason Ekstrand writes: > >> On Dec 3, 2015 3:47 PM, "Eric Anholt" wrote: >>> >>> Jason Ekstrand writes: >>> >>> > Cc: Eric Anholt >>> >>> OK, I've pushed a branch of partial fixes for this series to nir-loads >>> of my fdo tree, but it's sti

Re: [Mesa-dev] [PATCH 10/10] vc4/nir: Use the new unified io intrinsics

Jason Ekstrand writes: > On Dec 3, 2015 3:47 PM, "Eric Anholt" wrote: >> >> Jason Ekstrand writes: >> >> > Cc: Eric Anholt >> >> OK, I've pushed a branch of partial fixes for this series to nir-loads >> of my fdo tree, but it's still super broken. I've spent too much of >> today on it, and th

Re: [Mesa-dev] [PATCH v3] glsl: add support for GL_OES_geometry_shader

On 12/02/2015 01:33 AM, Lofstedt, Marta wrote: >> -Original Message- >> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On >> Behalf Of Ian Romanick >> Sent: Tuesday, December 1, 2015 7:52 PM >> To: Marta Lofstedt; mesa-dev@lists.freedesktop.org >> Cc: Emil Velikov >> Subject

Re: [Mesa-dev] [PATCH] mesa/tests: add KHR_debug GLES glGetPointervKHR entry points

On 4 December 2015 at 00:45, Matt Turner wrote: > On Thu, Dec 3, 2015 at 4:37 PM, Emil Velikov wrote: >>> FWIW, make check still fails for me even with this patch. >> Do you have a log that I can take a look ? I've `make clean'ed and >> rebuild a couple of times just in case and things seems to p

Re: [Mesa-dev] [PATCH 10/10] vc4/nir: Use the new unified io intrinsics

On Dec 3, 2015 3:47 PM, "Eric Anholt" wrote: > > Jason Ekstrand writes: > > > Cc: Eric Anholt > > OK, I've pushed a branch of partial fixes for this series to nir-loads > of my fdo tree, but it's still super broken. I've spent too much of > today on it, and this series was not ready for review.

Re: [Mesa-dev] [PATCH 03/10] nir: Get rid of *_indirect variants of input/output load/store intrinsics

On Thu, Dec 3, 2015 at 6:01 PM, Eric Anholt wrote: > Jason Ekstrand writes: > >> There is some special-casing needed in a competent back-end. However, they >> can do their special-casing easily enough based on whether or not the >> offset is a constant. In the mean time, having the *_indirect v

Re: [Mesa-dev] [PATCH 03/10] nir: Get rid of *_indirect variants of input/output load/store intrinsics

On Dec 3, 2015 3:01 PM, "Eric Anholt" wrote: > > Jason Ekstrand writes: > > > There is some special-casing needed in a competent back-end. However, they > > can do their special-casing easily enough based on whether or not the > > offset is a constant. In the mean time, having the *_indirect va

[Mesa-dev] [Bug 93188] "nir/nir.h", line 552: Error: Unexpected type name "nir_src" encountered.

https://bugs.freedesktop.org/show_bug.cgi?id=93188 --- Comment #4 from Ian Romanick --- I guess the question is whether or not this builds with Visual Studio's C++ compiler. If not, maybe we should reopen with changes to the summary? -- You are receiving this mail because: You are the QA Conta

Re: [Mesa-dev] [PATCH] mesa/tests: add KHR_debug GLES glGetPointervKHR entry points

On Thu, Dec 3, 2015 at 4:37 PM, Emil Velikov wrote: >> FWIW, make check still fails for me even with this patch. > Do you have a log that I can take a look ? I've `make clean'ed and > rebuild a couple of times just in case and things seems to pass here. Attached is the output of ./main-test witho

Re: [Mesa-dev] [RFC 2/3] gallium: Move nv50 clear_texture impl down to util_surface

On Thu, Dec 3, 2015 at 7:25 PM, Roland Scheidegger wrote: > Am 03.12.2015 um 23:48 schrieb Ilia Mirkin: >> On Thu, Dec 3, 2015 at 4:44 AM, Edward O'Callaghan >> wrote: >>> ARB_clear_texture is reasonably generic enough that it should >>> be moved down to become part of the fallback mechanism of >

Re: [Mesa-dev] [PATCH] mesa/tests: add KHR_debug GLES glGetPointervKHR entry points

On 4 December 2015 at 00:23, Matt Turner wrote: > On Thu, Dec 3, 2015 at 3:59 PM, Emil Velikov wrote: >> On 3 December 2015 at 22:15, Matt Turner wrote: >>> On Thu, Dec 3, 2015 at 2:05 PM, Emil Velikov >>> wrote: Should have been part of commit f53f9eb8d49 "glapi: add GetPointervKHR

[Mesa-dev] [PATCH v2] mesa/tests: add KHR_debug GLES glGetPointervKHR entry points

Should have been part of commit f53f9eb8d49 "glapi: add GetPointervKHR to the ES dispatch". v2: comment out the ES1.1 symbol and use the same description (pattern) as elsewhere (Matt) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93235 Fixes: f53f9eb8d49 "glapi: add GetPointervKHR to the

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #41 from Roland Scheidegger --- miscompilations are possible but rare, often different compiler options just hide a bug. Did you try running this with valgrind? -- You are receiving this mail because: You are the QA Contact for the

Re: [Mesa-dev] [PATCH 1/6] glsl: Switch opcode and avail parameters to binop().

On Thu, Dec 3, 2015 at 4:24 PM, Matt Turner wrote: > On Thu, Dec 3, 2015 at 4:22 PM, Eric Anholt wrote: >> Matt Turner writes: >> >>> To make it match unop(). >> >> FWIW, this series plus the algebraic patch appears to net the same code >> generated on vc4, so I'm fine with it. Based on the oth

Re: [Mesa-dev] [RFC 2/3] gallium: Move nv50 clear_texture impl down to util_surface

Am 03.12.2015 um 23:48 schrieb Ilia Mirkin: > On Thu, Dec 3, 2015 at 4:44 AM, Edward O'Callaghan > wrote: >> ARB_clear_texture is reasonably generic enough that it should >> be moved down to become part of the fallback mechanism of >> pipe->clear_texture. >> >> Signed-off-by: Edward O'Callaghan >

Re: [Mesa-dev] [PATCH 1/6] glsl: Switch opcode and avail parameters to binop().

On Thu, Dec 3, 2015 at 4:22 PM, Eric Anholt wrote: > Matt Turner writes: > >> To make it match unop(). > > FWIW, this series plus the algebraic patch appears to net the same code > generated on vc4, so I'm fine with it. Based on the other feedback, it > does seem like we should leave the GLSL op

Re: [Mesa-dev] [PATCH] mesa/tests: add KHR_debug GLES glGetPointervKHR entry points

On Thu, Dec 3, 2015 at 3:59 PM, Emil Velikov wrote: > On 3 December 2015 at 22:15, Matt Turner wrote: >> On Thu, Dec 3, 2015 at 2:05 PM, Emil Velikov >> wrote: >>> Should have been part of commit f53f9eb8d49 "glapi: add GetPointervKHR >>> to the ES dispatch". >>> >>> Note: as the core symbol is

Re: [Mesa-dev] [PATCH 1/6] glsl: Switch opcode and avail parameters to binop().

Matt Turner writes: > To make it match unop(). FWIW, this series plus the algebraic patch appears to net the same code generated on vc4, so I'm fine with it. Based on the other feedback, it does seem like we should leave the GLSL ops for now and just change the NIR to be simpler. signature.as

Re: [Mesa-dev] [PATCH] nir: Optimize useless comparisons against true/false.

Matt Turner writes: > --- > I add the true/false variables for clarity since there are some existing > optimizations using ~0 where it actually has nothing to do with true. > > I could take it or leave it. We obviously can't use them for feq and > friends. Maybe itrue/ifalse and ftrue/ffalse? No

Re: [Mesa-dev] [PATCH] mesa/tests: add KHR_debug GLES glGetPointervKHR entry points

On 3 December 2015 at 22:15, Matt Turner wrote: > On Thu, Dec 3, 2015 at 2:05 PM, Emil Velikov wrote: >> Should have been part of commit f53f9eb8d49 "glapi: add GetPointervKHR >> to the ES dispatch". >> >> Note: as the core symbol is present in GLES 1.1 we cannot (should not) >> include the KHR o

Re: [Mesa-dev] [PATCH 6/6] i965/vec4: Optimize predicate handling for any/all.

On Monday, November 30, 2015 03:32:11 PM Matt Turner wrote: > For a select whose condition is any(v), instead of emitting > >cmp.nz.f0(8)null<1>Dg1<0,4,1>D 0D >mov(8) g7<1>.xUD 0xUD >(+f0.any4h) mov(8) g7<1>.xUD0xUD >cmp.nz.f0(8)

Re: [Mesa-dev] [PATCH] meta/generate_mipmap: Work-around GLES 1.x problem with GL_DRAW_FRAMEBUFFER

On Thu, Dec 3, 2015 at 2:43 PM, Ian Romanick wrote: > From: Ian Romanick > > GL_DRAW_FRAMEBUFFER does not exist in OpenGL ES 1.x, and since > _mesa_meta_begin hasn't been called yet, we have to work-around API > difficulties. The whole reason that GL_DRAW_FRAMEBUFFER is used instead > of GL_FRAM

Re: [Mesa-dev] [PATCH 10/10] vc4/nir: Use the new unified io intrinsics

Jason Ekstrand writes: > Cc: Eric Anholt OK, I've pushed a branch of partial fixes for this series to nir-loads of my fdo tree, but it's still super broken. I've spent too much of today on it, and this series was not ready for review. There are still const_index[0] references all over that ar

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #40 from bellamort...@gmail.com --- compiling with -O3 -fno-inline-small-functions works. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. _

Re: [Mesa-dev] [RFC] r600g: evergreen/cayman tessellation support

On Thu, Dec 3, 2015 at 12:57 PM, Dave Airlie wrote: > > On 4 Dec 2015 03:01, "Aaron Watry" wrote: > > > > Hi Dave (and others), > > > > I cloned your fdo r600g-tess-submit branch and gave it a spin on CEDAR > (Radeon 5400, kernel 4.3.0) with Heaven, and ran into a few issues. > > Just grab r600g

Re: [Mesa-dev] [PATCH 03/10] nir: Get rid of *_indirect variants of input/output load/store intrinsics

Jason Ekstrand writes: > There is some special-casing needed in a competent back-end. However, they > can do their special-casing easily enough based on whether or not the > offset is a constant. In the mean time, having the *_indirect variants > adds special cases a number of places where they

Re: [Mesa-dev] [PATCH] radeonsi: fix Fiji for LLVM <= 3.7

On Thu, Dec 3, 2015 at 5:51 PM, Marek Olšák wrote: > From: Marek Olšák > > Cc: 11.0 11.1 Reviewed-by: Alex Deucher > --- > src/gallium/drivers/radeon/r600_pipe_common.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c >

[Mesa-dev] [PATCH] radeonsi: fix Fiji for LLVM <= 3.7

From: Marek Olšák Cc: 11.0 11.1 --- src/gallium/drivers/radeon/r600_pipe_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c b/src/gallium/drivers/radeon/r600_pipe_common.c index 1ed5eb7..f566a29 100644 --- a/src/gallium/

Re: [Mesa-dev] [RFC 2/3] gallium: Move nv50 clear_texture impl down to util_surface

On Thu, Dec 3, 2015 at 4:44 AM, Edward O'Callaghan wrote: > ARB_clear_texture is reasonably generic enough that it should > be moved down to become part of the fallback mechanism of > pipe->clear_texture. > > Signed-off-by: Edward O'Callaghan > --- > src/gallium/auxiliary/util/u_surface.c

Re: [Mesa-dev] [RFC 1/3] gallium/aux/util: Trivial, we already have format use it

Pushed this patch. Thanks, Marek On Thu, Dec 3, 2015 at 10:44 AM, Edward O'Callaghan wrote: > No need to dereference again, fixup for clarity. > > Signed-off-by: Edward O'Callaghan > --- > src/gallium/auxiliary/util/u_surface.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

[Mesa-dev] [PATCH] meta/generate_mipmap: Work-around GLES 1.x problem with GL_DRAW_FRAMEBUFFER

From: Ian Romanick GL_DRAW_FRAMEBUFFER does not exist in OpenGL ES 1.x, and since _mesa_meta_begin hasn't been called yet, we have to work-around API difficulties. The whole reason that GL_DRAW_FRAMEBUFFER is used instead of GL_FRAMEBUFFER is that the read framebuffer may be different. This is

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #39 from bellamort...@gmail.com --- Ugh, bisection is done. CXXFLAG -finline-small-functions cuases the segfault. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. _

Re: [Mesa-dev] [PATCH] mesa/tests: add KHR_debug GLES glGetPointervKHR entry points

On Thu, Dec 3, 2015 at 2:05 PM, Emil Velikov wrote: > Should have been part of commit f53f9eb8d49 "glapi: add GetPointervKHR > to the ES dispatch". > > Note: as the core symbol is present in GLES 1.1 we cannot (should not) > include the KHR one in the es11 table. Add the symbol, commented out, > w

Re: [Mesa-dev] [PATCH] mesa/tests: add KHR_debug GLES glGetPointervKHR entry points

On Thu, Dec 3, 2015 at 2:05 PM, Emil Velikov wrote: > Should have been part of commit f53f9eb8d49 "glapi: add GetPointervKHR > to the ES dispatch". > > Note: as the core symbol is present in GLES 1.1 we cannot (should not) > include the KHR one in the es11 table. Add the symbol, commented out, > w

[Mesa-dev] [PATCH] mesa/tests: add KHR_debug GLES glGetPointervKHR entry points

Should have been part of commit f53f9eb8d49 "glapi: add GetPointervKHR to the ES dispatch". Note: as the core symbol is present in GLES 1.1 we cannot (should not) include the KHR one in the es11 table. Add the symbol, commented out, with description for posterity. Bugzilla: https://bugs.freedeskt

Re: [Mesa-dev] [PATCH v3 09/44] i965/hsw: Enable L3 atomics.

On Tuesday, December 01, 2015 12:19:27 AM Jordan Justen wrote: > From: Francisco Jerez > > Improves performance of the arb_shader_image_load_store-atomicity > piglit test by over 25x (which isn't a real benchmark it's just heavy > on atomics -- the improvement in a microbenchmark I wrote a while

Re: [Mesa-dev] [PATCH v3 14/44] i965: Add debug flag to print out the new L3 state during transitions.

On Tuesday, December 01, 2015 12:19:32 AM Jordan Justen wrote: > From: Francisco Jerez > > Reviewed-by: Jordan Justen > Reviewed-by: Samuel Iglesias Gonsálvez > --- > src/mesa/drivers/dri/i965/gen7_l3_state.c | 17 + > src/mesa/drivers/dri/i965/intel_debug.c | 1 + > src/mes

Re: [Mesa-dev] [PATCH v3 13/44] i965: Implement L3 state atom.

On Tuesday, December 01, 2015 12:19:31 AM Jordan Justen wrote: > From: Francisco Jerez > > The L3 state atom calculates the target L3 partition weights when the > program bound to some shader stage is modified, and in case they are > far enough from the current partitioning it makes sure that the

Re: [Mesa-dev] [PATCH 00/26] i965: Tessellation shaders for Gen8+!

On Wed, Dec 2, 2015 at 4:15 PM, Kenneth Graunke wrote: > Happy reviewing! Patches 3-8 are Reviewed-by: Matt Turner I sent a few small comments on 9. The only real question I have is about the minimum number of VS URB entries -- it seems to be BDW-only according to the docs. More to come.

Re: [Mesa-dev] [PATCH 09/26] i965: URB allocations for tessellation

On Wed, Dec 2, 2015 at 4:15 PM, Kenneth Graunke wrote: > From: Chris Forbes > > Signed-off-by: Chris Forbes The commit title should be some imperative statement. Maybe just add "Add" to the beginning. > --- > src/mesa/drivers/dri/i965/brw_context.h | 17 +++- > src/mesa/drivers/dri/i965/gen

Re: [Mesa-dev] [PATCH 09/26] i965: URB allocations for tessellation

On Thu, Dec 3, 2015 at 12:01 PM, Matt Turner wrote: > Align the overflowing expression in these ALIGN()s Ignore this -- just GMail messing up whitespace. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listi

Re: [Mesa-dev] [PATCH v2] mesa/version: Update gl_extensions::Version during version override

On 3 December 2015 at 19:05, Nanley Chery wrote: > On Thu, Dec 3, 2015 at 10:58 AM, Emil Velikov > wrote: >> >> On 1 December 2015 at 20:21, Nanley Chery wrote: >> > On Tue, Dec 01, 2015 at 10:44:43AM -0800, Nanley Chery wrote: >> > From: Nanley Chery >> > >> > Commit a16ffb743ced9fde80b2485dfc

Re: [Mesa-dev] [PATCH v2] mesa/version: Update gl_extensions::Version during version override

On Thu, Dec 3, 2015 at 11:05 AM, Nanley Chery wrote: > > > On Thu, Dec 3, 2015 at 10:58 AM, Emil Velikov > wrote: >> >> On 1 December 2015 at 20:21, Nanley Chery wrote: >> > On Tue, Dec 01, 2015 at 10:44:43AM -0800, Nanley Chery wrote: >> > From: Nanley Chery >> > >> > Commit a16ffb743ced9fde80

Re: [Mesa-dev] [PATCH v2] mesa/version: Update gl_extensions::Version during version override

On Thu, Dec 3, 2015 at 10:58 AM, Emil Velikov wrote: > On 1 December 2015 at 20:21, Nanley Chery wrote: > > On Tue, Dec 01, 2015 at 10:44:43AM -0800, Nanley Chery wrote: > > From: Nanley Chery > > > > Commit a16ffb743ced9fde80b2485dfc2d86ae74e86f25, which introduced > > gl_extensions::Version,

Re: [Mesa-dev] [PATCH v2 0/1] Do not require all components to apply opt_vector_float()

On Wed, Dec 2, 2015 at 7:43 AM, Juan A. Suarez Romero wrote: > This patch, based on Matt suggestion, replaces the former two ones, as it gets > better results. > > Basically, so far opt_vector_float() is only applied when the 4 components of > the register are written with MOV. This patch changes

Re: [Mesa-dev] [PATCH v2 1/1] i965: add opportunistic behaviour to opt_vector_float()

On Wed, Dec 2, 2015 at 7:43 AM, Juan A. Suarez Romero wrote: > opt_vector_float() transforms several scalar MOV operations to a single > vectorial MOV. > > This is done when those MOV covers all the components of the destination > register. So something like: > > mov vgrf3.0.xy:D, 0D > mov vgrf3.0

[Mesa-dev] [PATCH] nv50/ir: fix DCE to not generate 96-bit loads

A situation where there's a 128-bit load where the last component gets DCE'd causes a 96-bit load to be generated, which no GPU can actually emit. Avoid generating such instructions by scaling back to 64-bit on the first load when splitting. Signed-off-by: Ilia Mirkin Cc: "11.0 11.1" --- .../dr

Re: [Mesa-dev] [PATCH v2] mesa/version: Update gl_extensions::Version during version override

On 1 December 2015 at 20:21, Nanley Chery wrote: > On Tue, Dec 01, 2015 at 10:44:43AM -0800, Nanley Chery wrote: > From: Nanley Chery > > Commit a16ffb743ced9fde80b2485dfc2d86ae74e86f25, which introduced > gl_extensions::Version, updates the field when the context version > is computed and when e

Re: [Mesa-dev] [RFC] r600g: evergreen/cayman tessellation support

On 4 Dec 2015 03:01, "Aaron Watry" wrote: > > Hi Dave (and others), > > I cloned your fdo r600g-tess-submit branch and gave it a spin on CEDAR (Radeon 5400, kernel 4.3.0) with Heaven, and ran into a few issues. Just grab r600g-tess-staging -submit only worked on cayman, but i d posted it here so

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #38 from har...@gmx.de --- @bellamorte, for better performance of this workaround, you could try the following: 1. make clean 2. generate 'makefile' via 'autogen.sh' with your prefered settings 3. make 4. delete 'src/mesa/state_track

Re: [Mesa-dev] [PATCH v3 10/44] i965: Define and use REG_MASK macro to make masked MMIO writes slightly more readable.

On Tuesday, December 01, 2015 12:19:28 AM Jordan Justen wrote: > From: Francisco Jerez > > Reviewed-by: Samuel Iglesias Gonsálvez > --- > src/mesa/drivers/dri/i965/brw_defines.h | 6 ++ > src/mesa/drivers/dri/i965/brw_state_upload.c | 2 +- > src/mesa/drivers/dri/i965/gen7_l3_state.c

Re: [Mesa-dev] [PATCH v3 08/44] i965: Implement programming of the L3 configuration.

On Tuesday, December 01, 2015 12:19:26 AM Jordan Justen wrote: > From: Francisco Jerez > > --- > src/mesa/drivers/dri/i965/gen7_l3_state.c | 95 > +++ > 1 file changed, 95 insertions(+) > > diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c > b/src/mesa/drivers

Re: [Mesa-dev] [PATCH v3 07/44] i965: Import tables enumerating the set of validated L3 configurations.

On Tuesday, December 01, 2015 12:19:25 AM Jordan Justen wrote: > From: Francisco Jerez > > It should be possible to use additional L3 configurations other than > the ones listed in the tables of validated allocations ("BSpec » > 3D-Media-GPGPU Engine » L3 Cache and URB [IVB+] » L3 Cache and URB [

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #37 from bellamort...@gmail.com --- Confirmed that -O3 CFLAGS and -O1 CXXFLAGS works. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. _

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #36 from har...@gmx.de --- i can now confirm: Compiling only file 'st_glsl_to_tgsi.cpp' with '-O1' and everything else with default '-O2' works flawless. -- You are receiving this mail because: You are the QA Contact for the bug. Yo

[Mesa-dev] [Bug 92850] Segfault loading War Thunder

https://bugs.freedesktop.org/show_bug.cgi?id=92850 --- Comment #35 from har...@gmx.de --- I found that only CXXFLAGS do the trick. If i append CXXFLAGS='-O1' to the configure params, WT works flawless. Since 'st_glsl_to_tgsi.cpp' is the only .cpp file in folder 'state_tracker', it seems to make

[Mesa-dev] AppVeyor: Build completed: mesa 32

Build mesa 32 completed Commit a0f1bc18e5 by Brian Paul on 12/3/2015 4:40 PM: mesa: print enum names rather than hexadecimal values in error messages\n\nTrivial. Configure your notification preferences ___

Re: [Mesa-dev] [RFC] r600g: evergreen/cayman tessellation support

Hi Dave (and others), I cloned your fdo r600g-tess-submit branch and gave it a spin on CEDAR (Radeon 5400, kernel 4.3.0) with Heaven, and ran into a few issues. 1) Initially, I got an assertion in r600_add_atom stating that the atom ID was not less than the R600_NUM_ATOMS value (id = 51, R600_NUM

[Mesa-dev] AppVeyor: Build failed: mesa 31

Build mesa 31 failed Commit e832b5b7fa by Brian Paul on 12/3/2015 4:12 PM: st/wgl: add support for WGL_ARB_render_texture\n\nThere are a few legacy OpenGL apps on Windows which need this extension.\nWe basically use glCopyTex[Sub]Image to implement wglBindTexIm

Re: [Mesa-dev] [RFC 2/3] gallium: Move nv50 clear_texture impl down to util_surface

One problem with this is that clear_render_target and clear_depth_stencil honor render condition, whereas clear_texture does not. nv50 got it wrong, but I care a lot more when that wrongness is moved to util. This could be fixed by making clear_render_target and clear_depth_stencil optionally honor

Re: [Mesa-dev] [PATCH 3/3] draw: fix clipping of layer/vp index outputs

On 03/12/15 00:35, srol...@vmware.com wrote: From: Roland Scheidegger This was just plain broken. It used always the value from v0 (for vp_index) but would pass the value from the provoking vertex to later stages - but only if there was a corresponding fs input, otherwise the layer/vp index wou

Re: [Mesa-dev] [RFC 3/3] radeonsi: Add ARB_clear_texture support

On Thu, Dec 3, 2015 at 10:44 AM, Edward O'Callaghan wrote: > Unfortantly we may not toggle on PIPE_CAP_CLEAR_TEXTURE > and update GL3.txt at this time as the piglit > ARB_clear_texture-float test still fails for unknown > reasons. > > However, this does allow a user to fake this extention > now an

Re: [Mesa-dev] [RFC 2/3] gallium: Move nv50 clear_texture impl down to util_surface

On Thu, Dec 3, 2015 at 10:44 AM, Edward O'Callaghan wrote: > ARB_clear_texture is reasonably generic enough that it should > be moved down to become part of the fallback mechanism of > pipe->clear_texture. > > Signed-off-by: Edward O'Callaghan > --- > src/gallium/auxiliary/util/u_surface.c

[Mesa-dev] [RFC 3/3] radeonsi: Add ARB_clear_texture support

Unfortantly we may not toggle on PIPE_CAP_CLEAR_TEXTURE and update GL3.txt at this time as the piglit ARB_clear_texture-float test still fails for unknown reasons. However, this does allow a user to fake this extention now and get some reasonable level of support should they urgently need this. S

[Mesa-dev] [RFC 2/3] gallium: Move nv50 clear_texture impl down to util_surface

ARB_clear_texture is reasonably generic enough that it should be moved down to become part of the fallback mechanism of pipe->clear_texture. Signed-off-by: Edward O'Callaghan --- src/gallium/auxiliary/util/u_surface.c | 83 + src/gallium/auxiliary/util/u_surface.

[Mesa-dev] [RFC 1/3] gallium/aux/util: Trivial, we already have format use it

No need to dereference again, fixup for clarity. Signed-off-by: Edward O'Callaghan --- src/gallium/auxiliary/util/u_surface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/util/u_surface.c b/src/gallium/auxiliary/util/u_surface.c index 70ed911..6aa44f

[Mesa-dev] radeonsi ARB_clear_texture support

The following patches make steps towards getting ARB_clear_texture support working on radeonsi. There is still some outstanding work to be done before we may toggle on the PIPE and check it off as done. The following is thus preliminary refactoring to set the stage for further work without the chu

Re: [Mesa-dev] [PATCH] travis: Initial import of travis instructions.

On 03/12/15 01:51, Michel Dänzer wrote: On 03.12.2015 06:01, Jose Fonseca wrote: On 02/12/15 03:39, Michel Dänzer wrote: On 02.12.2015 07:06, Jose Fonseca wrote: On 28/11/15 21:06, Emil Velikov wrote: On 25 November 2015 at 07:20, Jose Fonseca wrote: BTW, I setup Mesa with Appveyor (like T

[Mesa-dev] AppVeyor: Build completed: mesa 29

Build mesa 29 completed Commit 231db5869c by Tapani Pälli on 12/2/2015 11:21 AM: i965: use _Shader to get fragment program when updating surface state\n\nAtomic counters and Images were using ctx::Shader that does not take in\nto account program pipeline change