On Monday, June 20, 2016 11:42:09 PM PDT Jason Ekstrand wrote:
> SPIR-V treats it as an input but NIR wants the system value. This
> shouldn't have been too much of a surprise given that we have to do the
> same conversion in the GLSL IR to NIR pass.
>
> Signed-off-by: Jason Ekstrand
> ---
> sr
SPIR-V treats it as an input but NIR wants the system value. This
shouldn't have been too much of a surprise given that we have to do the
same conversion in the GLSL IR to NIR pass.
Signed-off-by: Jason Ekstrand
---
src/compiler/spirv/vtn_variables.c | 4 ++--
1 file changed, 2 insertions(+), 2
On 21.06.2016 15:24, Axel Davy wrote:
> On 21/06/2016 01:26, Michel Dänzer wrote:
>> On 20.06.2016 20:06, Frank Binns wrote:
>>> On 20/06/16 10:48, Michel Dänzer wrote:
On 18.06.2016 02:41, Frank Binns wrote:
> Up until now, DRI3 was only used for devices that have render nodes,
> unle
On 21/06/2016 01:26, Michel Dänzer wrote:
On 20.06.2016 20:06, Frank Binns wrote:
On 20/06/16 10:48, Michel Dänzer wrote:
On 18.06.2016 02:41, Frank Binns wrote:
Up until now, DRI3 was only used for devices that have render nodes,
unless
overridden via an environment variable, with it falling
Rather than send 90+ patches to the list. Please see the repo at the
bottom of this email.
The big update is I've added all stages but compute and tested with a
few games and everything seems to be working well so far. Enabling
shader cache with the Shadow of Mordor benchmark make things noticeabl
On Friday, June 17, 2016 4:55:41 PM PDT Jason Ekstrand wrote:
> On Thu, Jun 16, 2016 at 10:08 AM, Chad Versace
> wrote:
>
> > On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > > Otherwise, we end up with a bogus value in the third component. On
> > gen6-7
> > > where we always use 2D textures, this
On Mon, Jun 20, 2016 at 4:49 PM, Chad Versace wrote:
> Emil, how do you test the Android build? I tried building i965 using
> vanilla AOSP, but that turned into a long journey in yak shaving.
Fun, isn't it. Here's cut-n-paste from my CI job that is tracks AOSP
and mesa master:
repo init -u https
We already store this in gl_shader and gl_program here we
remove it from gl_shader_program and just use the values
from gl_shader.
This will allow us to keep the shader cache restore code as
simple as it can be while making it somewhat clearer where these
values originate from.
---
src/compiler/g
On 21.06.2016 08:17, Vedran Miletić wrote:
> setLangDefaults() now requires PreprocessorOptions as an argument.
> ---
> src/gallium/state_trackers/clover/llvm/invocation.cpp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.
Reported-by: Grazvydas Ignotas
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96607
Signed-off-by: Jordan Justen
Cc: Kristian Høgsberg
Cc: "12.0"
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 15 ++-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 21 +
On Mon 20 Jun 2016, Jason Ekstrand wrote:
> On Mon, Jun 20, 2016 at 3:53 PM, Chad Versace
> wrote:
>
> > On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > > ---
> > > src/intel/isl/Makefile.am | 12
> > > src/intel/isl/Makefile.sources| 13 +++--
> > > src/intel/isl/isl.c
On Sat 11 Jun 2016, Jason Ekstrand wrote:
> ---
> src/intel/isl/isl.h | 6 ++
> src/intel/isl/isl_surface_state.c | 42
> ---
> 2 files changed, 45 insertions(+), 3 deletions(-)
>
> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> in
On Mon, Jun 20, 2016 at 4:46 PM, Chad Versace
wrote:
> On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > ---
> > src/intel/isl/isl.h | 3 +++
> > src/intel/isl/isl_surface_state.c | 9 +
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/src/intel/isl/isl.h b/src/intel/
On Sat 11 Jun 2016, Jason Ekstrand wrote:
> ---
> src/intel/isl/isl.h | 3 +++
> src/intel/isl/isl_surface_state.c | 9 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/src/intel/isl/isl.h b/src/intel/isl/isl.h
> index a987482..4dd4a2f 100644
> --- a/src/intel/isl/isl.
On Mon, Jun 20, 2016 at 3:53 PM, Chad Versace
wrote:
> On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > ---
> > src/intel/isl/Makefile.am | 12
> > src/intel/isl/Makefile.sources| 13 +++--
> > src/intel/isl/isl.c | 28 +++
> > src/intel/isl/is
On 20.06.2016 20:06, Frank Binns wrote:
> On 20/06/16 10:48, Michel Dänzer wrote:
>> On 18.06.2016 02:41, Frank Binns wrote:
>>> Up until now, DRI3 was only used for devices that have render nodes,
>>> unless
>>> overridden via an environment variable, with it falling back to DRI2
>>> otherwise.
>>
setLangDefaults() now requires PreprocessorOptions as an argument.
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocatio
On Sat 11 Jun 2016, Jason Ekstrand wrote:
> ---
> src/intel/isl/Makefile.am | 12
> src/intel/isl/Makefile.sources| 13 +++--
> src/intel/isl/isl.c | 28 +++
> src/intel/isl/isl_priv.h | 24
> src/intel/isl/isl_surfac
Hi,
I tested the optimized one with android-x86 before submitting the patch to
mesa-dev,
also re-tested several times in the last two days with mesa 12.0.0rc3
mesa 12 and later need some changes in drm_gralloc, expecially this one:
https://github.com/maurossi/hardware_drm_gralloc/commit/4d331710
On Mon, Jun 20, 2016 at 2:47 PM, Chad Versace
wrote:
> On Sat 18 Jun 2016, Jason Ekstrand wrote:
> > The docs specify that this only matters for render targets and surfaces
> > used with typed dataport messages. On some platforms (gen4-6) the Depth
> > field has more bits than RenderTargetViewEx
Emil, how do you test the Android build? I tried building i965 using
vanilla AOSP, but that turned into a long journey in yak shaving.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat 18 Jun 2016, Jason Ekstrand wrote:
> The docs specify that this only matters for render targets and surfaces
> used with typed dataport messages. On some platforms (gen4-6) the Depth
> field has more bits than RenderTargetViewExtent so we can have textures
> with more levels than we can ren
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Only adds the attribute mapping to the jitter; no implementation yet.
---
src/gallium/drivers/swr/rasterizer/core/knobs.h | 2 +-
src/gallium/drivers/swr/rasterizer/core/state.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/knobs.h
b/
---
.../drivers/swr/rasterizer/jitter/JitManager.cpp | 9 +--
.../drivers/swr/rasterizer/jitter/JitManager.h | 7 -
.../drivers/swr/rasterizer/jitter/blend_jit.cpp| 8 +-
.../drivers/swr/rasterizer/jitter/builder_misc.cpp | 31 +++---
.../drivers/swr/raster
---
src/gallium/drivers/swr/Makefile.sources | 1 +
src/gallium/drivers/swr/rasterizer/core/api.cpp| 13 +-
src/gallium/drivers/swr/rasterizer/core/clip.h | 4 +-
.../drivers/swr/rasterizer/core/conservativeRast.h | 120 +++
src/gallium/drivers/swr/rasterizer/cor
---
src/gallium/drivers/swr/rasterizer/common/isa.hpp | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/common/isa.hpp
b/src/gallium/drivers/swr/rasterizer/common/isa.hpp
index ef38179..a62350f 100644
--- a/src/gallium/drivers/sw
Function static destructors were getting called by exit
handlers before context teardown.
---
src/gallium/drivers/swr/rasterizer/core/api.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/api.cpp
b/src/gallium/drivers/swr/rasteriz
Add early-out if no components are enabled. Add asserts.
---
.../drivers/swr/rasterizer/jitter/fetch_jit.cpp| 27 ++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
b/src/gallium/drivers/swr/rasterizer/
Move drawIDs from 64-bit to 32-bit to increase perf.
---
src/gallium/drivers/swr/rasterizer/core/api.cpp| 4 +-
src/gallium/drivers/swr/rasterizer/core/context.h | 4 +-
.../drivers/swr/rasterizer/core/ringbuffer.h | 8 ++--
.../drivers/swr/rasterizer/core/threads.cpp| 54 +++
Handle SGV stores separate from the stream fetch code.
Because of this change, there is a potential to jit an extra unused store.
---
.../drivers/swr/rasterizer/jitter/fetch_jit.cpp| 170 +
1 file changed, 36 insertions(+), 134 deletions(-)
diff --git a/src/gallium/driver
So we can skip the index gather in PA.
---
src/gallium/drivers/swr/rasterizer/core/state.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/swr/rasterizer/core/state.h
b/src/gallium/drivers/swr/rasterizer/core/state.h
index 29048f1..bfa9929 100644
--- a/src/gallium/drive
Currently, most code paths between AVX2 and AVX512 are identical
(see changes to knobs.h).
---
src/gallium/drivers/swr/rasterizer/common/simdintrin.h | 4 ++--
src/gallium/drivers/swr/rasterizer/core/format_types.h | 8
src/gallium/drivers/swr/rasterizer/core/knobs.h | 15
Never be dependent on "draw 0", instead have a bool that makes the draw
dependent on the previous draw or not dependent at all.
---
src/gallium/drivers/swr/rasterizer/core/api.cpp | 6 +++---
src/gallium/drivers/swr/rasterizer/core/context.h| 4 ++--
src/gallium/drivers/swr/rasterizer/cor
v2:
add conservativeRast.h to Makefile.sources
minimize changes in llvm support cleanup
remove tabs that were added by the v1 patches
Tim Rowley (14):
swr: [rasterizer common] workaround clang for windows __cpuid() bug
swr: [rasterizer common] fix include for Intel comp
Was trying to store an extra uninitialized component.
Only affects component packing, which isn't enabled (yet).
---
src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp
---
src/gallium/drivers/swr/rasterizer/common/os.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/rasterizer/common/os.h
b/src/gallium/drivers/swr/rasterizer/common/os.h
index 370c619..45517f6 100644
--- a/src/gallium/drivers/swr/rasterizer/common/os.h
---
src/gallium/drivers/swr/rasterizer/core/frontend.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/frontend.cpp
b/src/gallium/drivers/swr/rasterizer/core/frontend.cpp
index 6e1bc0e..f86f8fa 100644
--- a/src/gallium/drivers/swr/rasterizer/core/front
On 21 June 2016 at 04:29, Ian Romanick wrote:
> I sent feedback for this patch the first time. :)
>
> https://lists.freedesktop.org/archives/mesa-dev/2016-June/119945.html
This reply for some reason isn't in my inbox at all. Not sure what ate it.
To address the comments in it:
Keeping the types
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Kai changed:
What|Removed |Added
Depends on||96602
Referenced Bugs:
https://bugs.freedesktop.
On Mon 20 Jun 2016, Jason Ekstrand wrote:
> On Mon, Jun 20, 2016 at 12:08 PM, Chad Versace
> wrote:
>
> > On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > > ---
> > > src/intel/genxml/genX_pack.h | 10 +-
> > > src/intel/genxml/gen_macros.h | 15 ++-
> > > 2 files changed, 23 i
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 92059, which changed state.
Bug 92059 Summary: [radeonsi, apitrace] Missing textures and geometry in
"Middle-earth: Shadow of Mordor"
https://bugs.freedesktop.org/show_bug.cgi?id=92059
What|Removed
On Mon, Jun 20, 2016 at 11:08 AM, Matt Turner wrote:
> On Sat, Jun 18, 2016 at 12:42 PM, Jason Ekstrand
> wrote:
> > While mathematically correct, these two optimizations result in an
> > expression with substantially lower precision than the original. For any
> > positive finite floating-point
On Mon 20 Jun 2016, Chad Versace wrote:
> On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > ---
> > src/intel/genxml/genX_pack.h | 10 +-
> > src/intel/genxml/gen_macros.h | 15 ++-
> > 2 files changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/intel/genxml/genX_p
On Mon, Jun 20, 2016 at 12:08 PM, Chad Versace
wrote:
> On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > ---
> > src/intel/genxml/genX_pack.h | 10 +-
> > src/intel/genxml/gen_macros.h | 15 ++-
> > 2 files changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/inte
On Sat 11 Jun 2016, Jason Ekstrand wrote:
> ---
> src/intel/genxml/genX_pack.h | 10 +-
> src/intel/genxml/gen_macros.h | 15 ++-
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/genxml/genX_pack.h b/src/intel/genxml/genX_pack.h
> index 7967c29..
On Sat 11 Jun 2016, Jason Ekstrand wrote:
> THe offset type has special implications that it's intended to be some form
> of aligned memory address. These assumptions allow it to handle the case
> where there is some alignment requirement on the offset and the bottom bits
> are used for other thin
Since there isn’t much code difference at this point, I was holding off on this
until we had made changes to how the different architecture swr builds are
built/linked to minimize build time and disk space.
-Tim
On Jun 20, 2016, at 9:27 AM, Chuck Atkins
mailto:chuck.atk...@kitware.com>> wrote:
Mathias Fröhlich writes:
> On Monday, June 20, 2016 10:33:42 Mark Janes wrote:
>> mathias.froehl...@gmx.net writes:
>>
>> > From: Mathias Fröhlich
>> >
>> > The use of a bitmask makes functions iterating only active
>> > attributes less visible in profiles.
>> >
>> > Signed-off-by: Mathias Fröh
I sent feedback for this patch the first time. :)
https://lists.freedesktop.org/archives/mesa-dev/2016-June/119945.html
On 06/19/2016 10:06 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This adds the builtins and the lexer support.
>
> To avoid too many warnings, it adds basic
> support to th
On Monday, June 20, 2016 10:33:42 Mark Janes wrote:
> mathias.froehl...@gmx.net writes:
>
> > From: Mathias Fröhlich
> >
> > The use of a bitmask makes functions iterating only active
> > attributes less visible in profiles.
> >
> > Signed-off-by: Mathias Fröhlich
> > ---
> > src/mesa/vbo/vbo_s
From: Marek Olšák
This reduces time spend in glGenerateMipmap by a half.
v2: don't decompress the levels to be overwritten
---
src/gallium/drivers/radeonsi/si_blit.c | 31 +++
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
2 files changed, 32 insertions(+), 1 deleti
Am 20.06.2016 um 17:39 schrieb Rob Herring:
On Mon, Jun 20, 2016 at 9:27 AM, Christian König
wrote:
Am 20.06.2016 um 16:13 schrieb Rob Herring:
On Mon, Jun 20, 2016 at 8:31 AM, Nicolai Hähnle
wrote:
On 17.06.2016 21:05, Rob Herring wrote:
On Fri, Jun 17, 2016 at 1:45 PM, Emil Velikov
wrote
On 06/17/2016 11:15 AM, Emil Velikov wrote:
> On 17 June 2016 at 18:20, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Khronos recommends that the GLES 3.1 library also be called libGLESv2.
>> It also requires that functions be statically linkable from that
>> library.
>>
>> NOTE: Mesa has suppo
On Sat, Jun 18, 2016 at 12:42 PM, Jason Ekstrand wrote:
> While mathematically correct, these two optimizations result in an
> expression with substantially lower precision than the original. For any
> positive finite floating-point value, log2(x) is well-defined and finite.
> More precisely, it
mathias.froehl...@gmx.net writes:
> From: Mathias Fröhlich
>
> The use of a bitmask makes functions iterating only active
> attributes less visible in profiles.
>
> Signed-off-by: Mathias Fröhlich
> ---
> src/mesa/vbo/vbo_save.h | 2 ++
> src/mesa/vbo/vbo_save_api.c | 70
> +
On Fri 17 Jun 2016, Jason Ekstrand wrote:
> On Thu, Jun 16, 2016 at 10:57 AM, Chad Versace
> wrote:
>
> > On Thu 16 Jun 2016, Jason Ekstrand wrote:
> > > On Thu, Jun 16, 2016 at 10:39 AM, Chad Versace
> > > wrote:
> > >
> > > > On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > > > > ---
> > > > > s
Ping
On Mon, Jun 13, 2016 at 6:27 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
> src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
> src/gallium/drivers/radeonsi/si_shader.c | 16
> 3 files changed, 18 inser
Patches 18 and 18 are:
Reviewed-by: Iago Toral Quiroga
On Mon, 2016-06-20 at 15:07 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Just add types into unsupported or double
> equivalent spots.
>
> Signed-off-by: Dave Airlie
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 2 ++
> s
On Mon, 2016-06-20 at 17:40 +1000, Timothy Arceri wrote:
> This is more consitent with what we do elsewhere and will allow
consistent
Reviewed-by: Iago Toral Quiroga
> us to only cache one of the values in the shader cache.
> ---
> src/mesa/drivers/dri/i965/brw_tcs.c | 5 ++---
>
Am 20.06.2016 um 07:07 schrieb Dave Airlie:
> From: Dave Airlie
>
> This just adds the basic support for 64-bit opcodes,
> and the new types.
>
> v2: add conversion opcodes.
> add documentation.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/auxiliary/tgsi/tgsi_info.c | 92 +-
On Fri, Jun 17, 2016 at 8:45 PM, Emil Velikov wrote:
> On 17 June 2016 at 18:45, Rob Herring wrote:
>> Now that the pipe-loader is reference counting the screen creation, it
>> is unnecessary to do in it the winsys/driver.
>>
>> Signed-off-by: Rob Herring
>> Cc: "Marek Olšák"
>> Cc: Ilia Mirkin
On Mon, Jun 20, 2016 at 9:27 AM, Christian König
wrote:
> Am 20.06.2016 um 16:13 schrieb Rob Herring:
>>
>> On Mon, Jun 20, 2016 at 8:31 AM, Nicolai Hähnle
>> wrote:
>>>
>>> On 17.06.2016 21:05, Rob Herring wrote:
On Fri, Jun 17, 2016 at 1:45 PM, Emil Velikov
wrote:
>
> On
On Mon, 2016-06-20 at 21:11 +1000, Timothy Arceri wrote:
> We will reuse this for fs key generation for the on disk shader
> cache.
> ---
> src/mesa/drivers/dri/i965/brw_vs.c | 72
> ++
> src/mesa/drivers/dri/i965/brw_vs.h | 4 +++
> 2 files changed, 45 insert
Am 20.06.2016 um 11:21 schrieb Jose Fonseca:
> On 19/06/16 03:06, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> Apparently, these are deprecated. There's some AutoUpgrade feature which
>> is supposed to promote these to cmp/select, which apparently doesn't work
>> with jit code. It i
Ah it's not a regression, in that case it might be possible to profile the
running benchmark to see where some bottlenecks lie, but from what ive read
on here before, this is difficult to set up and the results aren't always
useful.
As you're unaffected by this I doubt you'll be able to help furth
On Fri, Jun 17, 2016 at 7:15 PM, Francesco Ansanelli
wrote:
> Hi Erik,
> Thanks for your feedback.
> Can you suggest a better subject?
st/mesa: handle negative _ColorDrawBufferIndexes values correctly
> After some thinking, should I cast gl_buffer_index before calling the
> function?
No if ther
Reviewed-by: Marek Olšák
Marek
On Mon, Jun 20, 2016 at 9:44 AM, Christian Gmeiner
wrote:
> Signed-off-by: Christian Gmeiner
> ---
> src/mesa/state_tracker/st_extensions.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 17, 2016 at 8:10 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This yields a small performance improvement in Unigine Heaven.
> ---
> src/gallium/drivers/radeonsi/si_state.c | 22 +-
> src/gallium/d
On Mon, Jun 20, 2016 at 4:59 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote:
> Hello.
>
> The result file at
> http://openbenchmarking.org/result/1606180-PTS-MIDJUNEA78 is showing
> multiple issues, some of them are:
>
> [Minor issue] Kernel 4.7.0-999-generic (x86_64) 20160616 has a
> performance regressi
For patches 20-22, 27:
Reviewed-by: Marek Olšák
Marek
On Mon, Jun 20, 2016 at 7:07 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This passes all my current piglit tests except the variants on:
> fs-op-div-int64_t-i64vec3
>
> I'm guessing this is probably a backend bug.
>
> [rfc: this needs m
On Mon, 20 Jun 2016 09:45:26 -0400
Rob Clark wrote:
> On Mon, Jun 20, 2016 at 8:37 AM, Pekka Paalanen wrote:
> > On Fri, 17 Jun 2016 11:44:34 -0400
> > Rob Clark wrote:
> >
> >> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen
> >> wrote:
> >> > On Fri, 17 Jun 2016 08:26:04 -0400
> >> > Ro
Am 20.06.2016 um 16:13 schrieb Rob Herring:
On Mon, Jun 20, 2016 at 8:31 AM, Nicolai Hähnle wrote:
On 17.06.2016 21:05, Rob Herring wrote:
On Fri, Jun 17, 2016 at 1:45 PM, Emil Velikov
wrote:
On 17 June 2016 at 18:45, Rob Herring wrote:
Now that the pipe-loader is reference counting the sc
Doesn't this also need corresponding compiler flags in configure.ac to
populate SWR_AVX512_CXXFLAGS?
- Chuck
On Fri, Jun 17, 2016 at 3:25 PM, Tim Rowley
wrote:
> Currently, most code paths between AVX2 and AVX512 are identical
> (see changes to knobs.h).
> ---
> src/gallium/drivers/swr/rasteri
On 17 June 2016 at 21:35, Rob Herring wrote:
> On Fri, Jun 17, 2016 at 2:49 PM, Emil Velikov
> wrote:
>> On 17 June 2016 at 20:05, Rob Herring wrote:
>>> On Fri, Jun 17, 2016 at 1:45 PM, Emil Velikov
>>> wrote:
On 17 June 2016 at 18:45, Rob Herring wrote:
> Now that the pipe-loader
On Mon, Jun 20, 2016 at 8:31 AM, Nicolai Hähnle wrote:
> On 17.06.2016 21:05, Rob Herring wrote:
>>
>> On Fri, Jun 17, 2016 at 1:45 PM, Emil Velikov
>> wrote:
>>>
>>> On 17 June 2016 at 18:45, Rob Herring wrote:
Now that the pipe-loader is reference counting the screen creation, it
>>>
On Mon, Jun 20, 2016 at 3:36 PM, Nicolai Hähnle wrote:
> On 20.06.2016 11:59, wrote:
>>
>> Hello.
>>
>> The result file at
>> http://openbenchmarking.org/result/1606180-PTS-MIDJUNEA78 is showing
>> multiple issues, some of them are:
>>
>> [Minor issue] Kernel 4.7.0-999-generic (x86_64) 20160616 ha
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, Jun 17, 2016 at 4:09 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> It is the same for all SEs.
> ---
> src/gallium/drivers/radeonsi/si_state.c | 33
> +
> 1 file changed, 17 insertions(+), 16 delet
On Mon, Jun 20, 2016 at 8:37 AM, Pekka Paalanen wrote:
> On Fri, 17 Jun 2016 11:44:34 -0400
> Rob Clark wrote:
>
>> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen wrote:
>> > On Fri, 17 Jun 2016 08:26:04 -0400
>> > Rob Clark wrote:
>> >
>> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen
>
On 20.06.2016 15:34, Marek Olšák wrote:
On Fri, Jun 17, 2016 at 4:09 PM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
The old calculation treated too many RBs as disabled.
Do you know which chips are affected by patch 1 & 2?
No, I'm not too familiar with which chips have which harvesting
c
On 20.06.2016 11:59, ⚛ wrote:
Hello.
The result file at
http://openbenchmarking.org/result/1606180-PTS-MIDJUNEA78 is showing
multiple issues, some of them are:
[Minor issue] Kernel 4.7.0-999-generic (x86_64) 20160616 has a
performance regression on R9 290
[Major issue] R7 370 yields 133 FPS in
Reviewed-by: Nicolai Hähnle
On 20.06.2016 09:44, Christian Gmeiner wrote:
Signed-off-by: Christian Gmeiner
---
src/mesa/state_tracker/st_extensions.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_ext
On Fri, Jun 17, 2016 at 4:09 PM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> The old calculation treated too many RBs as disabled.
Do you know which chips are affected by patch 1 & 2?
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
For the series:
Reviewed-by: Marek Olšák
Marek
On Wed, Jun 15, 2016 at 10:38 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> ---
> src/mesa/state_tracker/st_cb_fbo.h| 2 +
> src/mesa/state_tracker/st_cb_readpixels.c | 122
> ++
> 2 files changed, 1
On 17.06.2016 21:05, Rob Herring wrote:
On Fri, Jun 17, 2016 at 1:45 PM, Emil Velikov wrote:
On 17 June 2016 at 18:45, Rob Herring wrote:
Now that the pipe-loader is reference counting the screen creation, it
is unnecessary to do in it the winsys/driver.
[...]
-static unsigned hash_dev(vo
Fixes a regression induced by commit a0674ce5c41903ccd161e89abb149621bfbc40d2:
When EGL_TEXTURE_FORMAT and EGL_TEXTURE_TARGET were both specified (and
both != EGL_NO_TEXTURE), an error was instantly triggered, before the
other one had even a chance to be checked, which is obviously not the
intended
Patches 1 (with ":1;" added), 2 (with the comment addressed), 5, 6, 7
(with the comment addressed) are:
Reviewed-by: Marek Olšák
Marek
On Tue, Jun 14, 2016 at 11:33 PM, Axel Davy wrote:
> Empirical tests show that the polygon offset
> behaviour is entirely determined by the content of
> the PA
We only use "r600g: " for all changes in drivers/r600.
Marek
On Tue, Jun 14, 2016 at 11:33 PM, Axel Davy wrote:
> Empirical tests show that the polygon offset
> behaviour is entirely determined by the content of
> the PA_SU_POLY_OFFSET states, and not by the depth buffer
> format bound.
>
> PA_S
Same here: The r600_init_atom call for polygon_offset_state should be
updated to account for the new register write (+3 dwords).
Marek
On Tue, Jun 14, 2016 at 11:33 PM, Axel Davy wrote:
> Emit PA_SU_POLY_OFFSET_DB_FMT_CNTL with the other poly_offset states.
> This will be useful to implement
> P
The r600_init_atom call for polygon_offset_state should be updated to
account for the new register write (+3 dwords).
Marek
On Tue, Jun 14, 2016 at 11:33 PM, Axel Davy wrote:
> Emit PA_SU_POLY_OFFSET_DB_FMT_CNTL with the other poly_offset states.
> This will be useful to implement
> PIPE_CAP_POL
The title is misleading to me. This would be better:
radeonsi: move PA_SU_POLY_OFFSET_DB_FMT_CNTL to poly offset states
Marek
On Tue, Jun 14, 2016 at 11:33 PM, Axel Davy wrote:
> Emit PA_SU_POLY_OFFSET_DB_FMT_CNTL with rasterizer poly_offset states.
> This will be useful to implement
> PIPE_CAP
On Fri, 17 Jun 2016 11:44:34 -0400
Rob Clark wrote:
> On Fri, Jun 17, 2016 at 9:31 AM, Pekka Paalanen wrote:
> > On Fri, 17 Jun 2016 08:26:04 -0400
> > Rob Clark wrote:
> >
> >> On Fri, Jun 17, 2016 at 3:59 AM, Pekka Paalanen
> >> wrote:
> >> > On Thu, 16 Jun 2016 10:40:51 -0400
> >> > Ro
We will reuse this for fs key generation for the on disk shader
cache.
---
src/mesa/drivers/dri/i965/brw_vs.c | 72 ++
src/mesa/drivers/dri/i965/brw_vs.h | 4 +++
2 files changed, 45 insertions(+), 31 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs.
Le 20/06/2016 11:48, Michel Dänzer a écrit :
On 18.06.2016 02:41, Frank Binns wrote:
Up until now, DRI3 was only used for devices that have render nodes, unless
overridden via an environment variable, with it falling back to DRI2 otherwise.
This limitation was there in order to support WL_bind_w
On 20/06/16 10:48, Michel Dänzer wrote:
On 18.06.2016 02:41, Frank Binns wrote:
Up until now, DRI3 was only used for devices that have render nodes, unless
overridden via an environment variable, with it falling back to DRI2 otherwise.
This limitation was there in order to support WL_bind_waylan
Hi,
The three patches make sense to me.
Reviewed-by: Axel Davy
On 17/06/2016 19:41, Frank Binns wrote :
Up until now, DRI3 was only used for devices that have render nodes, unless
overridden via an environment variable, with it falling back to DRI2 otherwise.
This limitation was there in orde
On Fri, Jun 17, 2016 at 06:29:40PM +0100, Frank Binns wrote:
> When trying to get a device name for an fd using sysfs, it would always fail
> as it was expecting key/value pairs to be delimited by '\0', which is not the
> case.
>
> Signed-off-by: Frank Binns
For both patches:
Reviewed-by: Eric E
Hello.
The result file at
http://openbenchmarking.org/result/1606180-PTS-MIDJUNEA78 is showing
multiple issues, some of them are:
[Minor issue] Kernel 4.7.0-999-generic (x86_64) 20160616 has a
performance regression on R9 290
[Major issue] R7 370 yields 133 FPS in Tesseract, while R9 285
unexpec
On 18.06.2016 02:41, Frank Binns wrote:
> Up until now, DRI3 was only used for devices that have render nodes, unless
> overridden via an environment variable, with it falling back to DRI2
> otherwise.
> This limitation was there in order to support WL_bind_wayland_display as it
> requires client
1 - 100 of 107 matches
Mail list logo
