yeah, sounds fine. I wasn't 100% sure what the dnz flag does, with the
addition below: Reviewed-by: Karol Herbst
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 307d8762506..202faf0746a 100644
---
dnz flag only applies for multiplications (e.g. to make 0 * Infinity
becomes 0 instead of NaN). Once we optimize a MAD into an ADD, the dnz
flag no longer makes sense, and upsets the GM107 emitter (since it looks
at the ftz and dnz flags together).
Signed-off-by: Ilia Mirkin
---
On Sun, Nov 25, 2018 at 2:11 AM Ilia Mirkin wrote:
>
> Using this approach, num_samplers will never go down. Also, this
> applies to more than just samplers -- textures, everything else.
but is this a problem? I was checking on where num_samplers was used
and I don't see that it make much of a
yeah, I was hitting some asserts with a d3d trace. The issue is that
we optimize some MADs/MULs with dnz set to ADD, but the emiter isn't
able to emit an ADD with the dnz flag. At least for gm107.
example TGSI triggering it (there are more cases though):
VERT
PROPERTY NEXT_SHADER FRAG
PROPERTY
Can you elaborate as to what the issue is? The dnz flag is set when we
want to make NaN -> Infinity. Do you have a concrete TGSI program that
triggers issues?
On Sat, Nov 24, 2018 at 6:04 PM Karol Herbst wrote:
>
> fixes asserts with gallium nine
>
> Signed-off-by: Karol Herbst
> ---
>
Using this approach, num_samplers will never go down. Also, this
applies to more than just samplers -- textures, everything else.
On Sat, Nov 24, 2018 at 6:04 PM Karol Herbst wrote:
>
> The new approach is that samplers don't get unbound even if they won't be used
> in a draw and we should just
fixes asserts with gallium nine
Signed-off-by: Karol Herbst
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
Patch 1 fixes some compiler asserts I was running into:
Maybe we can just do those optimizations anyway, but simply drop the dnz flag
on the ADD as long as the instructions aren't marked as being prices
Patch 2 tries to fix our outstanding issue with bound samplers with nine.:
I don't really
The new approach is that samplers don't get unbound even if they won't be used
in a draw and we should just leave them be as well.
Fixes a regression in multiple windows games using gallium nine and nouveau.
Fixes: 4d6fab245eec3880e2a59424a579851f44857ce8
"cso: don't track the number of
https://bugs.freedesktop.org/show_bug.cgi?id=108245
--- Comment #6 from Bas Nieuwenhuizen ---
https://patchwork.freedesktop.org/patch/263716/ fixes the testcase (and
hopefully does not regress anything else)
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are
Mirrors AMDVLK. Looks like if we go over the alignment of height
we actually start to change the addressing. Seems like the extra
miplevels actually work with this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108245
Fixes: f6cc15dccd5 "radv/gfx9: fix block compression texture views.
We used the layer count which results in an off by one error.
Not sure this really affects anything.
Fixes: f4e499ec791 "radv: add initial non-conformant radv vulkan driver"
---
src/amd/vulkan/radv_image.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=108848
--- Comment #9 from Axel Davy ---
You can also try to reduce the memory footprint of pulseaudio, see the trick
described here:
https://www.winehq.org/pipermail/wine-devel/2018-November/134954.html
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=108853
Bug ID: 108853
Summary: OSMesaGetDepthBuffer flipped vertically
Product: Mesa
Version: 18.2
Hardware: All
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=108848
--- Comment #8 from Andre Heider ---
Game works for me with nine, but only after setting LARGE_ADDRESS_AWARE
manually on DAOrigins.exe. (It seems to work without on low texture details,
but I guess it'll crash at some point eventually).
--
https://bugs.freedesktop.org/show_bug.cgi?id=108848
--- Comment #7 from Axel Davy ---
After looking further, the crash observed seems to be NineVolumeTexture9
missing checks to properly exit on memory allocation failures.
I'll send a fix for this, but it won't help the game work. I suspect the
https://bugs.freedesktop.org/show_bug.cgi?id=108848
--- Comment #6 from Axel Davy ---
Is the game 32 bits ?
One thing you may want to try is to use a tool to make the exe large space
aware.
Possibly you run out of virtual space (wine restricts available space without
large space aware, and some
https://bugs.freedesktop.org/show_bug.cgi?id=108848
--- Comment #5 from Axel Davy ---
Mesa needs to be built with --enable-debug to have NINE_DEBUG=all do anything.
I can see though that two mmaps are failing on the log with nine.
Getting a new log with NINE_DEBUG=all would help find what
Patch #5 and #6 are Reviewed-by: Christian König
For patch #7 I think we really need some testing if that gives us an
improvement. As you noted as well that we have buffer which are slightly
smaller than a power of two is rather unlikely.
Christian.
Am 24.11.18 um 00:40 schrieb Marek
19 matches
Mail list logo
