Needs to allocate batches from the cache so that it could
get a valid index and make resource dependancy tracking right.
And it doesn't need to flush the batch in each launch_grid from
this approach. Also it could make it avoid potential memory leak
of the batches.
In addition this fixes assertio
From: Michał Janiszewski
Signed-off-by: Michał Janiszewski
---
src/gallium/state_trackers/glx/xlib/xm_api.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/xm_api.h
b/src/gallium/state_trackers/glx/xlib/xm_api.h
index d2b57d6b9d..9684
From: Michał Janiszewski
Signed-off-by: Michał Janiszewski
---
src/gallium/auxiliary/target-helpers/inline_debug_helper.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/target-helpers/inline_debug_helper.h
b/src/gallium/auxiliary/target-helpers/in
From: Michał Janiszewski
Signed-off-by: Michał Janiszewski
---
src/compiler/glsl/ir_builder.h| 5 +
src/gallium/drivers/svga/include/svga3d_surfacedefs.h | 5 +
src/gallium/winsys/svga/drm/vmw_shader.h | 1 +
src/glx/dri2_priv.h
On Mon, 2018-09-10 at 13:04 -0500, Jason Ekstrand wrote:
> ---
> src/compiler/spirv/spirv_to_nir.c | 170 ++
>
> 1 file changed, 103 insertions(+), 67 deletions(-)
>
(...)
> @@ -2516,6 +2600,9 @@ vtn_handle_image(struct vtn_builder *b, SpvOp
> opcode,
> } else {
>
Jason Ekstrand writes:
> Doing all of the CPU sampling on one side or the other of the GPU sampling
> would probably reduce our window.
True, although as I said, it's taking several µs to get through the
loop, and the gpu clock tick is far smaller than that, so even adding
the two values togethe
Jason Ekstrand writes:
> The result is that we're looking at something like "end - start +
> monotonic_raw_tick + max(gpu_tick, monotonic_tick)" Have I just come
> full-circle?
Yes. As monotonic_raw_tick and monotonic_tick are both 1...
--
-keith
signature.asc
Description: PGP signature
_
For example:
vec1 32 ssa_386 = feq ssa_333.x, ssa_6
vec1 32 ssa_387 = feq ssa_333.x, ssa_2
vec1 32 ssa_391 = bcsel ssa_387, ssa_388, ssa_324
vec1 32 ssa_396 = bcsel ssa_386, ssa_324, ssa_391
Can be simplified to:
vec1 32 ssa_386 = feq ssa_333.x, ssa_6
vec1 32 ssa_391 = bcsel ss
On Tue, Oct 16, 2018 at 5:56 PM Keith Packard wrote:
> Bas Nieuwenhuizen writes:
>
> > You can make the monotonic case the same as the raw case if you make
> > sure to always sample the CPU first by e.g. splitting the loops into
> > two and doing CPU in the first and GPU in the second. That way
On Tue, Oct 16, 2018 at 5:06 PM Keith Packard wrote:
> Bas Nieuwenhuizen writes:
>
> > Well the complication here is that in the MONOTONIC (not
> > MONOTONIC_RAW) case the CPU measurement can happen at the end of the
> > MONOTONIC_RAW interval (as the order of measurements is based on
> > argume
On Tue, Oct 16, 2018 at 7:51 PM Matt Turner wrote:
> On Sun, Oct 14, 2018 at 3:58 PM Jason Ekstrand
> wrote:
> >
> > On October 14, 2018 17:12:34 Matt Turner wrote:
> >
> > > From: Jason Ekstrand
> > >
> > > [mattst88]: Found in an old branch of Jason's.
> > >
> > > Jason implemented: inot, ia
On Sun, Oct 14, 2018 at 3:58 PM Jason Ekstrand wrote:
>
> On October 14, 2018 17:12:34 Matt Turner wrote:
>
> > From: Jason Ekstrand
> >
> > [mattst88]: Found in an old branch of Jason's.
> >
> > Jason implemented: inot, iand, ior, iadd, isub, ineg, iabs, compare,
> > imin, ima
Signed-off-by: Sagar Ghuge
---
src/intel/compiler/brw_eu_emit.c | 36
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 0cbc682ebc..a6b45fcb1a 100644
--- a/src/intel/compiler/br
Bas Nieuwenhuizen writes:
> You can make the monotonic case the same as the raw case if you make
> sure to always sample the CPU first by e.g. splitting the loops into
> two and doing CPU in the first and GPU in the second. That way you
> make the case above impossible.
Right, I had thought of t
https://bugs.freedesktop.org/show_bug.cgi?id=107765
--- Comment #12 from Timothy Arceri ---
(In reply to farmboy0+freedesktop from comment #11)
> Just start the game. After the intro videos it crashes, before the first
> game screen.
> Or if you want a faster crash do this:
> https://pcgamingwiki
On Wed, Oct 17, 2018 at 12:06 AM Keith Packard wrote:
>
> Bas Nieuwenhuizen writes:
>
> > Well the complication here is that in the MONOTONIC (not
> > MONOTONIC_RAW) case the CPU measurement can happen at the end of the
> > MONOTONIC_RAW interval (as the order of measurements is based on
> > argu
Bas Nieuwenhuizen writes:
> Well the complication here is that in the MONOTONIC (not
> MONOTONIC_RAW) case the CPU measurement can happen at the end of the
> MONOTONIC_RAW interval (as the order of measurements is based on
> argument order), so you can get a tick that started `period` (5 in
> thi
Jason Ekstrand writes:
> You've got me almost convinced as well. Thanks for the diagrams! I think
> instead of adding 1 perhaps what we want is
>
> max2(sample_interval_ns, gpu_tick_ns + monotonic_tick_ns)
>
> Where monotonic_tick_ns is maybe as low as 1. Am I following you correctly?
Not qu
https://bugs.freedesktop.org/show_bug.cgi?id=107765
--- Comment #11 from farmboy0+freedesk...@googlemail.com ---
Just start the game. After the intro videos it crashes, before the first game
screen.
Or if you want a faster crash do this:
https://pcgamingwiki.com/wiki/Batman:_Arkham_City#Skip_intro
On Tue, Oct 16, 2018 at 11:07 PM Keith Packard wrote:
>
> Jason Ekstrand writes:
>
> > I think what Bas is getting at is that there are two problems:
> >
> > 1) We are not sampling at exactly the same time
> > 2) The two clocks may not tick at exactly the same time.
>
> Thanks for the clarifica
On Tue, Oct 16, 2018 at 4:07 PM Keith Packard wrote:
> Jason Ekstrand writes:
>
> > I think what Bas is getting at is that there are two problems:
> >
> > 1) We are not sampling at exactly the same time
> > 2) The two clocks may not tick at exactly the same time.
>
> Thanks for the clarificati
https://bugs.freedesktop.org/show_bug.cgi?id=107765
--- Comment #10 from Samuel Pitoiset ---
Okay, so apparently Batman needs itoi with R32G32B32 too. I thought only btoi
as needed by that game. I will implement it.
Can you explain how to reproduce the problem in-game?
--
You are receiving thi
https://bugs.freedesktop.org/show_bug.cgi?id=107765
--- Comment #9 from farmboy0+freedesk...@googlemail.com ---
Unhandled exception: assertion failed in 32-bit code (0xf7feeb09).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:f7feeb09 ESP:12aef0d0 EBP:12aef0fc EFLAGS:0246
Jason Ekstrand writes:
> I think what Bas is getting at is that there are two problems:
>
> 1) We are not sampling at exactly the same time
> 2) The two clocks may not tick at exactly the same time.
Thanks for the clarification.
> If we want to be conservative, I suspect Bas may be right that
https://bugs.freedesktop.org/show_bug.cgi?id=107765
--- Comment #8 from Samuel Pitoiset ---
Can you paste a backtrace please?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
mesa-dev mai
On Thu, Oct 11, 2018 at 4:43 AM Samuel Pitoiset
wrote:
>
> WD_SWITCH_ON_EOP seems to be the only workaround that fixes
> the GPU hangs with Yakuza and The Evil Within on Vega. I don't
> like as it might decrease geometry performance as pointed out
> by Marek, but I don't know how to implement a be
https://bugs.freedesktop.org/show_bug.cgi?id=108355
--- Comment #5 from Hadrien Nilsson ---
I tried to run the game under a Wayland session instead of X11 and the mouse
cursor is normal.
--
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=108355
--- Comment #4 from Hadrien Nilsson ---
Created attachment 142059
--> https://bugs.freedesktop.org/attachment.cgi?id=142059&action=edit
Xorg log after reboot and started briefly the game in windowed mode
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=108355
--- Comment #3 from Hadrien Nilsson ---
Created attachment 142058
--> https://bugs.freedesktop.org/attachment.cgi?id=142058&action=edit
dmesg after reboot
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are th
https://bugs.freedesktop.org/show_bug.cgi?id=108353
--- Comment #3 from Ahmed Elsayed ---
I hope that will be done one day.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
mesa-dev maili
Due to some idiosyncrasies of the dispatch logic on gen8+ hardware, we
have to manually force the fragment shader to actually be dispatched when a
shader has side effects or uses discard and color writes are disabled.
Historically, we have done this with 3DSTATE_PS::PixelShaderHasUAV which
enforce
Suggested-by: Francisco Jerez
---
src/intel/blorp/blorp_genX_exec.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/intel/blorp/blorp_genX_exec.h
b/src/intel/blorp/blorp_genX_exec.h
index 50341ab0ecf..30025cf4deb 100644
--- a/src/intel/blorp/blorp_genX_exec.h
+++ b/src/intel/blo
This reverts commit 0fa9e6d7b304f6a8064ed78a4b9c557e1026e7e5. The real
issue appears to have been that HiZ ops don't like having WM thread
dispatch force-enabled. The previous commit fixes that problem so we
can go back to using the ForceThreadDispatchEnable bit even on SKL+.
---
src/intel/vulka
On Tue, Oct 16, 2018 at 2:35 PM Keith Packard wrote:
> Bas Nieuwenhuizen writes:
>
> >> + end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
> >> +
> >> + uint64_t clock_period = end - begin;
> >> + uint64_t device_period = DIV_ROUND_UP(100,
> clock_crystal_freq);
> >> +
> >> +
Bas Nieuwenhuizen writes:
>> + end = radv_clock_gettime(CLOCK_MONOTONIC_RAW);
>> +
>> + uint64_t clock_period = end - begin;
>> + uint64_t device_period = DIV_ROUND_UP(100, clock_crystal_freq);
>> +
>> + *pMaxDeviation = MAX2(clock_period, device_period);
>
> Should th
https://bugs.freedesktop.org/show_bug.cgi?id=107765
farmboy0+freedesk...@googlemail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
R
On Tue, Oct 16, 2018 at 4:21 AM Topi Pohjolainen
wrote:
>
> Identifier bits in the dispatch header have changed. See Bspec:
>
> SINGLE_PATCH Payload:
>
> 3D Pipeline Stages - 3D Pipeline Geometry -
> Hull Shader (HS) Stage IVB+ - Payloads IVB+
>
> Fixes:
> KHR-GL46.tessellation_shader.tessellatio
I've updated the comments a bit and pushed to master. Thanks for all your
debugging!
On Wed, Sep 19, 2018 at 11:21 AM Sergii Romantsov <
sergii.romant...@gmail.com> wrote:
> On Skylake enabling of ForceThreadDispatchEnable causes gpu-hang.
>
> -v2: enabling of ForceThreadDispatchEnable is only
Tested-by: Chuck Atkins
On Tue, Oct 16, 2018 at 8:51 AM Cherniak, Bruce
wrote:
> Reviewed-by: Bruce Cherniak
>
> > On Oct 15, 2018, at 9:53 AM, Alok Hota wrote:
> >
> > Converted from x86 VFMADDPS intrinsic to generic LLVM intrinsic, and
> > removed createInstructionSimplifierPass, which were
Looks reasonable to me.
Reviewed-by: Roland Scheidegger
Am 16.10.18 um 10:07 schrieb Gert Wollny:
> From: Gert Wollny
>
> The number of immediate constants was fixed and the size check was
> only done by means of an assertion. Given this a shader that emits
> more immediate constants would res
https://bugs.freedesktop.org/show_bug.cgi?id=108457
Bug ID: 108457
Summary: [OpenGL CTS]
KHR-GL46.tessellation_shader.single.xfb_captures_data_
from_correct_stage fails
Product: Mesa
Version: unspecified
https://bugs.freedesktop.org/show_bug.cgi?id=108382
--- Comment #3 from Emil Velikov ---
>From a quick skim at the report - it does sound similar to the issue described
here [1]. Feel free to try the patch.
If it doesn't help please submit any patches as described here [2]
[1] https://patchwor
On Sun, 14 Oct 2018 at 13:56, Jason Ekstrand wrote:
>
> Here I was reveling in the triviality of my fixed-pci-path implementation
> and you had to show me up by implementing it properly. :-P
>
> Implementing it properly is a better plan because we know discrete is coming.
>
You're welcome, that's
FYI, patch 1 is required for this patch to build. It also means this patch
found a nice little bug. I'll respond to patch 1 in more detail after the
SI call tomorrow.
--Jason
On October 16, 2018 06:49:35 Lionel Landwerlin
wrote:
Reviewed-by: Lionel Landwerlin
On 15/10/2018 04:47, Jas
Reviewed-by: Bruce Cherniak
> On Oct 15, 2018, at 9:53 AM, Alok Hota wrote:
>
> Converted from x86 VFMADDPS intrinsic to generic LLVM intrinsic, and
> removed createInstructionSimplifierPass, which were both removed in LLVM
> 7.0.0
>
> These changes combine patches we received from the communi
Reviewed-by: Lionel Landwerlin
On 15/10/2018 04:47, Jason Ekstrand wrote:
We don't need weak references to instance entrypoints because we never
have more than one of each so we don't need the NULL fall-back. This
also helps us avoid forgetting things because we now get link errors for
missing
Identifier bits in the dispatch header have changed. See Bspec:
SINGLE_PATCH Payload:
3D Pipeline Stages - 3D Pipeline Geometry -
Hull Shader (HS) Stage IVB+ - Payloads IVB+
Fixes:
KHR-GL46.tessellation_shader.tessellation_shader_tc_barriers.barrier_guarded_read_write_calls
CC: Anuj Phogat
CC
https://bugs.freedesktop.org/show_bug.cgi?id=108355
--- Comment #2 from Michel Dänzer ---
Please attach the corresponding Xorg log file and output of dmesg.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=108105
--- Comment #12 from Samuel Pitoiset ---
Well, I can launch the game, but I get a black screen after clicking on the
"Play" button. This is apparently a known issue with the tutorial. The only way
to solve it is to play the tutorial on a differe
On Monday, 2018-10-15 18:53:40 -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 wi
From: Gert Wollny
The number of immediate constants was fixed and the size check was
only done by means of an assertion. Given this a shader that emits
more immediate constants would result in a memory corruption when
mesa is build in release mode.
Instead of using this fixed limit allocate the
https://bugs.freedesktop.org/show_bug.cgi?id=108115
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Fixes errors thrown by GCC's Undefined Behaviour sanitizer (ubsan) every
time this macro is used.
Signed-off-by: Eric Engestrom
---
src/util/bitset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/bitset.h b/src/util/bitset.h
index adafc72a5f74d46e118a..3b18abac793a
Hi,
On 10/13/18 3:08 AM, Jason Ekstrand wrote:
This patch series adds a simple NIR shader cache that sits right after
spirv_to_nir and brw_preprocess_nir and before linking. This should help
alleviate some of the added overhead of link-time optimization since most
of the NIR-level optimization
I tried to find a helper function for bit count already available but
apparently I missed it :) No need for a new one if one exists already indeed.
-Toni
On Mon, Oct 15, 2018 at 07:59:58PM +, Roland Scheidegger wrote:
> Am 15.10.18 um 15:19 schrieb Toni Lönnberg:
> > ---
> > src/util/bitsca
On 10/16/18 9:54 AM, Bas Nieuwenhuizen wrote:
On Tue, Oct 16, 2018 at 9:40 AM Samuel Pitoiset
wrote:
This feature isn't used for now, so disable it until
wwm is fixed in LLVM.
Is wwm actually the issue?
Just reporting what Daniel said.
Reviewed-by: Bas Nieuwenhuizen
Fixes dEQP-VK.s
On Tue, Oct 16, 2018 at 9:40 AM Samuel Pitoiset
wrote:
>
> This feature isn't used for now, so disable it until
> wwm is fixed in LLVM.
Is wwm actually the issue?
Reviewed-by: Bas Nieuwenhuizen
>
> Fixes dEQP-VK.subgroups.vote.graphics.subgroupallequal*
>
> https://bugs.freedesktop.org/show_bug
This feature isn't used for now, so disable it until
wwm is fixed in LLVM.
Fixes dEQP-VK.subgroups.vote.graphics.subgroupallequal*
https://bugs.freedesktop.org/show_bug.cgi?id=108115
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_device.c | 6 --
1 file changed, 4 insertions(+), 2 d
On Tue, Oct 16, 2018 at 7:31 AM Keith Packard wrote:
>
> Offers three clocks, device, clock monotonic and clock monotonic
> raw. Could use some kernel support to reduce the deviation between
> clock values.
>
> v2:
> Ensure deviation is at least as big as the GPU time interval.
>
> v3:
>
The RADV bits are:
Reviewed-by: Samuel Pitoiset
Thanks!
On 10/16/18 7:31 AM, Keith Packard wrote:
Offers three clocks, device, clock monotonic and clock monotonic
raw. Could use some kernel support to reduce the deviation between
clock values.
v2:
Ensure deviation is at least as big
https://bugs.freedesktop.org/show_bug.cgi?id=107765
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> The leadership of freedesktop.org (fd.o) has recently expressed interest
> in having an elected governing body. Given the tight connection between
> fd.o and X.Org and the fact that X.Org has such a governing body it
> seemed obvious
62 matches
Mail list logo
