ffs() just returns the bit that is set, we need to know what
stage that bit represents so use u_bit_scan() instead.
Fixes: 2ca5d9548fc4 ("st/glsl_to_nir: gather next_stage in shader_info")
---
src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
To have uniform behavior while disassembling send(c) instruction use
register type of unsigned doubleword for src1 when message descriptor is
immediate value. Bspec does not specifiy anything for src1 immediate
default type.
Signed-off-by: Sagar Ghuge
---
src/intel/compiler/brw_eu_emit.c
https://bugs.freedesktop.org/show_bug.cgi?id=107457
Bug 107457 depends on bug 107510, which changed state.
Bug 107510 Summary: [GEN8+] up to 10% perf drop on several 3D benchmarks
https://bugs.freedesktop.org/show_bug.cgi?id=107510
What|Removed |Added
--
On Fri, Oct 19, 2018 at 11:09 PM Marek Olšák wrote:
>
> On Thu, Oct 18, 2018 at 10:13 AM Connor Abbott wrote:
>>
>> And implement ac_bulid_expand_to_vec4() on top of it.
>>
>> Fixes: 7e7ee82698247d8f93fe37775b99f4838b0247dd ("ac: add support for 16bit
>> buffer loads")
>> ---
>> src/amd/common/
On Mon, Oct 15, 2018 at 6:35 PM Kenneth Graunke
wrote:
> From: Jason Ekstrand
>
> They're not required to be the same as the access flag on the image
> unit. For hardware that does shader image lowering based on the
> qualifier (Intel), it may be required for state setup.
> ---
> src/gallium/i
For the series:
Reviewed-by: Marek Olšák
Marek
On Sun, Oct 14, 2018 at 8:48 PM Dave Airlie wrote:
> From: Dave Airlie
>
> The drawpixel lowering references undeclared samplers, but also
> missing a texture handle.
> ---
> src/compiler/nir/nir_lower_drawpixels.c | 20
>
> Jose, does it make more sense to just make gles on windows an error
in meson?
I don't mind if there are options for other things, but the default for
the unsuspicious user should be to create a single self-contained
opengl32.dll, as that is what's generally most useful (it can be used
with
Reviewed-by: Marek Olšák
Marek
On Thu, Oct 18, 2018 at 10:13 AM Connor Abbott wrote:
> The comment was wrong, since the loop above casts to a type with the
> correct bitsize already.
>
> Fixes: 7e7ee82698247d8f93fe37775b99f4838b0247dd ("ac: add support for
> 16bit buffer loads")
> ---
> src/a
On Thu, Oct 18, 2018 at 10:13 AM Connor Abbott wrote:
> And implement ac_bulid_expand_to_vec4() on top of it.
>
> Fixes: 7e7ee82698247d8f93fe37775b99f4838b0247dd ("ac: add support for
> 16bit buffer loads")
> ---
> src/amd/common/ac_llvm_build.c | 40 ++
> src/amd
Trivial.
---
src/amd/vulkan/radv_debug.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/amd/vulkan/radv_debug.c b/src/amd/vulkan/radv_debug.c
index 08fc80c12ab..e81b9cccb57 100644
--- a/src/amd/vulkan/radv_debug.c
+++ b/src/amd/vulkan/radv_debug.c
@@ -320,11 +320,11
Pushed, thanks!
Marek
On Fri, Oct 19, 2018 at 3:56 PM Jiang, Sonny wrote:
> Signed-off-by: Sonny Jiang
> Tested-by: Michel Dänzer
> ---
> src/gallium/drivers/radeonsi/si_pipe.c | 6 --
> src/gallium/drivers/radeonsi/si_state.c | 5 +++--
> 2 files changed, 7 insertions(+), 4 deletions(-
Signed-off-by: Sonny Jiang
Tested-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/si_pipe.c | 6 --
src/gallium/drivers/radeonsi/si_state.c | 5 +++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_
Quoting Kenneth Graunke (2018-10-19 18:51:36)
> Usually when making a new file, people copy some random other file
> to get the copyright header comments. Unfortunately, some of them
> are commented in a decades-old style, are word wrapped poorly, or
> worse, have a few subtle variations in the te
Signed-off-by: Sonny Jiang
Tested-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/si_pipe.c | 6 --
src/gallium/drivers/radeonsi/si_state.c | 5 +++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_
On Fri, Oct 19, 2018 at 10:51:36AM -0700, Kenneth Graunke wrote:
> Usually when making a new file, people copy some random other file
> to get the copyright header comments. Unfortunately, some of them
> are commented in a decades-old style, are word wrapped poorly, or
> worse, have a few subtle v
On Fri, Oct 19, 2018 at 12:45 PM Gert Wollny wrote:
>
> Am Freitag, den 19.10.2018, 08:25 -0400 schrieb Ilia Mirkin:
> > I don't think a PIPE_CAP is the answer here... I think you're on the
> > right track with format checks and whatnot.
>
> The problem is that with an GLES host, the checked sRGB
Sounds like a good idea to me.
Acked-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Friday, October 19, 2018 10:17:29 AM PDT Matt Turner wrote:
> On Thu, Oct 18, 2018 at 6:06 PM Kenneth Graunke wrote:
> >
> > This warning detects non-void functions with a missing return statement,
> > return statements with a value in void functions, and functions with an
> > bogus return type
https://bugs.freedesktop.org/show_bug.cgi?id=108491
--- Comment #7 from Karl ---
Thanks for the quick fix
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev mailing list
mesa-dev@l
Usually when making a new file, people copy some random other file
to get the copyright header comments. Unfortunately, some of them
are commented in a decades-old style, are word wrapped poorly, or
worse, have a few subtle variations in the text. While we've tried
to clean those up, we're not go
Fixes: 2f52925f5c60c72c9389bfdc122c3d5f8e15b25f
"nv50/ir: move a * b -> a << log2(b) code into createMul()"
Reviewed-by: Rhys Perry
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
On Thu, Oct 18, 2018 at 6:06 PM Kenneth Graunke wrote:
>
> This warning detects non-void functions with a missing return statement,
> return statements with a value in void functions, and functions with an
> bogus return type that ends up defaulting to int. It's already enabled
> by default with
That's not quite right. GLES needs shared glapi, but shared glapi doesn't need
gles. meson and autoconf have separate toggles for shared-glapi and gles, they
both happen to default to "on" currently.
If you want to uses GLES with mesa on Windows your best bet is probably to use
ARB_ES_compatibilit
On 10/19/2018 12:49 PM, Michel Dänzer wrote:
> On 2018-10-19 6:41 p.m., Nicholas Kazlauskas wrote:
>> The DDX driver can be notified of adaptive sync suitability by
>> flagging the application's window with the _VARIABLE_REFRESH property.
>>
>> This property is set on the first swap the application
Mesa 18.2.3 is now available.
In this release we have:
Different patches for the DirectX9 and DRI state trackers.
Several fixes and workarounds for different games, inlcuding RAGE, Yakuza and
The Evil Within, Wolfenstein The Old Blood ARMA 3, or No Mans Sky.
A bunch of fixes for different driv
On 2018-10-19 6:41 p.m., Nicholas Kazlauskas wrote:
> The DDX driver can be notified of adaptive sync suitability by
> flagging the application's window with the _VARIABLE_REFRESH property.
>
> This property is set on the first swap the application performs
> when adaptive_sync is set to true in t
Am Freitag, den 19.10.2018, 08:25 -0400 schrieb Ilia Mirkin:
> I don't think a PIPE_CAP is the answer here... I think you're on the
> right track with format checks and whatnot.
The problem is that with an GLES host, the checked sRGB format might be
supported by virgl, but not EXT_sRGB_write_contr
It's better to let most applications make use of adaptive sync
by default. Problematic applications can be placed on the blacklist
or the user can manually disable the feature.
Signed-off-by: Nicholas Kazlauskas
---
src/gallium/drivers/radeonsi/driinfo_radeonsi.h | 4
1 file changed, 4 inse
The DDX driver can be notified of adaptive sync suitability by
flagging the application's window with the _VARIABLE_REFRESH property.
This property is set on the first swap the application performs
when adaptive_sync is set to true in the drirc.
It's performed here instead of when the loader is i
Applications that don't present at a predictable rate (ie. not games)
shouldn't have adapative sync enabled. This list covers some of the
common desktop compositors, web browsers and video players.
Signed-off-by: Nicholas Kazlauskas
---
src/util/00-mesa-defaults.conf | 82 +++
Some programs start with the path and command line arguments in
argv[0] (program_invocation_name). Chromium is an example of
an application using mesa that does this.
This tries to query the real path for the symbolic link /proc/self/exe
to find the program name instead. It only uses the realpath
This option lets the user decide whether mesa should notify the
window manager / DDX driver that the current application is adaptive
sync capable.
It's off by default.
Signed-off-by: Nicholas Kazlauskas
---
src/util/xmlpool/t_options.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/sr
These patches are part of a proposed new interface for supporting variable
refresh rate via DRM properties.
It adds a new option for supporting adaptive sync to drirc along with the
implementation of notifying the window manager/DDX of the support via a window
property.
The option is enabled b
On 2018-10-19 4:45 p.m., Jiang, Sonny wrote:
> Signed-off-by: Sonny Jiang
Something like
radeonsi: Disable clear state with radeon kernel driver
might be a better shortlog. Also, please add
Fixes: f243980f2c1e "radeonsi:optimizing SET_CONTEXT_REG for shaders VS"
to the commit log.
> diff --
SCons never had parity with autoconf. It never gained enough traction
to replace autoconf, so it become this thing which is mostly use by
VMware and others who care about Windows.
Maybe one day meson will replace SCons. But I certainly have no plans
to have scons replace anything anymore.
Looks alright to me, if it's broken anyway.
Reviewed-by: Roland Scheidegger
Am 19.10.18 um 14:33 schrieb Jose Fonseca:
> It's broken, and WGL state tracker is always built with GLES support
> noawadays.
> ---
> common.py| 2 --
> src/SConscript
On Friday, October 19, 2018, 6:04:28 PM GMT+3, Liviu Prodea
wrote:
I think I found autotools build equivalent for gles=y. It is
--enable-shared-glapi. And the docs say it is needed to support applications
that mix OpenGL and OpenGL ES:
https://www.mesa3d.org/egl.html
and Meson
I think I found autotools build equivalent for gles=y. It is
--enable-shared-glapi. And the docs say it is needed to support applications
that mix OpenGL and OpenGL ES:
https://www.mesa3d.org/egl.html
---
Signed-off-by: Sonny Jiang
---
src/gallium/drivers/radeonsi/si_pipe.c | 6 --
src/gallium/drivers/radeonsi/si_state.c | 5 +++--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 9d25748df4..a
https://bugs.freedesktop.org/show_bug.cgi?id=108498
--- Comment #3 from cla...@mathr.co.uk ---
Created attachment 142096
--> https://bugs.freedesktop.org/attachment.cgi?id=142096&action=edit
processed fragment shader than glslangValidator doesn't complain about
--
You are receiving this mail b
https://bugs.freedesktop.org/show_bug.cgi?id=108498
--- Comment #2 from cla...@mathr.co.uk ---
I managed to use glslangValidator to debug the issue. The cause was
referencing a non-existent "position" field in struct Ray (the V variable in
those functions). Replacing it with the correct field nam
Reviewed-by: Lionel Landwerlin
On 15/10/2018 04:47, Jason Ekstrand wrote:
Instead of having weak references to the anv functions and separate
trampoline functions with their own dispatch table, just make the
trampoline functions weak. This gets rid of a dispatch table and
potentially lets the
https://bugs.freedesktop.org/show_bug.cgi?id=108498
Danylo changed:
What|Removed |Added
CC||danylo.pilia...@gmail.com
--- Comment #1 from
https://bugs.freedesktop.org/show_bug.cgi?id=108498
Michel Dänzer changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes
Reviewed-by: Brian Paul
On 10/19/2018 06:33 AM, Jose Fonseca wrote:
> It's broken, and WGL state tracker is always built with GLES support
> noawadays.
> ---
> common.py| 2 --
> src/SConscript | 7 ---
> src/gallium/state_
Rb
On October 19, 2018 04:54:14 Bas Nieuwenhuizen wrote:
Trying to access the bus info before it is initialized is not going
to work.
Fixes: baa38c144f6 "vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108491
---
src/amd/vulkan/r
https://bugs.freedesktop.org/show_bug.cgi?id=108491
Bas Nieuwenhuizen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
It's broken, and WGL state tracker is always built with GLES support
noawadays.
---
common.py| 2 --
src/SConscript | 7 ---
src/gallium/state_trackers/osmesa/SConscript | 4 +---
src/gallium/state_trackers/wgl/SConscript| 4
I don't think a PIPE_CAP is the answer here... I think you're on the
right track with format checks and whatnot.
On Fri, Oct 19, 2018 at 2:54 AM Gert Wollny wrote:
>
> Considering how virgl has to deal with host capabilities the extension
> should be enabled via a CAP, so I'll rework this patch an
On Fri, Oct 19, 2018 at 6:32 AM Gert Wollny wrote:
>
> Am Donnerstag, den 06.09.2018, 22:36 -0400 schrieb Ilia Mirkin:
> > Not handling caps explicitly means that we're likely getting
> > incorrect values -- these need to be reviewed and set appropriately.
> >
> > While we're at it, add in some mi
Am Donnerstag, den 06.09.2018, 22:36 -0400 schrieb Ilia Mirkin:
> Not handling caps explicitly means that we're likely getting
> incorrect values -- these need to be reviewed and set appropriately.
>
> While we're at it, add in some missing caps, and set all the subpixel
> stuff to 8 as that seems
Hi,
On 19/10/2018 11:53, Bas Nieuwenhuizen wrote:
Trying to access the bus info before it is initialized is not going
to work.
Fixes: baa38c144f6 "vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108491
confirmed, fixes the issue
On Thursday, October 11, 2018 12:12:38 PM PDT Kenneth Graunke wrote:
> On Thursday, October 11, 2018 11:58:40 AM PDT Kenneth Graunke wrote:
> > On Tuesday, October 2, 2018 9:16:01 AM PDT asimiklit.w...@gmail.com wrote:
> > > From: Andrii Simiklit
> > >
> > > I guess that when we calculating the w
Reviewed-by: Samuel Pitoiset
On 10/19/18 11:53 AM, Bas Nieuwenhuizen wrote:
Trying to access the bus info before it is initialized is not going
to work.
Fixes: baa38c144f6 "vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108491
--
On Thursday, 2018-10-18 18:05:13 -0700, Kenneth Graunke wrote:
> This warning detects non-void functions with a missing return statement,
> return statements with a value in void functions, and functions with an
> bogus return type that ends up defaulting to int. It's already enabled
> by default
https://bugs.freedesktop.org/show_bug.cgi?id=108491
--- Comment #5 from Bas Nieuwenhuizen ---
Okay it looks like this fails for radv, because the wsi gets initialized before
the PCI bus info.
This should be fixed by
https://lists.freedesktop.org/archives/mesa-dev/2018-October/207311.html
(sor
Trying to access the bus info before it is initialized is not going
to work.
Fixes: baa38c144f6 "vulkan/wsi: Use VK_EXT_pci_bus_info for DRM fd matching"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108491
---
src/amd/vulkan/radv_device.c | 13 +
1 file changed, 9 insertions
https://bugs.freedesktop.org/show_bug.cgi?id=108491
--- Comment #4 from Andre Heider ---
Not here, just one gpu and one display
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev m
Hi,
On 18/10/2018 17:13, Jason Ekstrand wrote:
This lets us avoid passing the DRM fd around all over the place and gets
us closer to layer utopia.
---
src/amd/vulkan/radv_wsi.c | 3 --
src/amd/vulkan/radv_wsi_x11.c | 4 +--
src/intel/vulkan/anv_wsi.c | 4 +--
src
https://bugs.freedesktop.org/show_bug.cgi?id=108491
--- Comment #3 from Bas Nieuwenhuizen ---
Are any of you using a different GPU to display vs running the game? (e.g.
prime)
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=108491
--- Comment #2 from Andre Heider ---
Same here with wine/dxvk/radv on tonga.
The fps seems unaffected, but it looks like every n'th displayed frame is an
older one.
Reverting the commit on master fixes the issue.
--
You are receiving this ma
https://bugs.freedesktop.org/show_bug.cgi?id=108491
Bug ID: 108491
Summary: Commit baa38c14 causes output issues on my VEGA with
RADV
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NE
https://bugs.freedesktop.org/show_bug.cgi?id=108491
--- Comment #1 from Karl ---
Created attachment 142090
--> https://bugs.freedesktop.org/attachment.cgi?id=142090&action=edit
DXVK
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.__
I agree on the fact it is suspicious that libglapi,dll was asked for
considering glapi is built as a static library part of opengl32.dll by default.
If I understood correctly what gles variable does, it turns glapi into a shared
library and that's all there is to it and probably as a side effec
https://bugs.freedesktop.org/show_bug.cgi?id=108355
Michel Dänzer changed:
What|Removed |Added
Product|Mesa|xorg
QA Contact|mesa-dev@lists.
https://bugs.freedesktop.org/show_bug.cgi?id=108355
Michel Dänzer changed:
What|Removed |Added
Attachment #142083|text/x-log |text/plain
mime type|
66 matches
Mail list logo
