https://bugs.freedesktop.org/show_bug.cgi?id=102496
--- Comment #5 from Thomas Hellström ---
(In reply to Tapani Pälli from comment #3)
> I'm seeing the 'no animation' on i965 too. Sometimes animation happens but
> most of the time not.
@Tapani
If this is seen on i965/DRI, this commit is probab
https://bugs.freedesktop.org/show_bug.cgi?id=102496
Thomas Hellström changed:
What|Removed |Added
Status|NEW |NEEDINFO
Assignee|mesa-dev
On 09/06/2017 09:30 AM, Tapani Pälli wrote:
verified values against drm_fourcc.h,
Reviewed-by: Tapani Pälli
One nit though, other values are aligned with a tab while your additions
use spaces. Since tab is used all over this header maybe these changes
should continue that fine tradition,
there are similar helpers between mesa formats and dri ones in
dri_util.c but I can see that it had already these covered;
Reviewed-by: Tapani Pälli
On 09/05/2017 08:01 AM, Mario Kleiner wrote:
To allow DRI3/Present buffer sharing for 10 bpc buffers.
Signed-off-by: Mario Kleiner
---
src/l
verified values against drm_fourcc.h,
Reviewed-by: Tapani Pälli
On 09/05/2017 08:01 AM, Mario Kleiner wrote:
Used to support ARGB2101010 and XRGB2101010
winsys framebuffers / drawables, but added
other 10 bpc fourcc's as well for consistency
with definitions in wayland_drm.h, gbm.h, and
drm_fo
On Tue, Sep 5, 2017 at 8:19 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This being declared bool means it won't get merged with the previous
> bitfields, this seems like an oversight rather than deliberate.
>
Really? That's silly... This is fine with me.
Reviewed-by: Jason Ekstrand
> No
https://bugs.freedesktop.org/show_bug.cgi?id=102496
--- Comment #3 from Tapani Pälli ---
I'm seeing the 'no animation' on i965 too. Sometimes animation happens but most
of the time not.
--
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=102530
--- Comment #14 from Tapani Pälli ---
(In reply to Alexandre Demers from comment #13)
> Created attachment 133983 [details]
> Kodi segfault with MESA_NO_ERROR=0
>
> Core dump produced by Kodi when MESA_NO_ERROR=0
Have you tried it Kodi works w
On 06/09/17 11:59, Ilia Mirkin wrote:
On Tue, Sep 5, 2017 at 9:54 PM, Timothy Arceri wrote:
On 06/09/17 11:23, Ilia Mirkin wrote:
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 singl
From: Dave Airlie
This being declared bool means it won't get merged with the previous
bitfields, this seems like an oversight rather than deliberate.
Noticed when running pahole.
Signed-off-by: Dave Airlie
---
src/compiler/nir/nir.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
The new name means "Volcano" in Japanese.
For those who don't remember, Kazan is a work-in-progress
software-rendering Vulkan implementation.
I moved the source code to https://github.com/kazan-3d/kazan, additionally,
I registered the domain name kazan-3d.org, which currently redirects to the
sou
On 6 September 2017 at 03:11, Marek Olšák wrote:
> On Tue, Sep 5, 2017 at 5:50 PM, Brian Paul wrote:
>> On 09/04/2017 05:29 AM, Marek Olšák wrote:
>>>
>>> On Sun, Sep 3, 2017 at 1:18 PM, Dave Airlie wrote:
From: Dave Airlie
reduces size from 1144 to 1128.
Signed-of
On Tue, Sep 5, 2017 at 9:54 PM, Timothy Arceri wrote:
>
> On 06/09/17 11:23, Ilia Mirkin wrote:
>>
>> 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
On 06/09/17 11:23, Ilia Mirkin wrote:
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!).
Th
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 06/09/17 05:17, Samuel Pitoiset wrote:
This will allow to dump the active shaders when a hang is
This will allow us to
Otherwise 1-6, 8-9:
Reviewed-by: Timothy Arceri
I'll let Dave or Bas comment on the other two.
___
mesa-dev mailing list
me
On Tue, Sep 5, 2017 at 5:32 PM, Ian Romanick wrote:
> On 08/17/2017 10:22 AM, Jason Ekstrand wrote:
> > These helpers are much nicer than just using assert because they don't
> > kill your process. Instead, it longjmps back to spirv_to_nir(), cleans
> > up all the temporary memory, and nicely re
Reviewed-by: Bruce Cherniak
> On Sep 5, 2017, at 1:57 PM, Tim Rowley wrote:
>
> Highlight is starting to unify the simd/simd16 code, removing lots of
> temporary code duplication.
>
> No piglit or vtk test regressions.
>
> Tim Rowley (8):
> swr/rast: Allow gather of floats from fetch shader
On 01/09/17 21:15, Juan A. Suarez Romero wrote:
On Thu, 2017-06-29 at 14:43 +1000, Timothy Arceri wrote:
On 27/06/17 21:20, Juan A. Suarez Romero wrote:
On Tue, 2017-06-27 at 09:29 +1000, Timothy Arceri wrote:
On 16/06/17 18:12, Juan A. Suarez Romero wrote:
Commit 00620782c9 (i965: use nir
On 08/17/2017 10:22 AM, Jason Ekstrand wrote:
> These helpers are much nicer than just using assert because they don't
> kill your process. Instead, it longjmps back to spirv_to_nir(), cleans
> up all the temporary memory, and nicely returns NULL. While crashing is
> completely OK in the Vulkan w
The series is
Reviewed-by: Matt Turner
I think It should be tagged for the stable branch as well. Does anyone
else have an opinion?
I tested a KBL-R system (the 0x5917 PCI ID) with it set as a GT1.5 and
a GT2 and in both cases is passed piglit.
Are you planning to send patches for the kernel a
We need to set brw->no_batch_wrap to actually avoid flushing in the
middle of our BLORP operation, and instead grow the batchbuffer.
---
src/mesa/drivers/dri/i965/genX_blorp_exec.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/genX_
Calling exit(1) when execbuffer fails is not necessarily safe.
When running Piglit tests with a Mesa that submitted invalid commands
to the GPU, I discovered the following problem:
1. do_flush_locked fails and calls exit(1)...invoking atexit handlers.
2. Piglit tries to clean up after itself, and
Now that we can grom the batchbuffer if we absolutely need the extra
space, we don't need to reserve space for the final do-or-die ending
commands.
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 11 +++
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 26 --
2 f
The batch buffer and state buffer code is fairly tied together,
and having it in one .c file will make refactoring easier.
Also, drop some commentary above brw_state_batch. The "aperture
checking performance hacks" are long since gone, so that paragraph
makes little sense at this point.
---
src/
We'll need to read from both buffers when decoding state.
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 102 +-
1 file changed, 52 insertions(+), 50 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer
We now flush the batch when either the batchbuffer or statebuffer
reaches the original intended batch size, instead of when the sum of
the two reaches a certain size (which makes no sense now that they're
separate buffers).
With this change, we also need to update our "are we near the end?"
estima
I'm planning on splitting batch and state into separate buffers, at
which point we'll need two relocation lists. In preparation for that,
this patch refactors the relocation stuff into a structure we can
replicate...which looks a lot like anv_reloc_list.
---
src/mesa/drivers/dri/i965/brw_context.
Previously, we emitted GPU commands and indirect state into the same
buffer, using a stack/heap like system where we filled in commands from
the start of the buffer, and state from the end of the buffer. We then
flushed before the two met in the middle.
Meeting in the middle is fatal, so you have
brw_batch_reloc emits a relocation from the batchbuffer to elsewhere.
brw_state_reloc emits a relocation from the statebuffer to elsewhere.
For now, they do the same thing, but when we actually split the two
buffers, we'll change brw_state_reloc to use the state buffer.
---
src/mesa/drivers/dri/i
We don't need to special case the batch - when we add the batch to the
validation list, we can simply increase the refcount to 2, and when we
make a new batch, we'll drop it back down to 1 (when unreferencing all
buffers in the validation list). The final reference is still held by
brw->batch.bo,
Previously, we would just assert fail and die in this case. The only
safeguard is the "estimated max prim size" checks when starting a draw
(or compute dispatch or BLORP operation)...which are woefully broken.
Growing is fairly straightforward:
1. Allocate a new larger BO.
2. memcpy the existing
This makes the assertion safe against batchbuffers growing.
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 5ac34e59299..a7243a
Prior to the previous patch, we would pwrite the batchbuffer contents,
and wanted to skip the execbuffer if that failed. Now, we write things
directly to the map, so we don't need this check.
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 40 ---
1 file changed, 18 in
This only made sense for the shadow copy of the batch.
---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index df094b
When a batch is flushed, INTEL_DEBUG=bat prints a message indicating
which part of the code triggered the flushed, and some statistics about
the batch/state buffer utilization.
It also decodes the batchbuffer in debug builds...which is so much
output that it drowns out the utilization messages, if
Now that we have write-combining maps, our writes to the batch should be
reasonably fast. (In the past, we only had uncached maps, which were
slow...so we kept a CPU-side shadow copy for write combining purposes.)
There are a few places that still read back a DWord or so from the
batch, which wil
Hello,
This series separates GPU commands and indirect state into two distinct
buffers - the batch buffer and the state buffer. It then adds support
for growing the batch/state buffers, in case we need more space but are
in a "critical section" where we can't safely "wrap" (flush) the batch.
Grow
This assertion prevents you from doing intel_batchbuffer_require_space
with a size so huge it won't fit in the batchbuffer. This doesn't seem
like a common mistake, and I've never seen the assert to be useful.
Soon, I hope to have batches grow, at which point this won't make sense.
---
src/mesa/
Fixes: f4e499ec791 "radv: add initial non-conformant radv vulkan driver"
---
src/amd/vulkan/radv_meta_blit2d.c | 206 --
1 file changed, 107 insertions(+), 99 deletions(-)
diff --git a/src/amd/vulkan/radv_meta_blit2d.c
b/src/amd/vulkan/radv_meta_blit2d.c
index
https://bugs.freedesktop.org/show_bug.cgi?id=102530
--- Comment #13 from Alexandre Demers ---
Created attachment 133983
--> https://bugs.freedesktop.org/attachment.cgi?id=133983&action=edit
Kodi segfault with MESA_NO_ERROR=0
Core dump produced by Kodi when MESA_NO_ERROR=0
--
You are receivin
https://bugs.freedesktop.org/show_bug.cgi?id=102461
Vinson Lee changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Signed-off-by: Anuj Phogat
---
src/intel/common/gen_device_info.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/src/intel/common/gen_device_info.c
b/src/intel/common/gen_device_info.c
index c0eb7c3..a9a1399 100644
--- a/src/intel/common/gen_device_info.c
+++ b/src/intel/common/
Signed-off-by: Anuj Phogat
---
include/pci_ids/i965_pci_ids.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 5c42712..80f7712 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_i
Signed-off-by: Anuj Phogat
---
include/pci_ids/i965_pci_ids.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 80f7712..6f92084 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
These PCI IDs are not used in any Kabylake SKUs.
Signed-off-by: Anuj Phogat
---
include/pci_ids/i965_pci_ids.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 57e70b7..5c42712 100644
--- a/include/pci_ids/i965_pci_id
Signed-off-by: Anuj Phogat
---
include/pci_ids/i965_pci_ids.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
index 6f92084..4a51e44 100644
--- a/include/pci_ids/i965_pci_ids.h
+++ b/include/pci_ids/i965_pci_ids.h
Alejandro Piñeiro writes:
> Although it is possible to emit them directly as AND/OR on brw_fs_nir,
> having a specific opcode makes it easier to remove duplicate settings
> later.
>
> v2: (Curro)
> - Set thread control to 'switch' when using the control register
> - Use a single SHADER_OPCODE
On Sat, Sep 2, 2017 at 3:17 AM, Chad Versace wrote:
> I'm bringing up Vulkan in the Android container of Chrome OS (ARC++).
>
> On Android, stdio goes to /dev/null. On Android, remote gdb is even more
> painful than the usual remote gdb. On Android, nothing works like you
> expect and debugging is
Emil Velikov writes:
> From: Emil Velikov
>
> The macro itself is a well defined string, which cannot cause issues
> with printf or other printf-like functions.
>
> All other places through Mesa already use it directly, so let's update
> the final two instances.
>
> Signed-off-by: Emil Velikov
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/amd/vulkan/radv_debug.c b/src/amd/vulkan/radv_debug.c
index f2339dfe71..d9d6b95bb6 100644
--- a/src/amd/vulkan/radv_debug.c
+++ b/src/amd/vulkan/r
Only the ASM is currently dumped.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_debug.c | 58 +
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/src/amd/vulkan/radv_debug.c b/src/amd/vulkan/radv_debug.c
index a1c0a61997..f2339dfe
To dump the shader stats when a hang is detected.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 64 +-
src/amd/vulkan/radv_shader.c | 70 ++
src/amd/vulkan/radv_shader.h | 6
3 files chang
When a GPU hang is detected in radv_gpu_hang_occured() we know
which command buffer is faulty but the bound pipeline might
have been updated during the execution.
The pointer to the radv_pipeline object is emitted just after
the second trace ID, that way it would be easy to dump the
active shaders
To dump the ASM when RADV_TRACE_FILE is used and a hang is
detected.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index 44a1f64737..0596fb7f54 100
This will allow to dump the active shaders when a hang is
detected. Only the ASM will be dumped for now.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 27 ++-
src/amd/vulkan/radv_shader.h | 1 +
2 files changed, 15 insertions(+), 13 deletions(-)
diff
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_shader.c | 114 +--
1 file changed, 56 insertions(+), 58 deletions(-)
diff --git a/src/amd/vulkan/radv_shader.c b/src/amd/vulkan/radv_shader.c
index c0fbdd3d49..de7d9a2752 100644
--- a/src/amd/vulkan/r
Reduce size of radv_pipeline.c and improve code isolation. More
code can probably moved but it's a start.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/Makefile.sources | 1 +
src/amd/vulkan/radv_cmd_buffer.c | 28 +-
src/amd/vulkan/radv_debug.c | 1 +
src/amd/vulkan/r
The device object contains the debug flags.
Signed-off-by: Samuel Pitoiset
---
src/amd/vulkan/radv_pipeline.c | 16 +++-
src/amd/vulkan/radv_shader.c | 17 +
src/amd/vulkan/radv_shader.h | 8 +++-
3 files changed, 19 insertions(+), 22 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=102496
--- Comment #2 from Bruce Cherniak ---
"no animation" may be a better description. This is exactly what I'm seeing on
llvmpipe, swr, and softpipe.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contac
Fixed properly in gcc-compatible fashion.
---
src/gallium/drivers/swr/rasterizer/core/binner.cpp | 110 -
1 file changed, 20 insertions(+), 90 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/binner.cpp
b/src/gallium/drivers/swr/rasterizer/core/binner.cpp
ind
SWR rasterizer must remain C++11 compliant.
---
src/gallium/drivers/swr/rasterizer/core/binner.cpp | 6 +++---
src/gallium/drivers/swr/rasterizer/core/binner.h | 14 +++---
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/swr/rasterizer/core/binner.cpp
Highlight is starting to unify the simd/simd16 code, removing lots of
temporary code duplication.
No piglit or vtk test regressions.
Tim Rowley (8):
swr/rast: Allow gather of floats from fetch shader with 2-4GB offsets
swr: set caps for VB 4-byte alignment
swr/rast: Removed some trailing wh
For consistency and to support overloading.
---
src/gallium/drivers/swr/rasterizer/core/clip.h | 18 +-
.../drivers/swr/rasterizer/core/frontend.cpp | 6 +++---
src/gallium/drivers/swr/rasterizer/core/pa.h | 22 +++---
3 files changed, 15 insertions
---
src/gallium/drivers/swr/rasterizer/core/clip.cpp | 16 +-
src/gallium/drivers/swr/rasterizer/core/clip.h | 1650 ++
src/gallium/drivers/swr/rasterizer/core/state.h |7 +
3 files changed, 465 insertions(+), 1208 deletions(-)
diff --git a/src/gallium/drivers/swr/ras
Needed to compensate for change to fetch jit requiring
alignment.
Fixes regressions in piglit: vertex-buffer-offsets and about
another hundred of the vs-input*byte* tests.
---
src/gallium/drivers/swr/swr_screen.cpp | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/g
---
src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py | 1 +
src/gallium/drivers/swr/rasterizer/jitter/fetch_jit.cpp | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/swr/rasterizer/codegen/gen_llvm_ir_macros.py
b/src/gallium/dr
---
.../rasterizer/codegen/templates/gen_ar_eventhandlerfile.hpp | 4 ++--
src/gallium/drivers/swr/rasterizer/core/fifo.hpp | 4 ++--
src/gallium/drivers/swr/rasterizer/core/pa.h | 12 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git
a/src/
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #27 from Kai ---
(In reply to Kai from comment #26)
> [...]
>
> The full stack used (fully updated Debian testing as a base) was:
> GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
> Mesa: Git:master/39a69f0692
> libdrm: 2.4.82-1
>
https://bugs.freedesktop.org/show_bug.cgi?id=95346
Kai changed:
What|Removed |Added
Attachment #130866|0 |1
is obsolete||
Am 05.09.2017 um 19:37 schrieb Leo Liu:
Fixes:7319ff87("radeon/uvd: add YUYV format support for target buffer")
Signed-off-by: Leo Liu
Reviewed-by: Christian König
---
src/gallium/drivers/radeon/radeon_uvd.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src
On Tue, Sep 5, 2017 at 10:25 AM, Emil Velikov
wrote:
> Hi Jason,
>
> On 5 September 2017 at 16:48, Jason Ekstrand wrote:
> > For non-CCS images, we were reporting just one plane even though they
> > may have multiple in the case of YUV.
> >
> > Reviewed-by: Ben Widawsky
> I think we want this f
On Tue, Sep 5, 2017 at 10:14 AM, Emil Velikov
wrote:
> Hi Jason,
>
> On 5 September 2017 at 16:48, Jason Ekstrand wrote:
>
> > + GLboolean (*queryDmaBufFormatModifierAttribs)(__DRIscreen *screen,
> > + uint32_t fourcc,
> We seems to be using "int
On Tue, Sep 5, 2017 at 9:56 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> When the HS wave is empty, the hardware writes the LS VGPRs starting at
> v0 instead of v2. Workaround by shifting them back into place when
> necessary. For simplicity, this is always done in the LS prolog.
>
> Acco
https://bugs.freedesktop.org/show_bug.cgi?id=95346
--- Comment #25 from Gert Wollny ---
Created attachment 133972
--> https://bugs.freedesktop.org/attachment.cgi?id=133972&action=edit
screenshot on r600g with mesa-git43e8808b8
I've tested the trace on r600g and also in software mode on mesa gi
On 5 September 2017 at 15:51, Rob Herring wrote:
> On Tue, Sep 5, 2017 at 9:23 AM, Emil Velikov wrote:
>> From: Emil Velikov
>>
>> Former is non-deterministic and compilers throw a warning about it.
>>
>> Cc: Rob Herring
>> Signed-off-by: Emil Velikov
>> ---
>> I think the patch is a good idea
From: Emil Velikov
v2: Use correct 17.1.10 version, adjust some names.
Cc: Juan A. Suárez
Cc: Andres Gomez
Signed-off-by: Emil Velikov
Reviewed-by: Eric Engestrom
---
docs/release-calendar.html | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff -
Fixes:7319ff87("radeon/uvd: add YUYV format support for target buffer")
Signed-off-by: Leo Liu
---
src/gallium/drivers/radeon/radeon_uvd.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.
Hi Jason,
On 5 September 2017 at 16:48, Jason Ekstrand wrote:
> For non-CCS images, we were reporting just one plane even though they
> may have multiple in the case of YUV.
>
> Reviewed-by: Ben Widawsky
I think we want this for stable, right?
The series looks good, FWIW
Reviewed-by: Emil Velik
https://bugs.freedesktop.org/show_bug.cgi?id=102502
--- Comment #2 from Alexandre Demers ---
The other segfault has been reported as bug 102530. However, they seem
unrelated. Also, bug 102530 may aleready have been fixed, but I can't confirm
until the current bug is fixed or the patch is reverted
Hi Jason,
On 5 September 2017 at 16:48, Jason Ekstrand wrote:
> + GLboolean (*queryDmaBufFormatModifierAttribs)(__DRIscreen *screen,
> + uint32_t fourcc,
We seems to be using "int fourcc" throughout the file. Worth saying
consistent and doing the
On Tue, Sep 5, 2017 at 5:50 PM, Brian Paul wrote:
> On 09/04/2017 05:29 AM, Marek Olšák wrote:
>>
>> On Sun, Sep 3, 2017 at 1:18 PM, Dave Airlie wrote:
>>>
>>> From: Dave Airlie
>>>
>>> reduces size from 1144 to 1128.
>>>
>>> Signed-off-by: Dave Airlie
>>> ---
>>> src/mesa/main/mtypes.h | 10
On 5 September 2017 at 12:48, Tapani Pälli wrote:
> This was used by EGL_MESA_screen_surface that has been removed
> in commit 7a58262e58d8edac3308777def0950032628edee.
>
> Signed-off-by: Tapani Pälli
Reviewed-by: Emil Velikov
-Emil
___
mesa-dev maili
https://bugs.freedesktop.org/show_bug.cgi?id=102038
Brad King changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=102038
--- Comment #19 from Bruce Cherniak ---
The swr driver patch has been committed, as well.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
On 5 September 2017 at 16:50, Brian Paul wrote:
>
>
> There's lots of opportunities along these lines in gl_texture_image. And
> since we often have many gl_texture_images per gl_texture_object, and we
> often have many textures, it'll probably have considerable impact. I've
> suggested this in
2017-09-05 17:50 GMT+02:00 Brian Paul :
> On 09/04/2017 05:29 AM, Marek Olšák wrote:
>>
>> On Sun, Sep 3, 2017 at 1:18 PM, Dave Airlie wrote:
>>>
>>> From: Dave Airlie
>>>
>>> reduces size from 1144 to 1128.
>>>
>>> Signed-off-by: Dave Airlie
>>> ---
>>> src/mesa/main/mtypes.h | 10 +-
https://bugs.freedesktop.org/show_bug.cgi?id=102038
--- Comment #18 from Brian Paul ---
The state tracker patch has been committed.
I'll leave the swr driver patch to Bruce.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
On 05/09/17 17:01, srol...@vmware.com wrote:
From: Roland Scheidegger
Trivial. We already support tg4 for legacy tex opcodes, so the actual
texture sampling code already handles it.
(Just like TG4, we don't handle additional capabilities and always sample
red channel.)
---
src/gallium/auxilia
From: Roland Scheidegger
Trivial. We already support tg4 for legacy tex opcodes, so the actual
texture sampling code already handles it.
(Just like TG4, we don't handle additional capabilities and always sample
red channel.)
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 28 ++
On Tue, Sep 5, 2017 at 8:33 AM, Connor Abbott wrote:
> As a quick drive-by, yeah, I noticed this too, and it's going to
> require fixes to radv to not break things since none of the other NIR
> opcodes are hooked up (this will be needed for the NIR path in
> radeonsi too, since GLSL-to-NIR alread
On 09/04/2017 05:29 AM, Marek Olšák wrote:
On Sun, Sep 3, 2017 at 1:18 PM, Dave Airlie wrote:
From: Dave Airlie
reduces size from 1144 to 1128.
Signed-off-by: Dave Airlie
---
src/mesa/main/mtypes.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/ma
For non-CCS images, we were reporting just one plane even though they
may have multiple in the case of YUV.
Reviewed-by: Ben Widawsky
---
src/mesa/drivers/dri/i965/intel_screen.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
---
src/mesa/drivers/dri/i965/intel_screen.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index ace244f..3217fee 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.
This allows the user to query the number of planes required by a given
format+modifier combination without having to create a bo or surface.
---
src/gbm/backends/dri/gbm_dri.c | 26 ++
src/gbm/main/gbm.c | 14 ++
src/gbm/main/gbm.h | 5 +
This is mostly just a re-send of the original patch series I sent out only
with a couple of reviews and fixes applied. I'm happy with it and I think
Daniel can confirm that it fixes the problem we're having in modesetting
when trying to enable CCS. Anyone opposed?
Jason Ekstrand (4):
dri/image
---
include/GL/internal/dri_interface.h | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 1c91bde..783ff1c 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/G
As a quick drive-by, yeah, I noticed this too, and it's going to
require fixes to radv to not break things since none of the other NIR
opcodes are hooked up (this will be needed for the NIR path in
radeonsi too, since GLSL-to-NIR already uses those opcodes).
On Tue, Sep 5, 2017 at 11:13 AM, Jason
On Tue, 2017-09-05 at 15:21 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Cc: Andres Gomez
> Signed-off-by: Emil Velikov
> ---
> docs/release-calendar.html | 27 +--
> 1 file changed, 13 insertions(+), 14 deletions(-)
>
> diff --git a/docs/release-calendar.html b
Most of NIR doesn't allow doing array indexing on a vector (though it
does on a matrix). However, nir_lower_io handles it just fine and this
behavior is needed for shared variables in Vulkan. This commit makes
glsl_get_array_element do something sensible for vector types and makes
nir_validate ha
1 - 100 of 184 matches
Mail list logo
