This one has been bugging me too. Just not enough to actually fix it. :-P
Reviewed-by: Jason Ekstrand
On Sat, Sep 9, 2017 at 3:35 PM, Eric Engestrom wrote:
> src/mesa/drivers/dri/i965/intel_tex.h:52:40: warning: ‘enum
> intel_miptree_create_flags’ declared inside parameter list will not be
>
https://bugs.freedesktop.org/show_bug.cgi?id=102639
Bug ID: 102639
Summary: BadLength (poly request too large or internal Xlib
length erro
Product: Mesa
Version: 17.2
Hardware: All
OS: Linux (All)
Yes, that's what I mean - no workaround in Mesa.
Marek
On Sat, Sep 9, 2017 at 12:07 PM, Mario Kleiner
wrote:
> On 09/08/2017 05:21 AM, Michel Dänzer wrote:
>>
>> On 08/09/17 12:26 AM, Marek Olšák wrote:
>>>
>>> [+ Dave]
>>>
>>> We can also ignore gnome-shell in Mesa for now and let the gnome-she
src/mesa/drivers/dri/i965/intel_tex.h:52:40: warning: ‘enum
intel_miptree_create_flags’ declared inside parameter list will not be visible
outside of this definition or declaration
enum intel_miptree_create_flags flags);
^~
Fixes: ca
Chema Casanova writes:
> El 08/09/17 a las 11:06, Alejandro Piñeiro escribió:
>> On 08/09/17 02:50, Francisco Jerez wrote:
>>> Currently the liveness analysis pass would extend a live interval up
>>> to the top of the program when no unconditional and complete
>>> definition of the variable is fo
https://bugs.freedesktop.org/show_bug.cgi?id=102634
--- Comment #2 from mais...@archlinux.us ---
Actually, this seems to work in Mesa 17.2
--
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=102571
danielr...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Since commit 552aaa11 the compiler complains:
external/mesa/src/amd/common/ac_debug.c:124:51: error: use of undeclared
identifier 'gfx9d_reg_table'; did you mean 'sid_reg_table'?
reg = find_register(gfx9d_reg_table,
ARRAY_SIZE(gfx9d_reg_table), offset);
The enhanced layouts spec has all kinds of restrictions about what can
and cannot be mixed in a location. Integer/float(/presumably double)
can't occupy a single location, interpolation has to be the same, as
well as auxiliary storage (including patch!).
The implication of this is ... don't specif
On 09.09.2017 13:26, Bas Nieuwenhuizen wrote:
Out of curiosity, don't SI and CIK also support the out of order bits?
Why only enable it on VI?
According to internal docs, there's a lock-up bug on older chips.
(and would enabling it on 1 SE chips hurt anything?)
I don't think so, except for
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 95346, which changed state.
Bug 95346 Summary: Stellaris - Black/super dark planets
https://bugs.freedesktop.org/show_bug.cgi?id=95346
What|Removed |Added
---
https://bugs.freedesktop.org/show_bug.cgi?id=95346
Kai changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=102571
--- Comment #2 from Bas Nieuwenhuizen ---
I can't reproduce. Can you do a crashing run with
RADV_DEBUG=shaders,shaderstats and then upload the stdout+stderr?
if num_vgprs is really 0, I'd think something is really wrong.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=99591
Bas Nieuwenhuizen changed:
What|Removed |Added
Resolution|--- |NOTABUG
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=98406
Bas Nieuwenhuizen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=98842
Bas Nieuwenhuizen changed:
What|Removed |Added
Component|Drivers/Vulkan/radeon |Mesa core
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=98714
Bas Nieuwenhuizen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99319
Bas Nieuwenhuizen changed:
What|Removed |Added
Resolution|--- |FIXED
Component|Drivers/Vul
https://bugs.freedesktop.org/show_bug.cgi?id=100951
--- Comment #3 from Fabian Maurer ---
(In reply to Bas Nieuwenhuizen from comment #2)
> vkcube is known broken, it allocates memory from a non-mappable memory type
> and then tries to map it.
Well, that was unexpected. Thanks for explaining, ca
https://bugs.freedesktop.org/show_bug.cgi?id=100951
Bas Nieuwenhuizen changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
On 09/07/2017 04:27 PM, Emil Velikov wrote:
Hi Mario,
On 5 September 2017 at 06:01, Mario Kleiner wrote:
Expose formats which are supported at least back to Gen 5 Ironlake,
possibly further. Allow creation of 10 bpc winsys buffers for drawables.
glxinfo now lists new RGBA 10 10 10 2/0 forma
On 09.09.2017 00:55, Brian Paul wrote:
We don't have vasprintf() on Windows so we need to implement it ourselves.
Since we don't know the length of the final string, take a guess at 1
chars.
---
src/util/u_string.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/util/u
Out of curiosity, don't SI and CIK also support the out of order bits?
Why only enable it on VI?
(and would enabling it on 1 SE chips hurt anything?)
On Sat, Sep 9, 2017 at 12:43 PM, Nicolai Hähnle wrote:
> Hi all,
>
> This is my attempt at restructuring the logic for out-of-order
> rasterizatio
From: Nicolai Hähnle
We do not enable this by default for additive blending, since it slightly
breaks OpenGL invariance guarantees due to non-determinism.
Still, there may be some applications can benefit from white-listing
via the radeonsi_commutative_blend_add drirc setting without any real
v
Hi all,
This is my attempt at restructuring the logic for out-of-order
rasterization, including commutative blending cases. Tested on
Tonga and Polaris so far.
The series adds some new options:
R600_DEBUG=nooutoforder --> disable entirely
drirc options:
radeonsi_assume_no_z_fights --> as the n
From: Nicolai Hähnle
This does not take commutative blending into account yet.
R600_DEBUG=nooutoforder disables it.
---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c | 3 +
src
From: Marek Olšák
Reviewed-by: Nicolai Hähnle
---
src/amd/common/ac_surface.c| 2 ++
src/amd/common/ac_surface.h| 1 +
src/amd/vulkan/radv_device.c | 6 +++---
src/gallium/drivers/r600/evergreen_state.c | 2 +-
src/ga
From: Nicolai Hähnle
This option enables a performance optimization where typical non-blending
draws with depth buffer may be rasterized out-of-order (on VI+, multi-SE
chips).
This optimization can lead to incorrect results when an applications
renders multiple objects with the same Z value at t
From: Nicolai Hähnle
The callee can derive the current enable state itself.
---
src/gallium/drivers/r600/r600_state_common.c | 4 +++-
src/gallium/drivers/radeon/r600_pipe_common.h | 4 +++-
src/gallium/drivers/radeon/r600_query.c | 3 ++-
src/gallium/drivers/radeonsi/si_state.c | 4
On 09/07/2017 04:33 PM, Emil Velikov wrote:
On 5 September 2017 at 06:01, Mario Kleiner wrote:
A few clients don't like RGB10X2 and RGB10A2 fbconfigs and
visuals. Add a new driconf option 'expose_rgb10_configs' to
allow per application enable/disable.
The option defaults to enabled.
Most con
On 09/07/2017 04:38 PM, Emil Velikov wrote:
On 7 September 2017 at 01:51, Mario Kleiner wrote:
On 09/06/2017 03:18 PM, Eric Engestrom wrote:
On Tuesday, 2017-09-05 07:01:13 +0200, Mario Kleiner wrote:
Similar to the matching of 24 bit RGB visuals to 32-bit
RGBA EGLConfigs.
Fixes failure
https://bugs.freedesktop.org/show_bug.cgi?id=102634
--- Comment #1 from mais...@archlinux.us ---
Created attachment 134108
--> https://bugs.freedesktop.org/attachment.cgi?id=134108&action=edit
Wrong output when WORKAROUND_RADV = 0
--
You are receiving this mail because:
You are the assignee fo
https://bugs.freedesktop.org/show_bug.cgi?id=102634
Bug ID: 102634
Summary: 0 Color write masks with multiple render targets
redirects color outputs to wrong attachment
Product: Mesa
Version: 17.1
Hardware: Other
On 09/07/2017 04:45 PM, Emil Velikov wrote:
Hi Mario,
Hi Emil, and thanks for all the feedback.
On 5 September 2017 at 06:01, Mario Kleiner wrote:
Successfully tested under Weston 3.0, both with the new
(experimental) dmabuf+modifiers path, and the old buffer
import path. Photometer confir
On 09/08/2017 05:21 AM, Michel Dänzer wrote:
On 08/09/17 12:26 AM, Marek Olšák wrote:
[+ Dave]
We can also ignore gnome-shell in Mesa for now and let the gnome-shell
maintainers fix the issue in gnome-shell.
Indeed, that would be better.
[+ Jonas Adahl] probably a good person to ping wrt.
35 matches
Mail list logo
