On Wed, Sep 21, 2016 at 11:49 AM, Jason Ekstrand wrote:
> This seems odd... When can it even happen that we have persample_dispatch
> set in wm_surface_state and have only one sample? Does this fix a test
> case?
>
No, It just fixes a simulator warning. It's recommended in graphics spec
for gen7.
Hi Ian,
I just sent out a four patch series that I think will accomplish a lot
of what you were trying to do with the "do post-link optimizations, but
only for built-ins" patches. But it deletes code.
https://lists.freedesktop.org/archives/mesa-dev/2016-September/129437.html
I'd been playing wi
This is now handled directly by ast_function.cpp.
Signed-off-by: Kenneth Graunke
---
src/compiler/glsl/builtin_functions.cpp | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/src/compiler/glsl/builtin_functions.cpp
b/src/compiler/glsl/builtin_fu
Now that we generate built-in functions inline, there's no need to link
against the built-in shader, and no built-in prototypes to consider.
This lets us delete a bunch of code.
Signed-off-by: Kenneth Graunke
---
src/compiler/glsl/link_functions.cpp | 32 +++
src/compile
We want to check prior to optimization - otherwise we might fail to
detect cases where barrier() is in control flow which is always taken
(and therefore gets optimized away).
We don't currently loop unroll if there are function calls inside;
otherwise we might have a problem detecting barrier() in
In the past, we imported the prototypes of built-in functions, generated
calls to those, and waited until link time to resolve the calls and
import the actual code for the built-in functions.
This severely limited our compile-time optimization opportunities: even
trivial functions like dot() were
Hello,
This series reworks the GLSL compiler to inline built-in functions
immediately, at compile time, rather than importing prototypes and
linking against an extra shader later on.
Without this, compile time optimizations are nearly useless. For example,
trying to use a dot product would gener
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #9 from Tobias Droste ---
Ah should have mentioned it:
This is with radeon+radeonsi (no amdpgu) so it's probably not the kernel.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #8 from Tobias Droste ---
On the first screenshot you can clearly see the FPS going down to 0 multiple
times.
Though looking at the graph only the first 2 drops could be explained by shader
compiles if I interpret this correctly. I c
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #7 from Tobias Droste ---
Created attachment 126717
--> https://bugs.freedesktop.org/attachment.cgi?id=126717&action=edit
Screenshot with GALLIUM_HUD of the first 2min30s of the game (good)
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #6 from Tobias Droste ---
Created attachment 126716
--> https://bugs.freedesktop.org/attachment.cgi?id=126716&action=edit
Screenshot with GALLIUM_HUD of the first 1min30s of the game (good)
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #5 from Tobias Droste ---
Created attachment 126715
--> https://bugs.freedesktop.org/attachment.cgi?id=126715&action=edit
Screenshot with GALLIUM_HUD of the first 10s of the game (bad)
--
You are receiving this mail because:
You a
Commit 5921f372c89a68fac6ddefc009442721d9df4db2 exposed GLES 3.1 symbols
in libGLESv2.so. Are we supposed to do the same thing for GLES 3.2?
I imagine we're supposed to, but I'm not certain what spec actually
defines the ABI or where to look.
signature.asc
Description: This is a digitally signe
Build mesa 2238 failed
Commit 6c648cdac8 by Kenneth Graunke on 9/21/2016 6:51 PM:
docs: Mark ES 3.2 "all done" for i965/gen9+.
Configure your notification preferences
___
mesa-dev mailing list
mesa-dev@list
On 21/09/16 16:25, Brian Paul wrote:
From reading the code, it's not obvious what is src/dest compatible.
The list of a->b copy-compatible formats comes from Jose's original
check-in message, with some format name updates.
---
src/gallium/auxiliary/util/u_format.c | 24
This seems odd... When can it even happen that we have persample_dispatch
set in wm_surface_state and have only one sample? Does this fix a test
case?
On Sep 21, 2016 9:14 PM, "Anuj Phogat" wrote:
> Signed-off-by: Anuj Phogat
> ---
> src/intel/vulkan/gen7_pipeline.c | 3 ++-
> 1 file changed,
The genxml packing structs will assert this for you. I'm guessing it did
and you found it rather obtuse. :-)
Rb
On Sep 21, 2016 9:16 PM, "Anuj Phogat" wrote:
> Signed-off-by: Anuj Phogat
> ---
> src/intel/isl/isl_surface_state.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/
For the series, Reviewed-by: Charmaine Lee
From: Brian Paul
Sent: Wednesday, September 21, 2016 8:25 AM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee
Subject: [PATCH 2/2] svga: minor simplification in svga_validate_surface_view()
Get rid of unnee
Signed-off-by: Anuj Phogat
---
src/intel/vulkan/anv_blorp.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/intel/vulkan/anv_blorp.c b/src/intel/vulkan/anv_blorp.c
index cb61070..de33dce 100644
--- a/src/intel/vulkan/anv_blorp.c
+++ b/src/intel/vulkan/anv_blorp.c
@@ -273,6 +273,10 @@
Signed-off-by: Anuj Phogat
---
src/intel/isl/isl_surface_state.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/intel/isl/isl_surface_state.c
b/src/intel/isl/isl_surface_state.c
index 1a1a819..b20f767 100644
--- a/src/intel/isl/isl_surface_state.c
+++ b/src/intel/isl/isl_surface_stat
Signed-off-by: Anuj Phogat
---
This patch requires below series:
https://patchwork.freedesktop.org/series/12594/
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_ex
Signed-off-by: Anuj Phogat
---
src/intel/vulkan/gen7_pipeline.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c
index 878308b..5150ef9 100644
--- a/src/intel/vulkan/gen7_pipeline.c
+++ b/src/intel/vulkan/gen
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #4 from Andreas Hartmetz ---
I have the same problem. Assuming the problem was shader compilation, what
could be done about it, though? Optimizing shader compilation by a factor of 10
seems unrealistic, a disk cache for shaders has be
Hi Andy,
On Wed, Sep 21, 2016 at 9:30 PM, Andy Furniss wrote:
> Andy Furniss wrote:
>
>> Andy Furniss wrote:
>>
>>> Andy Furniss wrote:
>>>
Andy Furniss wrote:
bz2 compressed vid showing the issue -
>
> https://drive.google.com/open?id=0BxP5-S1t9VEEUE5sbUFBV20zSms
>
Am 21.09.2016 um 17:25 schrieb Brian Paul:
> From reading the code, it's not obvious what is src/dest compatible.
> The list of a->b copy-compatible formats comes from Jose's original
> check-in message, with some format name updates.
> ---
> src/gallium/auxiliary/util/u_format.c | 24
Andy Furniss wrote:
Andy Furniss wrote:
Andy Furniss wrote:
Andy Furniss wrote:
bz2 compressed vid showing the issue -
https://drive.google.com/open?id=0BxP5-S1t9VEEUE5sbUFBV20zSms
To be clear this is just the test rez vid I used so you can
possibly recreate the issue your self.
Hmm, int
Reviewed-by: Nicolai Hähnle
On 21.09.2016 17:25, Brian Paul wrote:
From reading the code, it's not obvious what is src/dest compatible.
The list of a->b copy-compatible formats comes from Jose's original
check-in message, with some format name updates.
---
src/gallium/auxiliary/util/u_format.c
From reading the code, it's not obvious what is src/dest compatible.
The list of a->b copy-compatible formats comes from Jose's original
check-in message, with some format name updates.
---
src/gallium/auxiliary/util/u_format.c | 24
1 file changed, 24 insertions(+)
diff
Never used, AFAIK.
---
src/gallium/drivers/svga/svga_context.c | 2 --
src/gallium/drivers/svga/svga_context.h | 2 --
src/gallium/drivers/svga/svga_pipe_draw.c | 6 --
3 files changed, 10 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_context.c
b/src/gallium/drivers/svga/svga_c
Get rid of unneeded local var.
---
src/gallium/drivers/svga/svga_surface.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_surface.c
b/src/gallium/drivers/svga/svga_surface.c
index 42636bc..7cc7ef1 100644
--- a/src/gallium/drivers/svga/svga_s
On 09/21/2016 08:14 AM, Randall Frank wrote:
Hello,
I have been working around an issue with the OSMesa interface a bit
and was curious if others see this as a bug. An example that triggers
the issue is:
#include
#include
#include
#include
int main(int iargs, const char *argv[])
{
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #3 from Michel Dänzer ---
(In reply to Silvan Jegen from comment #2)
> Just to clarify: the trace also includes loading of the game itself (which
> takes a long time too) as well as in-game menu navigation.
Right, replaying the trace
Andy Furniss wrote:
Andy Furniss wrote:
Andy Furniss wrote:
bz2 compressed vid showing the issue -
https://drive.google.com/open?id=0BxP5-S1t9VEEUE5sbUFBV20zSms
To be clear this is just the test rez vid I used so you can
possibly recreate the issue your self.
Hmm, interesting, with bicubi
Hello,
I have been working around an issue with the OSMesa interface a bit
and was curious if others see this as a bug. An example that triggers
the issue is:
#include
#include
#include
#include
int main(int iargs, const char *argv[])
{
void *pBuf0Ptr, *pBuf1Ptr, *pBuf2Ptr;
GL
Signed-off-by: Adam Jackson
---
src/mesa/drivers/dri/i915/intel_screen.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i915/intel_screen.c
b/src/mesa/drivers/dri/i915/intel_screen.c
index 19f7a6a..a78e250 100644
--- a/src/mesa/drivers/dri/i915/intel_screen.c
+++ b/s
Signed-off-by: Adam Jackson
---
src/mesa/drivers/dri/i965/intel_screen.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 82d4203..63b02530 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/
This extension is a prerequisite for EGL 1.5, but the Intel drivers don't
report support for it, and I'm not really sure why, the driver code certainly
looks prepared for it. That said, I haven't tested either of these patches, and
I'm not aware of any apps using the feature (certainly nothing in p
On Wed, Sep 21, 2016 at 4:58 AM, Matt Turner wrote:
> On Fri, Sep 16, 2016 at 6:59 AM, Jason Ekstrand
> wrote:
> > This was something that I wrote in the early days of the spirv_to_nir
> code
> > but deleted once we had a real driver. However, in the absence of a
> > shader_runner equivalent, i
On 20 September 2016 at 09:32, Weng, Chuanbo wrote:
> Hi Emil,
> What you mentioned about style issue in last round is:
> Please move the variable declaration in local scope and add
> space between ){
> I think I have fixed these issue in this version. Maybe I have
On Fri, Sep 16, 2016 at 6:59 AM, Jason Ekstrand wrote:
> This was something that I wrote in the early days of the spirv_to_nir code
> but deleted once we had a real driver. However, in the absence of a
> shader_runner equivalent, it's extremely useful for debugging the
> spirv_to_nir code so let'
You can use the GALLIUM_HUD environment variable to find out the cause
of those hiccups. Just set it before running steam. Type
"GALLIUM_HUD=help glxgears" - that should print the available options.
From the top of my head, the useful graphs are:
- num-evictions (TTM overhead as the number of buff
https://bugs.freedesktop.org/show_bug.cgi?id=97879
Frederic Romagne changed:
What|Removed |Added
CC||frederic.roma...@gmail.com
--
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=97879
Vedran Miletić changed:
What|Removed |Added
CC||ved...@miletic.net
--
You are receivin
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #2 from Silvan Jegen ---
(In reply to Michel Dänzer from comment #1)
> Looks like most of the cycles at the start of the apitrace are spent in the
> GLSL compiler frontend, in particular in do_common_optimization.
Just to clarify: th
Reviewed-by: Ian Romanick
On 09/10/2016 12:43 AM, Eric Anholt wrote:
> VC4 was running into a major performance regression from enabling control
> flow in the glmark2 conditionals test, because of short if statements
> containing an ffract.
>
> This pass seems like it was was trying to ensure th
Gentle ping to Eric ..
On 09/16/2016 06:21 PM, Tapani Pälli wrote:
Changes make copy_propagation_elements pass faster, reducing link
time spent in test case of bug 94477. Does not fix the actual issue
but brings down the total time. No regressions seen in CI.
Signed-off-by: Tapani Pälli
---
F
46 matches
Mail list logo
