Valgrind reports that we use cfg.cycle_count uninitialised, so zero the
cfg_t on construction.
Fixes: 52d2b28f7f10 ("ralloc: use rzalloc where it's necessary")
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Marek Olšák
Cc: Edmondo Tommasina
Cc: Nicolai Hähnle
---
src/mesa/drivers/dri/i9
On Wed, Nov 02, 2016 at 12:14:32PM +0900, Michel Dänzer wrote:
> On 01/11/16 08:10 PM, Chris Wilson wrote:
> > glXSwapBuffers() is translated internally into glXSwapBuffersMsc() with
> > a target and divisor of 0.
> >
> > https://www.opengl.org/registry/specs/OML/glx_sync_control.txt
> >
> >
On Wed, Nov 02, 2016 at 10:09:26AM +0900, Michel Dänzer wrote:
> On 22/10/16 07:00 PM, Chris Wilson wrote:
> > This applies a synchronisation point to GetBuffers() such that binding a
> > texture-from-pixmap its rendering is serialised with X. This matches the
> > synchronisation point inside DRI2,
On 02/11/16 04:13 PM, Chris Wilson wrote:
> On Wed, Nov 02, 2016 at 10:09:26AM +0900, Michel Dänzer wrote:
>> On 22/10/16 07:00 PM, Chris Wilson wrote:
>>> This applies a synchronisation point to GetBuffers() such that binding a
>>> texture-from-pixmap its rendering is serialised with X. This match
On Tue, Nov 01, 2016 at 08:09:10PM -0700, Jason Ekstrand wrote:
> ---
> src/intel/blorp/blorp.c | 28 +++-
> src/intel/blorp/blorp_blit.c | 2 +-
> src/intel/blorp/blorp_clear.c | 2 +-
> src/intel/blorp/blorp_genX_exec.h | 31 --
On Wed, Nov 02, 2016 at 04:16:55PM +0900, Michel Dänzer wrote:
> On 02/11/16 04:13 PM, Chris Wilson wrote:
> > On Wed, Nov 02, 2016 at 10:09:26AM +0900, Michel Dänzer wrote:
> >> On 22/10/16 07:00 PM, Chris Wilson wrote:
> >>> This applies a synchronisation point to GetBuffers() such that binding a
Hi,
This maybe somewhat of a striking topic however it is one that has not
really had enough attention, I feel, in a way that warrants the gravity
of if ramifications. Thus, I really would like to kick this discussion
into hopefully something serious and creditable that we can all think
about. Als
On Tue, Nov 01, 2016 at 08:09:11PM -0700, Jason Ekstrand wrote:
> ---
> src/intel/blorp/blorp.h | 5 +++--
> src/intel/blorp/blorp_blit.c | 2 +-
> src/intel/blorp/blorp_clear.c | 2 +-
> src/intel/vulkan/anv_blorp.c | 3 ++-
> src/mesa/drivers/dri/i965/brw_
On 02/11/16 04:43 PM, Chris Wilson wrote:
> On Wed, Nov 02, 2016 at 04:16:55PM +0900, Michel Dänzer wrote:
>> On 02/11/16 04:13 PM, Chris Wilson wrote:
>>> On Wed, Nov 02, 2016 at 10:09:26AM +0900, Michel Dänzer wrote:
On 22/10/16 07:00 PM, Chris Wilson wrote:
> This applies a synchronisat
On Tue, Nov 01, 2016 at 08:09:12PM -0700, Jason Ekstrand wrote:
> While we can simply calculate offsets to get to things such as the
> prog_data and the key, it's much more user-friendly if there are just
> pointers. Also, it's a bit more fool-proof.
>
> While we're at it, we rework the pipeline
On Tuesday, 2016-11-01 17:56:05 -0700, Jason Ekstrand wrote:
> Without this fix, the function would still end up returning NULL but it
> would put that NULL connection in the hash table which would be bad.
>
> Signed-off-by: Jason Ekstrand
> Cc: "13.0"
> Cc: Dave Airlie
Series is:
Reviewed-by:
Reviewed-by: Marek Olšák
Marek
On Wed, Nov 2, 2016 at 8:01 AM, Chris Wilson wrote:
> Valgrind reports that we use cfg.cycle_count uninitialised, so zero the
> cfg_t on construction.
>
> Fixes: 52d2b28f7f10 ("ralloc: use rzalloc where it's necessary")
> Signed-off-by: Chris Wilson
> Cc: Kenneth
On Wed, Nov 2, 2016 at 2:38 AM, Timothy Arceri
wrote:
> I'm about to do some refactoring that will move a bunch of glsl only
> fields from gl_linked_program into gl_program.
>
> If we wan't to share memory it makes sense to do it while I move
> things. I just wanted to see what people think about
From: Michel Dänzer
Fixes valgrind warnings about using uninitialized memory when starting X.
Signed-off-by: Michel Dänzer
---
src/gallium/winsys/radeon/drm/radeon_drm_surface.c | 31 +++---
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/src/gallium/winsys/rade
From: Michel Dänzer
Fixes spurious assertion failure in surf_level_drm_to_winsys when
starting X, due to processing a miplevel which was never initialized.
Fixes: e9c76eeeaa67 ("gallium/radeon: remove radeon_surf_level::pitch_bytes")
Signed-off-by: Michel Dänzer
---
src/gallium/winsys/radeon/d
From: Michel Dänzer
Fixes valgrind warnings about surf_ws->flags being uninitialized while
starting X.
Signed-off-by: Michel Dänzer
---
src/gallium/winsys/radeon/drm/radeon_drm_surface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_dr
From: Michel Dänzer
For symmetry with surf_drm_to_winsys.
Signed-off-by: Michel Dänzer
---
src/gallium/winsys/radeon/drm/radeon_drm_surface.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_surface.c
b/src/gallium/winsys/rade
Otherwise it won't be picked in the tarball and the build will fail.
Fixes: 533b3530c12 ("direct-to-native-GL for GLX clients on Cygwin
("Windows-DRI")")
Cc: "13.0"
Signed-off-by: Andreas Boll
---
src/glx/windows/Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/
On 02/11/2016 11:13, Andreas Boll wrote:
Otherwise it won't be picked in the tarball and the build will fail.
Thanks, my bad.
Reviewed-by: Jon Turney
Fixes: 533b3530c12 ("direct-to-native-GL for GLX clients on Cygwin
("Windows-DRI")")
Cc: "13.0"
Signed-off-by: Andreas Boll
---
src/glx/wi
On 02.11.2016 08:59, Edward O'Callaghan wrote:
This maybe somewhat of a striking topic however it is one that has not
really had enough attention, I feel, in a way that warrants the gravity
of if ramifications. Thus, I really would like to kick this discussion
into hopefully something serious and
On 29.10.2016 01:13, Marek Olšák wrote:
From: Marek Olšák
---
src/compiler/glsl/ir_optimization.h | 3 ++-
src/compiler/glsl/lower_if_to_cond_assign.cpp | 23 ---
src/compiler/glsl/test_optpass.cpp| 2 +-
src/mesa/drivers/dri/i965/brw_link.cpp
Patches 1, 2, 4 - 6:
Reviewed-by: Nicolai Hähnle
I have one pending LLVM patch related to indirect addressing. Not sure
if that's related to the regressions, but it may be.
Cheers,
Nicolai
On 29.10.2016 01:13, Marek Olšák wrote:
Hi,
this series enables lowering small branches for radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=98263
Vedran Miletić changed:
What|Removed |Added
CC||ved...@miletic.net
--
You are receivin
Hi Chris,
On 22 October 2016 at 11:00, Chris Wilson wrote:
> Xorg may implement fine grained per-drawable serialisation. If the
> client is reading from shared pixmap sources, flushing rendering to the
> current drawable is not enough (even if the current code did that, it
> does not). Instead, f
On 1 November 2016 at 23:47, Timothy Arceri
wrote:
> This move the delete linked shaders call to
> _mesa_clear_shader_program_data() which makes sure we delete them
> before returning due to any validation problems.
>
> It also reduces some code duplication.
>
> Cc: Tapani Pälli
> Bugzilla: https
On Mon, 2016-10-31 at 22:19 +0100, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> When a UBO reference has the form block_name.foo where block_name
> refers
> to a block where the first member has a non-zero offset, the base
> offset
> was incorrectly added to the reference.
The patch looks go
On Tue, 2016-11-01 at 20:48 +, Chris Wilson wrote:
> The fence_fd is closed by xcb_dri3_fence_from_fd() as
> xcb_send_request_with_fds() always calls close().
> -Chris
D'oh! You are correct. Objection withdrawn.
- ajax
___
mesa-dev mailing list
mes
Hi Leo,
To support clipping of the output texture I was trying to send a
xcb_xfixes_region as the fifth argument (i.e valid-area) to
xcb_present_pixmap but it still displays the entire surface. Am I missing
something?
Regards,
Nayan
___
mesa-dev mailing
On Wed, Nov 02, 2016 at 11:26:08AM +1000, Dave Airlie wrote:
> So it appears at least the LLVM 3.9 backend can get confused
> when it gets hit with if (cond) discard type constructs, and we
> have a GLSL optimisation to convert this to discard_if, so I've
> ported that to NIR, and enabled it for ra
Right now, if this happens we trigger an assertion when we try to create
a GRF register > 128. Let the backend compiler fail the compilation in this
case. For things like geometry shaders, this can trigger a compilation
using interleaved attribute setup which might even help get the shader to
compi
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 1fb65f3..03c83af 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drive
On 02.11.2016 02:26, Dave Airlie wrote:
From: Dave Airlie
This is ported from GLSL and converts
if (cond)
discard;
into
discard_if(cond);
This removes a block, but also is needed by radv
to workaround a bug in the LLVM backend.
FYI, the GLSL pass also converts
if (A)
discard
On 02.11.2016 15:46, Iago Toral wrote:
On Mon, 2016-10-31 at 22:19 +0100, Nicolai Hähnle wrote:
From: Nicolai Hähnle
When a UBO reference has the form block_name.foo where block_name
refers
to a block where the first member has a non-zero offset, the base
offset
was incorrectly added to the re
From: Emil Velikov
The use of regparm causes an error on arm/arm64 builds with clang.
fastcall is allowed, but still throws a warning. As both options only
have effect on 32-bit x86 builds, limit them to that case.
v2: keep the __i386__ within GCC (Nicolai)
Cc: 13.0
Cc: Rob Herring
Cc: Nicola
On 28 October 2016 at 10:54, Chih-Wei Huang wrote:
> Note LOCAL_CFLAGS and LOCAL_SHARED_LIBRARIES in Android.common.mk
> are used by both host and target modules. However, commit 112e988
> moved libdrm related flags to common. It causes the errors like:
>
> error:
> 'out/host/linux-x86/obj32/SHAR
Dave Airlie writes:
> From: Dave Airlie
>
> This is ported from GLSL and converts
>
> if (cond)
> discard;
>
> into
> discard_if(cond);
>
> This removes a block, but also is needed by radv
> to workaround a bug in the LLVM backend.
I think this is missing "also make sure that after our if
Nicolai Hähnle writes:
> On 02.11.2016 08:59, Edward O'Callaghan wrote:
>> This maybe somewhat of a striking topic however it is one that has not
>> really had enough attention, I feel, in a way that warrants the gravity
>> of if ramifications. Thus, I really would like to kick this discussion
>>
On 02.11.2016 16:32, Emil Velikov wrote:
From: Emil Velikov
The use of regparm causes an error on arm/arm64 builds with clang.
fastcall is allowed, but still throws a warning. As both options only
have effect on 32-bit x86 builds, limit them to that case.
v2: keep the __i386__ within GCC (Nico
Timothy Arceri writes:
> I'm about to do some refactoring that will move a bunch of glsl only
> fields from gl_linked_program into gl_program.
>
> If we wan't to share memory it makes sense to do it while I move
> things. I just wanted to see what people think about this before
> I get started as
For the series:
Reviewed-by: Nicolai Hähnle
On 02.11.2016 12:11, Michel Dänzer wrote:
From: Michel Dänzer
For symmetry with surf_drm_to_winsys.
Signed-off-by: Michel Dänzer
---
src/gallium/winsys/radeon/drm/radeon_drm_surface.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Thanks to both of you. Pushed.
On Wed, Nov 2, 2016 at 3:11 AM, Eric Engestrom
wrote:
> On Tuesday, 2016-11-01 17:56:05 -0700, Jason Ekstrand wrote:
> > Without this fix, the function would still end up returning NULL but it
> > would put that NULL connection in the hash table which would be bad
On Tue, Nov 01, 2016 at 03:35:13PM -0700, Jason Ekstrand wrote:
> +static void
> +write_reloc(const struct anv_device *device, void *p, uint64_t v)
> +{
> + unsigned reloc_size = 0;
> + if (device->info.gen >= 8) {
> + /* From the Broadwell PRM Vol. 2a, MI_LOAD_REGISTER_MEM::MemoryAddress:
This is a nice refactoring.
Reviewed-by: Samuel Pitoiset
On 11/02/2016 05:38 AM, Ilia Mirkin wrote:
The GM107 had a bunch of prepareEmission needlessly duplicated because
the sched block size is different. Move that knowledge into the target,
and generalize the existing code.
Signed-off-by: I
This seems like redundant, and because the GM107 emitter already has a
bunch of emitXXX() helpers, how about adding emitTARG()? Like:
void
CodeEmitterGM107::emitTARG()
{
int32_t pos = insn->target.bb->binPos;
if (writeIssueDelays && !(pos & 0x1f))
pos += 8;
emitField(0x14, 24, pos - (c
Good idea, will put a v2 together.
On Wed, Nov 2, 2016 at 1:20 PM, Samuel Pitoiset
wrote:
> This seems like redundant, and because the GM107 emitter already has a bunch
> of emitXXX() helpers, how about adding emitTARG()? Like:
>
> void
> CodeEmitterGM107::emitTARG()
> {
> int32_t pos = insn->t
Regarding to xcb_present_pixmap client call, you might have to check
xserver present/present.c on how xserver deal with it.
Regards,
Leo
On 11/02/2016 10:55 AM, Nayan Deshmukh wrote:
Hi Leo,
To support clipping of the output texture I was trying to send a
xcb_xfixes_region as the fifth argum
On 10/30/2016 08:16 PM, Francisco Jerez wrote:
> Vedran Miletić writes:
>
>> OpenCL apps can quote arguments they pass to the OpenCL compiler, most
>> commonly include paths containing spaces.
>>
>> If the Clang OpenCL compiler was called via a shell, the shell would
>> split the arguments with r
From: Marek Olšák
I need the definition of PUBLIC.
Cc: 12.0 13.0
---
src/egl/drivers/dri2/egl_dri2.h | 2 --
src/egl/main/egldefines.h | 5 ++---
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 85d4b85
From: Marek Olšák
This was broken when the GLAPI use was removed from mesa_glinterop.h.
Cc: 12.0 13.0
---
src/glx/glxcmds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 6abe0b9..8980de3 100644
--- a/src/glx/glxcmds.c
+++ b/
From: Marek Olšák
This was broken when the GLAPI use was removed from mesa_glinterop.h.
Cc: 12.0 13.0
---
src/egl/main/eglapi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 04cac03..53340bf 100644
--- a/src/egl/main
On Tue, Nov 1, 2016 at 6:26 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This is ported from GLSL and converts
>
> if (cond)
> discard;
>
> into
> discard_if(cond);
>
> This removes a block, but also is needed by radv
> to workaround a bug in the LLVM backend.
>
> Signed-off-by: Dave Ai
On Wed, Nov 2, 2016 at 9:43 AM, Chris Wilson
wrote:
> On Tue, Nov 01, 2016 at 03:35:13PM -0700, Jason Ekstrand wrote:
> > +static void
> > +write_reloc(const struct anv_device *device, void *p, uint64_t v)
> > +{
> > + unsigned reloc_size = 0;
> > + if (device->info.gen >= 8) {
> > + /*
On Wed, Nov 2, 2016 at 2:07 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> This was broken when the GLAPI use was removed from mesa_glinterop.h.
>
> Cc: 12.0 13.0
Series is:
Acked-by: Alex Deucher
> ---
> src/glx/glxcmds.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #42 from Evan Black ---
Can't really contribute much in terms of any of the tracing stuff; just
dropping my specs here as I have similar issues.
Core i5 4690k
R9 285
8 GB Memory
I've tried it both on my SSD and HDD, and the issue wa
Signed-off-by: Topi Pohjolainen
CC: Jason Ekstrand
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 35 ---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
ind
There are actually two contradicting pieces in the bspec:
From the BSpec: 3D-Media-GPGPU Engine - 3D Pipeline Stages - Pixel -
Pixel Backend [IVB+] - MCS Buffer for Render Target(s)
BDW: Mip-mapped and arrayed surfaces are supported with MCS buffer
layout with these alignments in the RT sp
On Wed, Nov 2, 2016 at 12:45 PM, Topi Pohjolainen <
topi.pohjolai...@gmail.com> wrote:
> Signed-off-by: Topi Pohjolainen
> CC: Jason Ekstrand
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 35
> ---
> 1 file changed, 32 insertions(+), 3 deletions(-)
>
> diff --g
Series is
Reviewed-by: Jason Ekstrand
On Thu, Sep 22, 2016 at 5:19 PM, Nanley Chery wrote:
> This series prevents invalid compressed textures from being created in
> the Vulkan driver. There aren't any Vulkan CTS tests for 1D compressed
> textures, so no change has been observed in that test s
On Wed, Nov 02, 2016 at 01:37:07PM -0700, Jason Ekstrand wrote:
> Series is
>
> Reviewed-by: Jason Ekstrand
>
Thanks!
> On Thu, Sep 22, 2016 at 5:19 PM, Nanley Chery wrote:
>
> > This series prevents invalid compressed textures from being created in
> > the Vulkan driver. There aren't any Vu
This puts the actual execbuf2 call in anv_batch_chain.c along with the
other relocation stuff.
---
src/intel/vulkan/anv_batch_chain.c | 8
src/intel/vulkan/anv_device.c | 3 +--
src/intel/vulkan/anv_private.h | 2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a
Because our relocation processing happens at EndCommandBuffer time and
because RENDER_SURFACE_STATE objects may be shared by batches, we really
have no clue whatsoever what address is actually written to the relocation
offset in the BO. We need to stop making such claims to the kernel and
just let
This is primarily a re-send of the previous series. In responding to some
of Chris Wilson's comments, I found more bugs in the existing relocation
code which required some fixing.
One major change from the previous series is that I put all of the new
relocation handling code in anv_batch_chain.c
This ensures that we're always setting all of the fields in anv_bo
Signed-off-by: Jason Ekstrand
---
src/intel/vulkan/anv_allocator.c | 9 ++---
src/intel/vulkan/anv_device.c| 10 +++---
src/intel/vulkan/anv_intel.c | 11 +--
src/intel/vulkan/anv_private.h | 11 +++
This wrapper ensures that we always update all anv_bo::offset fields based
on the offsets returned by the kernel.
Signed-off-by: Jason Ekstrand
---
src/intel/vulkan/anv_device.c | 51 +-
src/intel/vulkan/anv_private.h | 4
2 files changed, 35 insert
The previous implementation was being overly clever and using the
anv_bo::size field as its mutex. Scratch pool allocations don't happen
often, will happen at most a fixed number of times, and never happen in the
critical path (they only happen in shader compilation). We can make this
much simple
Since -1 is an invalid GPU address, this lets us know whether or not we
have a valid address for a buffer. We don't get a valid address until the
first time that buffer is used in an execbuf2 ioctl.
Signed-off-by: Jason Ekstrand
---
src/intel/vulkan/anv_private.h | 2 +-
1 file changed, 1 inser
The old version wasn't properly handling large addresses where we have to
sign-extend to get it into the "canonical form" expected by the hardware.
Also, the new version is capable of doing a clflush of the newly written
reloc if requested.
Signed-off-by: Jason Ekstrand
---
src/intel/vulkan/anv_
From: Kristian Høgsberg Kristensen
Since our surface state buffer is shared by all batches, the kernel does a
full stall and sync with the CPU between batches every time we call
execbuf2 because it refuses to do relocations on an active buffer. Doing
them in userspace and passing the NO_RELOC fl
On Mon, Oct 31, 2016 at 11:11 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Fixes GL45-CTS.geometry_shader.adjacency.adjacency_indiced_triangle_strip and
> others.
>
> This leaves the case of triangle strips with adjacency and primitive restarts
> open. It seems that the only thing that ca
On Wed, 2016-11-02 at 09:07 -0700, Eric Anholt wrote:
> Timothy Arceri writes:
>
> >
> > I'm about to do some refactoring that will move a bunch of glsl
> > only
> > fields from gl_linked_program into gl_program.
> >
> > If we wan't to share memory it makes sense to do it while I move
> > thing
Reviewed-by: Marek Olšák
Marek
On Wed, Nov 2, 2016 at 4:32 PM, Emil Velikov wrote:
> From: Emil Velikov
>
> The use of regparm causes an error on arm/arm64 builds with clang.
> fastcall is allowed, but still throws a warning. As both options only
> have effect on 32-bit x86 builds, limit them
On Wed, 2016-11-02 at 12:08 +0100, Marek Olšák wrote:
> On Wed, Nov 2, 2016 at 2:38 AM, Timothy Arceri
> wrote:
> >
> > I'm about to do some refactoring that will move a bunch of glsl
> > only
> > fields from gl_linked_program into gl_program.
> >
> > If we wan't to share memory it makes sense t
At link time, we resolve the size of implicitly sized arrays.
When doing so, we update the type of the ir_variables. However,
we neglected to update the type of ir_dereference nodes which
reference those variables.
It turns out array_resize_visitor (for GS/TCS/TES interface array
handling) alread
On Wed, Nov 2, 2016 at 3:02 PM, Nicolai Hähnle wrote:
> Patches 1, 2, 4 - 6:
>
> Reviewed-by: Nicolai Hähnle
Thanks.
>
> I have one pending LLVM patch related to indirect addressing. Not sure if
> that's related to the regressions, but it may be.
LLVM master fixes all but one regression. It's:
On Tue, Nov 1, 2016 at 2:25 PM, Francisco Jerez wrote:
> Assuming the hardware is set-up to use a screen coordinate system
> flipped vertically with respect to the GL's window coordinate system,
> the SYSTEM_VALUE_SAMPLE_POS vector will also be flipped vertically
> with respect to the value expect
For Windows. Otherwise, we don't see the message until the program exits.
---
src/gallium/auxiliary/hud/hud_context.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 3772f3c..ceb
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c
index 0d7ead3..03a3ff0 100644
--- a/src
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c
index 36534ba..
Hi,
Spotted when working on SM50 performance counters implementation (which is
almost ready). More performance metrics could be actually added but this
will require investigation because blob tries to obfuscate some signals
which makes the process harder than it seems.
Please review,
Thanks!
Sam
Event not_predicated_off_thread_inst_executed is SM35+.
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/nvc0/nvc0_query_hw_metric.c| 37 +-
.../drivers/nouveau/nvc0/nvc0_query_hw_metric.h| 1 +
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/src
Signed-off-by: Samuel Pitoiset
---
.../drivers/nouveau/nvc0/nvc0_query_hw_metric.c| 23 ++
.../drivers/nouveau/nvc0/nvc0_query_hw_metric.h| 1 +
2 files changed, 24 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c
b/src/gallium/driv
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c
index e5034f7..0d7ead3 100644
--- a/src/
Signed-off-by: Samuel Pitoiset
---
src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_query_hw_metric.c
index 6f02be3..
These were broken in e1af20f18a8 when the info field in nir_shader was
turned into a pointer.
Clone was copying the pointer rather than the data and nir_sweep was
cleaning up shader_info rather than claiming it.
Cc: Eric Anholt
---
src/compiler/nir/nir_clone.c | 2 +-
src/compiler/nir/nir_sweep
This will allow us to move some fields from gl_linked_shader to
gl_program, which will allow us to do some clean-ups like storing
gl_program directly in the CurrentProgram array in gl_pipeline_object
enabling some small validation optimisations at draw time.
Also it is error prone to depend on the
This will allow use to use ralloc_parent() on the info field and fix
a regression in nir_sweep() caused by e1af20f18a8.
This is intended to be a temporary requirement that will be removed
when we finish separating shader_info from nir_shader.
Cc: Eric Anholt
---
src/mesa/main/mtypes.h | 5 +++--
Series is Reviewed-by: Ilia Mirkin
On Wed, Nov 2, 2016 at 7:12 PM, Samuel Pitoiset
wrote:
> Hi,
>
> Spotted when working on SM50 performance counters implementation (which is
> almost ready). More performance metrics could be actually added but this
> will require investigation because blob trie
Reviewed-by: Charmaine Lee
From: Brian Paul
Sent: Wednesday, November 2, 2016 3:08 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee
Subject: [PATCH] gallium/hud: call fflush() after printing error messages
For Windows. Otherwise, we don't see th
On Wed, Nov 2, 2016 at 2:55 PM, Nicolai Hähnle wrote:
> On 29.10.2016 01:13, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> ---
>> src/compiler/glsl/ir_optimization.h | 3 ++-
>> src/compiler/glsl/lower_if_to_cond_assign.cpp | 23
>> ---
>> src/compiler/glsl/test
On Wed, Nov 2, 2016 at 6:55 PM, Marek Olšák wrote:
> On Wed, Nov 2, 2016 at 2:55 PM, Nicolai Hähnle wrote:
>> On 29.10.2016 01:13, Marek Olšák wrote:
>>>
>>> From: Marek Olšák
>>>
>>> ---
>>> src/compiler/glsl/ir_optimization.h | 3 ++-
>>> src/compiler/glsl/lower_if_to_cond_assign.c
Timothy Arceri writes:
> This will allow us to move some fields from gl_linked_shader to
> gl_program, which will allow us to do some clean-ups like storing
> gl_program directly in the CurrentProgram array in gl_pipeline_object
> enabling some small validation optimisations at draw time.
>
> Als
On Thu, Nov 3, 2016 at 12:01 AM, Ilia Mirkin wrote:
> On Wed, Nov 2, 2016 at 6:55 PM, Marek Olšák wrote:
>> On Wed, Nov 2, 2016 at 2:55 PM, Nicolai Hähnle wrote:
>>> On 29.10.2016 01:13, Marek Olšák wrote:
From: Marek Olšák
---
src/compiler/glsl/ir_optimization.h
On Wed, 2016-11-02 at 16:27 -0700, Eric Anholt wrote:
> Timothy Arceri writes:
>
> >
> > This will allow us to move some fields from gl_linked_shader to
> > gl_program, which will allow us to do some clean-ups like storing
> > gl_program directly in the CurrentProgram array in
> > gl_pipeline_ob
Such a surface is not possible on our hardware. Without this change, ISL
surface creation would fail with the next patch.
Signed-off-by: Nanley Chery
---
This series requires the following extra patch, seemingly due to the
recent changes with blorp.
src/intel/vulkan/anv_blorp.c | 16 +
---
src/intel/vulkan/gen8_cmd_buffer.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/src/intel/vulkan/gen8_cmd_buffer.c
b/src/intel/vulkan/gen8_cmd_buffer.c
index 0548a5e..5df2e50 100644
--- a/src/intel/vulkan/gen8_cmd_buffer.c
+++ b/src/intel/vulkan/gen8_cmd_
Our previous fence implementation was very simple. Fences had two states:
signaled and unsignaled. However, this didn't properly handle all of the
edge-cases that we need to handle. In order to handle the case where the
client calls vkGetFenceStatus on a fence that has not yet been submitted
via
---
src/intel/vulkan/anv_wsi.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/intel/vulkan/anv_wsi.c b/src/intel/vulkan/anv_wsi.c
index 064581d..72f79f1 100644
--- a/src/intel/vulkan/anv_wsi.c
+++ b/src/intel/vulkan/anv_wsi.c
@@ -323,13 +323,19 @@ VkResult anv
On Wed, 2016-11-02 at 14:28 -0700, Kenneth Graunke wrote:
> At link time, we resolve the size of implicitly sized arrays.
> When doing so, we update the type of the ir_variables. However,
> we neglected to update the type of ir_dereference nodes which
> reference those variables.
>
> It turns out
On Wed, 2016-11-02 at 14:47 +, Emil Velikov wrote:
> On 1 November 2016 at 23:47, Timothy Arceri
> wrote:
> >
> > This move the delete linked shaders call to
> > _mesa_clear_shader_program_data() which makes sure we delete them
> > before returning due to any validation problems.
> >
> > It
From: Roland Scheidegger
Previous fixes were incomplete - some code still iterated through the number
of elements provided by velem layout instead of the number stored in the key
(which is the same as the number defined by the vs). And also actually
accessed the elements from the layout directly
1 - 100 of 114 matches
Mail list logo
