https://bugs.freedesktop.org/show_bug.cgi?id=101334
--- Comment #20 from Marko ---
Hello,
I have a similar problem on R9-270x and latest Mesa-git. I can check the latest
commit Mesa was built from, but honestly, I have this issue since day one (it
never worked and I check periodically).
Dota2 a
On 7 July 2017 at 14:25, Dave Airlie wrote:
> Hi,
>
> Hopefully someone in here can help with this, and maybe ask the
> internal Vulkan team how this works.
>
> I've been looking into a large perf cliff in radv vs pro when MRT
> rendering is enabled (I didn't know that
> was what I was looking for
On Thursday, July 6, 2017 10:51:49 PM PDT Kenneth Graunke wrote:
> On Wednesday, July 5, 2017 2:24:55 PM PDT Chris Wilson wrote:
> > Quoting Kenneth Graunke (2017-07-05 21:56:54)
> > > ---
> > > src/mesa/drivers/dri/i965/brw_bufmgr.c | 15 +--
> > > 1 file changed, 13 insertions(+), 2
On Wednesday, July 5, 2017 2:24:55 PM PDT Chris Wilson wrote:
> Quoting Kenneth Graunke (2017-07-05 21:56:54)
> > ---
> > src/mesa/drivers/dri/i965/brw_bufmgr.c | 15 +--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
On Thursday, July 6, 2017 4:21:28 AM PDT Chris Wilson wrote:
> Quoting Kenneth Graunke (2017-07-05 21:56:53)
> > diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> > b/src/mesa/drivers/dri/i965/intel_buffer_objects.c
> > index a9ac29a6a81..2b0f7b9a698 100644
> > --- a/src/mesa/drivers
v2: fix an indentation error
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe
These need to match for interop compatibility queries.
Signed-off-by: Andres Rodriguez
---
src/amd/vulkan/radv_device.c | 9 -
src/amd/vulkan/radv_private.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
i
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index e3abc10..078f12b 1006
These are just basic implementations.
Signed-off-by: Andres Rodriguez
---
src/mesa/main/formatquery.c | 17 +
src/mesa/main/mtypes.h | 3 +++
src/mesa/main/texparam.c| 27 +++
3 files changed, 47 insertions(+)
diff --git a/src/mesa/main/formatqu
We have a few UUIDs, so lets be more specific.
Signed-off-by: Andres Rodriguez
---
src/amd/vulkan/radv_device.c | 4 ++--
src/amd/vulkan/radv_pipeline_cache.c | 4 ++--
src/amd/vulkan/radv_private.h| 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/amd/vul
This is required for interop use cases. The same device must report
identical UUIDs through the GL and Vulkan APIs so that users can
identify when it is safe to perform a memory object import.
v2: use ac helpers to calculate the uuid
Signed-off-by: Andres Rodriguez
---
src/amd/vulkan/radv_devic
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/ddebug/dd_screen.c | 17 +
src/gallium/include/pipe/p_defines.h | 1 +
src/gallium/include/pipe/p_screen.h| 13 +
3 files changed, 31 insertions(+)
diff --git a/src/gallium/drivers/ddebug/dd_screen.c
b/sr
Signed-off-by: Andres Rodriguez
---
src/mesa/main/externalobjects.c | 63 +
1 file changed, 51 insertions(+), 12 deletions(-)
diff --git a/src/mesa/main/externalobjects.c b/src/mesa/main/externalobjects.c
index 919a81c..73c9d4b 100644
--- a/src/mesa/main/e
We need vulkan and gl to produce the same UUIDs. Therefore we should
keep the mechanism to compute these in a common location to guarantee
they are updated in lockstep.
Signed-off-by: Andres Rodriguez
---
src/amd/common/ac_gpu_info.c | 27 +++
src/amd/common/ac_gpu_info.h
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/radeon/r600_pipe_common.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index fd67d9a..c14d4eb 100644
--- a/src/gallium/driv
Hi,
Hopefully someone in here can help with this, and maybe ask the
internal Vulkan team how this works.
I've been looking into a large perf cliff in radv vs pro when MRT
rendering is enabled (I didn't know that
was what I was looking for until today - about 2-3 weeks ago I was
just digging aroun
v2: respective changes for new gallium interface
Signed-off-by: Andres Rodriguez
---
src/mesa/main/dd.h | 15 +++
src/mesa/main/get.c | 17 +
src/mesa/main/version.c | 13 +
src/mesa/main/version.h |
Include no_error variants as well.
Signed-off-by: Andres Rodriguez
---
src/mapi/glapi/gen/EXT_external_objects.xml | 4 +-
src/mesa/main/bufferobj.c | 80 +++--
src/mesa/main/bufferobj.h | 16 +-
src/mesa/main/externalobjects.c
These are used by EXT_external_objects to present UUIDs for the device
and the driver.
Signed-off-by: Andres Rodriguez
---
src/mesa/main/get.c | 177
1 file changed, 177 insertions(+)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
ind
v2: use PIPE_CAP_MEMOBJ to guard the extension
Signed-off-by: Andres Rodriguez
---
src/mesa/main/extensions_table.h | 2 ++
src/mesa/main/mtypes.h | 2 ++
src/mesa/state_tracker/st_extensions.c | 5 +
3 files changed, 9 insertions(+)
diff --git a/src/mesa/main/extensio
This can be used to guard support for EXT_memory_object and related
extensions.
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/etnaviv/etnaviv_screen.c | 1 +
src/gallium/drivers/freedreno/freedreno_screen.c | 1 +
src/gallium/drivers/i915/i915_screen.c | 1 +
src/gallium/
Signed-off-by: Andres Rodriguez
---
src/mesa/main/externalobjects.c | 53
src/mesa/main/teximage.c| 76 +
src/mesa/main/teximage.h| 10 ++
3 files changed, 110 insertions(+), 29 deletions(-)
diff --git a/src
Use a memory object instead of user memory.
Signed-off-by: Andres Rodriguez
---
src/mesa/main/dd.h | 12 +
src/mesa/state_tracker/st_cb_bufferobjects.c | 66 +---
2 files changed, 61 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/
No changes, just re-indent.
Signed-off-by: Andres Rodriguez
---
src/mesa/state_tracker/st_cb_bufferobjects.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_bufferobjects.c
b/src/mesa/state_tracker/st_cb_bufferobjec
From: Dave Airlie
Instead of allocating memory to back a texture, use the provided memory
object.
v2: split off extension exposure logic
Signed-off-by: Andres Rodriguez
---
src/mesa/state_tracker/st_cb_texture.c | 123 +
1 file changed, 123 insertions(+)
diff
From: Dave Airlie
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/radeon/r600_pipe_common.h | 7 ++
src/gallium/drivers/radeon/r600_texture.c | 112 ++
2 files changed, 119 insertions(+)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gal
Signed-off-by: Andres Rodriguez
---
src/mesa/main/dd.h | 9
src/mesa/main/externalobjects.c | 93 -
src/mesa/main/texstorage.c | 76 -
src/mesa/main/texstorage.h | 13 +-
4 files changed, 160
From: Dave Airlie
v2: pass dedicated flag
Signed-off-by: Andres Rodriguez
---
src/mesa/Makefile.sources| 2 +
src/mesa/state_tracker/st_cb_memoryobjects.c | 66
src/mesa/state_tracker/st_cb_memoryobjects.h | 25 +++
src/mesa/state_track
Includes implementation stubs.
Signed-off-by: Andres Rodriguez
---
src/mapi/glapi/gen/EXT_external_objects.xml| 234 +
src/mapi/glapi/gen/EXT_external_objects_fd.xml | 28 +++
src/mapi/glapi/gen/Makefile.am | 2 +
src/mapi/glapi/gen/gl_API.xml
Signed-off-by: Andres Rodriguez
---
src/mesa/main/externalobjects.c | 54 -
src/mesa/main/mtypes.h | 5 +++-
2 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/externalobjects.c b/src/mesa/main/externalobjects.c
index 2a
From: Dave Airlie
v2: fix comment regarding fd ownership, define pipe_memory_object
---
src/gallium/drivers/ddebug/dd_screen.c | 40 ++
src/gallium/include/pipe/p_screen.h| 36 ++
src/gallium/include/pipe/p_state.h | 8 +++
This series is an initial step towards the implementation of
EXT_external_objects. It implements the functionality under
EXT_memory_object and EXT_memory_object_fd.
This updated version of the series has the following changes:
* Re-worked UUIDs to be provided by the gallium driver
* Use a PIPE
Used by EXT_external_objects and EXT_external_objects_fd
Signed-off-by: Andres Rodriguez
---
src/mesa/drivers/common/driverfuncs.c | 4 +
src/mesa/main/dd.h| 36 +
src/mesa/main/externalobjects.c | 145 +-
src/mesa/main/externa
From: Thomas Hellstrom
If the application hasn't done any drawing since the last call, we
would reuse the same back buffer which was used for the previous swap,
which may not have completed yet. This could result in various issues
such as tearing or application hangs.
In the normal case, the beh
On Thu, Jul 6, 2017 at 4:48 PM, Matt Turner wrote:
> ... trivially (as allowed by the spec!) by reusing the existing
> nir_opt_intrinsics code.
> ---
> src/compiler/nir/nir.h| 4
> src/compiler/nir/nir_opt_intrinsics.c | 6 +++---
> 2 files changed, 7 insertions(+), 3 deletio
I've thought about this a little bit, and I think we'd rather just
decrease the bitsize of the intrinsic rather than add a whole new one.
The separate intrinsic isn't really buying you anything, I don't think
it's going to make anything simpler.
On Thu, Jul 6, 2017 at 4:48 PM, Matt Turner wrote:
On Thu, Jul 6, 2017 at 6:36 PM, Matt Arsenault wrote:
>
> On Jul 6, 2017, at 18:31, Connor Abbott wrote:
>
> After looking into it some more, I think LLVM won't promote allocas to
> registers at all when there are non-constant indices in the mix, and
> fixing it seems kinda involved. I guess a be
> On Jul 6, 2017, at 18:31, Connor Abbott wrote:
>
> After looking into it some more, I think LLVM won't promote allocas to
> registers at all when there are non-constant indices in the mix, and
> fixing it seems kinda involved. I guess a better solution for now
AMDGPUPromoteAlloca does this, b
On Thu, Jul 6, 2017 at 2:18 PM, Connor Abbott wrote:
> On Thu, Jul 6, 2017 at 2:01 PM, Bas Nieuwenhuizen
> wrote:
>> On Thu, Jul 6, 2017 at 9:48 PM, Connor Abbott
>> wrote:
>>> From: Connor Abbott
>>>
>>> The old way was very TGSI-based, and couldn't handle indirect
>>> dereferences at all. In
On Thu, Jul 6, 2017 at 5:07 PM, Connor Abbott wrote:
> FYI, I already have another series which adds ARB_shader_ballot and
> ARB_shader_group_vote intrinsics, in addition to adding some more
> precise semantics to represent the restrictions on ballotARB() and
> similar things [0]. The problem is t
It looks like we could want this into -stable (?)
On Thu, 2017-07-06 at 21:10 +0300, Andres Gomez wrote:
> On Thu, 2017-06-22 at 09:25 +, Namburu, Chandu-babu wrote:
> > From: Chandu Babu N
> > Subject: [PATCH] [st/va] Fix leak in VAAPI subpictures
> >
> > sampler view allocated in vaAssoci
On Mon, Jun 12, 2017 at 9:26 PM, Jason Ekstrand wrote:
> On Mon, Jun 12, 2017 at 7:38 PM, Connor Abbott wrote:
>>
>> On Mon, Jun 12, 2017 at 7:19 PM, Jason Ekstrand
>> wrote:
>> > On Mon, Jun 12, 2017 at 11:58 AM, Nicolai Hähnle
>> > wrote:
>> >>
>> >> On 12.06.2017 20:50, Connor Abbott wrote:
This patch starts uploading UBO data via 3DSTATE_CONSTANT_* packets,
and updates the compiler to know that there's extra payload data, so
things continue working. However, it still issues pull loads for all
data. I wanted to separate the two aspects for greater bisectability.
---
src/intel/compi
This is an annoyingly big hammer, but it seems less mean than disabling
UBO pushing, and I'm not sure what else to do.
---
src/mesa/drivers/dri/i965/intel_buffer_objects.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_bu
Soon, we're going to start providing UBO data to shaders as push
constants, rather than requiring them to issue pull loads. The
3DSTATE_CONSTANT_* commands require 32 byte aligned pointers.
So, we need to increase this from 16 to 32.
---
src/mesa/drivers/dri/i965/brw_context.c | 5 -
1 file
Right now, we always upload new push constant data, and immediately
emit 3DSTATE_CONSTANT_* packets. We call intel_upload_space and store
the resulting BO pointer in brw->curbe.curbe_bo. We read that when
emitting the packets. This works today, but is fragile - it depends on
upload and packet em
This actually takes advantage of the newly pushed UBO data, avoiding
pull loads.
XXX: quote performance numbers
---
src/intel/compiler/brw_fs.cpp | 35 ++-
src/intel/compiler/brw_fs.h | 2 ++
src/intel/compiler/brw_fs_nir.cpp | 28 +++
This adds a NIR pass that decides which portions of UBOS we should
upload as push constants, rather than pull constants.
---
src/intel/Makefile.sources | 1 +
src/intel/compiler/brw_compiler.h | 11 +
src/intel/compiler/brw_nir.h| 4 +
sr
With UBOs, the answer of "have we decided to push this uniform" gets
a bit more complicated - for one, we have multiple surfaces. This
patch refactors things so we can add the new code in a single place.
---
src/intel/compiler/brw_fs.cpp | 39 +++
src/intel/com
Previously we would re-upload the constant data to the batchbuffer,
then re-emit the packets. We only need to do the last step (causing
the existing data in the batchbuffer to be re-uploaded to the push
constant staging area in the L3).
Now that we've separated the two, it's pretty easy to accomp
This allows us to have atoms which are signalled on every draw call.
---
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_draw.c | 5 +
src/mesa/drivers/dri/i965/brw_state_upload.c | 1 +
3 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/
I hope to upload UBO via 3DSTATE_CONSTANT_XS packets, in addition to
normal uniforms. In order to do that, I'll need to re-emit the packets
when UBOs change. But I don't want to re-copy the regular uniform data
to the batchbuffer every time.
This patch separates out the data uploading from the p
Hello,
This series begins pushing UBOs (rather than resorting to pull loads)
for scalar shaders on Gen7.5+, for the OpenGL driver. Future work is
to hook it up for Vulkan (haven't started), for the vec4 shader stages
(I have about 75% of the code written), and for Gen7 (I have a plan).
Note that
By default, 3DSTATE_CONSTANT_* Constant Buffer 0 is relative to dynamic
state base address. This makes it unusable for pushing UBOs. I'd like
to be able to use all four push buffers.
There is a bit in the INSTPM register (or CS_DEBUG_MODE2 on Skylake)
which controls whether buffer 0 is relative
FYI, I already have another series which adds ARB_shader_ballot and
ARB_shader_group_vote intrinsics, in addition to adding some more
precise semantics to represent the restrictions on ballotARB() and
similar things [0]. The problem is that marking ballot as
can_eliminate but not can_reorder is ove
https://bugs.freedesktop.org/show_bug.cgi?id=101712
guiscara...@gmail.com changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
If we know the high bits are zero, we can just do a 32-bit comparison on
the low bytes instead.
---
src/compiler/nir/nir_opt_algebraic.py | 14 +-
src/compiler/nir/nir_search_helpers.h | 48 +++
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/
No use in taking a 64-bit value when we know the high 32-bits are zero.
---
src/intel/compiler/brw_compiler.c | 2 +-
src/intel/compiler/brw_fs_nir.cpp | 9 +++--
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/intel/compiler/brw_compiler.c
b/src/intel/compiler/brw_compiler
Allows the instructions to be compacted. The documentation claims that
some of these only accept UD types, even though the type doesn't change
the operation performed. Just normalize the types to ensure we get
instruction compaction.
The only functional changes are for FBL and CBIT (always use UD
---
docs/features.txt| 2 +-
docs/relnotes/17.2.0.html| 1 +
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/docs/features.txt b/docs/features.txt
index ec78447e88..1f628e1c03 100644
-
Two of the ARB_shader_ballot piglit tests hit the find_lsb case,
removing some of the noise allowed me to better debug the test when it
was failing.
---
src/compiler/nir/nir_opt_algebraic.py | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/s
The implementations of the ARB_shader_ballot intrinsics will explicitly
read the flag as a source register.
---
src/intel/compiler/brw_fs.cpp | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index
---
src/intel/compiler/brw_fs_nir.cpp | 41 +++
src/intel/compiler/brw_nir.c | 1 +
2 files changed, 42 insertions(+)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 17f35e081d..25e9b703eb 100644
--- a/src/intel/c
Some hardware, like i965, doesn't support group sizes greater than 32.
In that case, we can use the ballot32 intrinsic instead, which will
simplify our code generation.
---
src/compiler/nir/nir.h| 2 ++
src/compiler/nir/nir_intrinsics.h | 3 +++
src/compiler/nir/nir_opt_intri
The implementation of ballotARB() will start by zeroing the flags
register. So, a doing something like
if (gl_SubGroupInvocationARB % 2u == 0u) {
... = ballotARB(true);
[...]
} else {
... = ballotARB(true);
[...]
---
docs/features.txt| 2 +-
docs/relnotes/17.2.0.html| 1 +
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/docs/features.txt b/docs/features.txt
index 79b71de543..ec78447e88 100644
-
---
src/compiler/glsl/glsl_to_nir.cpp | 45 +++
src/compiler/nir/nir_intrinsics.h | 13 +++
2 files changed, 58 insertions(+)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index 43d7e07042..23632f27c2 100644
--- a/s
We already had a channel_num system value, which I'm renaming to
subgroup_invocation to match the rest of the new system values.
Note that while ballotARB(true) will return zeros in the high 32-bits on
systems where gl_SubGroupSizeARB <= 32, the gl_SubGroup??MaskARB
variables do not consider wheth
---
src/intel/compiler/brw_fs_nir.cpp | 36
1 file changed, 36 insertions(+)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index a9dce42c38..264398f38e 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compile
This function will be used to implement read_invocation (by specifying a
specific channel) and read_first_invocation (by not specifying a
channel).
---
src/intel/compiler/brw_fs_builder.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/intel/compiler/brw_fs_builder
i965 will want these to be scalar operations.
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/nir.h | 2 +-
.../nir/nir_lower_read_invocation_to_scalar.c | 112 +
3 files changed, 114 insertions(+), 1 deletion(
The implementations of the ARB_shader_group_vote intrinsics will
explicitly write the flag as the destination register.
---
src/intel/compiler/brw_fs.cpp | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
Specifically, constant fold intrinsics from ARB_shader_group_vote, but I
suspect it'll be useful for other things in the future.
---
src/compiler/Makefile.sources | 1 +
src/compiler/nir/nir.h| 2 +
src/compiler/nir/nir_opt_intrinsics.c | 102 +++
I don't expect anyone is going to care about using this in vec4 programs
(vertex/tessellation/geometry on Gen6/7), no one has come up with a good
way to implement it much less test it.
---
src/intel/compiler/brw_compiler.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/intel/compiler/b
... trivially (as allowed by the spec!) by reusing the existing
nir_opt_intrinsics code.
---
src/compiler/nir/nir.h| 4
src/compiler/nir/nir_opt_intrinsics.c | 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/ni
These are intrinsics rather than opcodes, because they operate across
channels.
---
src/compiler/glsl/glsl_to_nir.cpp | 22 ++
src/compiler/nir/nir_intrinsics.h | 5 +
2 files changed, 27 insertions(+)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/gl
Copying the kernel commit message:
Starting with GEN9, Memory Object Control State (MOCS) becomes an index
into a table as opposed to the direct programming within the command.
The table has 62 usable entries (ie 6 bits can represent all settings),
and each buffer type may use one of these 62 entr
https://bugs.freedesktop.org/show_bug.cgi?id=101703
Brian Paul changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Signed-off-by: Ben Widawsky
---
src/intel/drm/i915_drm.h | 8
1 file changed, 8 insertions(+)
diff --git a/src/intel/drm/i915_drm.h b/src/intel/drm/i915_drm.h
index c26bf7c125..69e38ce89f 100644
--- a/src/intel/drm/i915_drm.h
+++ b/src/intel/drm/i915_drm.h
@@ -431,6 +431,14 @@ typedef s
We don't yet have optimal MOCS settings, but we have enough to know how
to at least determine when we might have non-optimal settings within our
driver.
Signed-off-by: Ben Widawsky
---
src/intel/vulkan/anv_device.c | 12
src/intel/vulkan/anv_private.h| 2 ++
From: Ben Widawsky
Starting with GEN9, Memory Object Control State (MOCS) becomes an index
into a table as opposed to the direct programming within the command.
The table has 62 usable entries (ie 6 bits can represent all settings),
and each buffer type may use one of these 62 entries to describe
Thanks for the patches, Olivier!
I'm a bit short on time, but I'll test/commit them ASAP. I'll take a
closer look at the VBO issue too.
-Brian
On 07/06/2017 09:45 AM, Olivier Lauffenburger wrote:
glPrimitiveRestartNV crashes when it is called during the compilation
of a render list.
There
https://bugs.freedesktop.org/show_bug.cgi?id=101712
--- Comment #2 from guiscara...@gmail.com ---
Created attachment 132488
--> https://bugs.freedesktop.org/attachment.cgi?id=132488&action=edit
DSMEG (more detailed log)
Here it is a more detailed log
--
You are receiving this mail because:
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=101712
guiscara...@gmail.com changed:
What|Removed |Added
Priority|medium |high
--- Comment #1 from guiscar
https://bugs.freedesktop.org/show_bug.cgi?id=101712
Bug ID: 101712
Summary: CPU lockup after ring 0 stalled
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
Thanks! Pushed and cc'd it to stable.
Not pushing the first patch as I assume that is superseded by Connors patches.
On Fri, Jun 30, 2017 at 12:15 PM, Alex Smith
wrote:
> The NIR parameters are ordered "compare, data", matching GLSL, but both
> the image and buffer LLVM intrinsics take them the
On Thu, Jul 6, 2017 at 11:18 PM, Aleksander Morgado
wrote:
> Despite being a member of the etna_screen struct, 'refcnt' is used by
> the winsys-specific logic to track the reference count of the object
> managed in a hash table. When the count reaches zero, the pipe screen
> is removed from the ta
Reviewed-by: Jason Ekstrand
On Thu, Jul 6, 2017 at 12:48 PM, Connor Abbott
wrote:
> From: Connor Abbott
>
> The compact flag doesn't make sense on local variables, since the
> packing on them is up to the driver. This fixes nir_validate assertions
> in some cases, particularly when lower_io_to
On Thu, Jul 6, 2017 at 9:50 PM, Connor Abbott wrote:
> From: Connor Abbott
>
> Radeonsi doesn't either. As of the last commit, these should be handled
> properly as long as LLVM has scratch support. We also should use
> nir_lower_io_to_temporaries() for inputs instead of generating an
> if-ladder
Reviewed-by: Bas Nieuwenhuizen
On Fri, Jul 7, 2017 at 12:10 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Since radv uses compute rings and we can't know when we are setting
> up the shaders what ring they are to be used on, we should just use
> the default xnack setting. This may be suboptima
On 6 July 2017 at 22:20, Connor Abbott wrote:
> On Thu, Jul 6, 2017 at 12:48 PM, Connor Abbott
> wrote:
>> From: Connor Abbott
>>
>> This series grew out of trying to get rid of the copy-n-pasted index
>> calculation code in radv's NIR-to-LLVM path, in particular in
>> radv_get_deref_offset(). I
From: Dave Airlie
Since radv uses compute rings and we can't know when we are setting
up the shaders what ring they are to be used on, we should just use
the default xnack setting. This may be suboptimal in some places,
but if we hit a problem, we likely should try and address this
between llvm a
On 2017-07-04 12:39 PM, Andres Rodriguez wrote:
On 2017-07-04 09:30 AM, Christian König wrote:
Am 04.07.2017 um 15:13 schrieb Nicolai Hähnle:
On 01.07.2017 01:03, Andres Rodriguez wrote:
From: Dave Airlie
Signed-off-by: Andres Rodriguez
---
src/gallium/drivers/radeon/r600_pipe_common.
On Thu, Jul 6, 2017 at 8:24 PM, Andres Gomez wrote:
> Marek, would we want this series in -stable or we shouldn't bother ?
Don't bother. Patch 1 isn't that important. Other patches are for
features not enabled in 17.1.
Marek
___
mesa-dev mailing list
m
On Thu, Jul 6, 2017 at 12:48 PM, Connor Abbott
wrote:
> From: Connor Abbott
>
> This series grew out of trying to get rid of the copy-n-pasted index
> calculation code in radv's NIR-to-LLVM path, in particular in
> radv_get_deref_offset(). I realized for IO it's probably better to
> switch to usi
Despite being a member of the etna_screen struct, 'refcnt' is used by
the winsys-specific logic to track the reference count of the object
managed in a hash table. When the count reaches zero, the pipe screen
is removed from the table and destroyed.
Fix the logic by initializing the refcnt to 1 wh
Reviewed-by: Bas Nieuwenhuizen
On Thu, Jul 6, 2017 at 9:50 PM, Connor Abbott wrote:
> From: Connor Abbott
>
> This makes the radv shader pipeline much closer to brw_preprocess_nir().
> The main changes are:
>
> - Now we call nir_split_var_copies(), which is necessary for
> nir_lower_var_copies(
On Thu, Jul 6, 2017 at 2:01 PM, Bas Nieuwenhuizen
wrote:
> On Thu, Jul 6, 2017 at 9:48 PM, Connor Abbott
> wrote:
>> From: Connor Abbott
>>
>> The old way was very TGSI-based, and couldn't handle indirect
>> dereferences at all. Instead, pass through the type information NIR has
>
> I think the
On Thu, Jul 6, 2017 at 4:56 PM, Marek Olšák wrote:
> On Thu, Jul 6, 2017 at 8:12 PM, Alex Deucher wrote:
>> On Thu, Jul 6, 2017 at 1:13 PM, Jan Vesely wrote:
>>> On Thu, 2017-07-06 at 12:09 +1000, Dave Airlie wrote:
From: Dave Airlie
Use family, but only set xnack+ for gfx9.
Patches 3-4 look technically correct to me, so for just using it for shared vars
Reviewed-by: Bas Nieuwenhuizen
On Thu, Jul 6, 2017 at 9:48 PM, Connor Abbott wrote:
> From: Connor Abbott
>
> Similar to before, do the direct NIR->LLVM translation instead of
> lowering to an array then back to a
1 - 100 of 168 matches
Mail list logo