https://bugs.freedesktop.org/show_bug.cgi?id=97967
--- Comment #7 from Timothy Arceri ---
The real issue is these MAX_SIZE limits are far too small. Arguably we should
handle it anyway or maybe apply a minimum size.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You
https://bugs.freedesktop.org/show_bug.cgi?id=98471
Bug 98471 depends on bug 97967, which changed state.
Bug 97967 Summary: glsl/tests/cache-test regression
https://bugs.freedesktop.org/show_bug.cgi?id=97967
What|Removed |Added
---
https://bugs.freedesktop.org/show_bug.cgi?id=97967
Vinson Lee changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
On 20 January 2017 at 13:02, Dave Airlie wrote:
> This is a first pass at geometry shader support on radv, all the code
> should be here in reviewable pieces, it seems to mostly pass CTS tests
> but triggers some llvm 3.9 bugs around kill, and there might still
> be a GPU hang in here, but this sh
This reverts commit 0bac2551e40410e2251daf4fd9faf69310ab34ce.
Now that we position the guardband correctly (applying translations
in addition to scaling) and made it as large (or larger) than the
render target, this shouldn't be necessary.
Now we leave guardband clipping enabled 100% of the time,
Previously we disabled the guardband when the viewport was smaller than
the framebuffer on Gen6-7.5, to prevent portions of primitives from
being draw outside of the viewport. On Gen8+, we relied on the viewport
extents test to effectively scissor this away for us.
We can simply always enable sci
From: Jason Ekstrand
(Patch co-authored by Jason and Ken.)
We scaled the guardband based on the viewport size, but failed to
take into account the translation portion of the viewport transform.
This meant the guardband was always centered around the origin.
We want it to be centered around the
The next patch will make the guardband calculation dependent on the
transformation matrix. Instead of computing it in both atoms, just
combine them into a single atom.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_state.h | 2 +-
src/mesa/drivers/dri/i965/brw_state
On Sat, 2016-12-31 at 14:55 -0500, Romain Failliot wrote:
> Hi!
>
> I've recently bought a 4K display and an RX 480, but I've got some
> troubles with Dota when using high settings. I've created a thread on
> Phoronix forum (because maybe other people have the same problem...):
>
> https://www.ph
https://bugs.freedesktop.org/show_bug.cgi?id=99496
Christian Lanig changed:
What|Removed |Added
Summary|Dolphin emulator: Starting |Dolphin emulator displays
https://bugs.freedesktop.org/show_bug.cgi?id=99496
--- Comment #1 from Christian Lanig ---
It has turned out that my installation was misconfigured having two versions of
the Vulkan driver installed. See
https://bugs.freedesktop.org/show_bug.cgi?id=99498
On a fresh installation I get the message
https://bugs.freedesktop.org/show_bug.cgi?id=99498
Christian Lanig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=99498
--- Comment #1 from Bas Nieuwenhuizen ---
In what way does it not work? Does nothing happen at all, show a corrupted
intro screen, or give an error message in a pop-up?
Also, libgl1-mesa-glx from the padoka PPA should provide radv already. That
https://bugs.freedesktop.org/show_bug.cgi?id=99498
Bug ID: 99498
Summary: Dota 2 doesn't launch with -vulkan option enabled
Product: Mesa
Version: 17.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=99496
Bug ID: 99496
Summary: Dolphin emulator: Starting Mario Kart Wii results in a
black screen/window and freezes the whole PC
Product: Mesa
Version: 17.0
Hardware: x86-64 (AMD
On Sun, Jan 22, 2017 at 1:50 AM, Kenneth Graunke
wrote:
> When trying to blit larger tiled surfaces, the pitch can be larger than
> 32768 bytes, which means it won't fit in a GLshort. Passing it in will
> truncate the stride to 0, which has...surprising results.
>
> For Y-tiled surfaces, pitches
https://bugs.freedesktop.org/show_bug.cgi?id=99442
Hadrien changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 20 January 2017 at 17:06, Christian Gmeiner
wrote:
> Hi Rhys,
>
> 2017-01-19 7:02 GMT+01:00 Rhys Kidd :
> > Use of unsigned loop control variable with '>= 0' would lead to infinite
> loop.
> >
> > Reported by clang:
> >
> > etnaviv_compiler.c:1024:39: warning: comparison of unsigned expression
On Sunday, January 22, 2017 9:07:53 AM PST Jason Ekstrand wrote:
> I think there are places where we can drop some stride checks. We should
> do that too. Thanks!
>
> I thought we didn't see any blits last night. How does this fix it?
I'm not sure...I went home, turned off Z16, and ran
./glct
I think there are places where we can drop some stride checks. We should
do that too. Thanks!
I thought we didn't see any blits last night. How does this fix it?
On Jan 22, 2017 1:50 AM, "Kenneth Graunke" wrote:
> When trying to blit larger tiled surfaces, the pitch can be larger than
> 3276
https://bugs.freedesktop.org/show_bug.cgi?id=99413
Iaroslav Andrusyak changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
When trying to blit larger tiled surfaces, the pitch can be larger than
32768 bytes, which means it won't fit in a GLshort. Passing it in will
truncate the stride to 0, which has...surprising results.
For Y-tiled surfaces, pitches can be up to 128KB, as we divide by 4 and
program the pitch as a n
"Juan A. Suarez Romero" writes:
> Rewrite atan2(y,x) to cover (+/-)INF values.
>
> This fixes several test cases in Vulkan CTS
> (dEQP-VK.glsl.builtin.precision.atan2.*)
>
> v2: do not flush denorms to 0 (jasuarez)
> ---
> src/compiler/spirv/vtn_glsl450.c | 48
>
23 matches
Mail list logo
