On 03/20/2017 03:37 AM, Rob Herring wrote:
On Thu, Mar 16, 2017 at 8:34 AM, Emil Velikov wrote:
On 13 March 2017 at 22:36, Mauro Rossi wrote:
2017-03-13 14:00 GMT+01:00 Emil Velikov :
On 12 March 2017 at 23:01, Mauro Rossi wrote:
Automake generation rules are replicated for android.
$*
> -Original Message-
> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> Behalf Of Xu, Randy
> Sent: Monday, March 20, 2017 2:41 PM
> To: Palli, Tapani ; Emil Velikov
> ; Landwerlin, Lionel G
>
> Cc: ML mesa-dev ; x...@freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] Vul
From: Xu Randy
We should use anv_get_layerCount() to access layerCount of VkImageSub-
resourceRange in anv_CmdClearColorImage and anv_CmdClearDepthStencil-
Image, which handles the VK_REMAINING_ARRAY_LAYERS (~0) case.
Test: Sample multithreadcmdbuf from LunarG can run without crash
Signed-off-b
https://bugs.freedesktop.org/show_bug.cgi?id=100091
--- Comment #26 from John ---
Timothy, do you have any patch you'd like me to test?
Thanks!
John
--
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=100075
--- Comment #3 from Julien Isorce ---
Thx Gurkirpal, this time the backtrace looks different than the gst bug I
pointed above.
I get the same result with AMD, dri/radeonsi_drv_video.so . Note it crashes
with RGBx and BGRx but not with RGBA and
series is
Reviewed-by: Tapani Pälli
On 03/20/2017 03:33 AM, Rob Herring wrote:
This is a series of clean-ups and fixes to get Mesa master building on
AOSP master again. AOSP master recently changed from X.Y.Z versioning to
just the letter commonly used. Primarily, dropping KitKat and earlier
su
I added this flag in 65a9d5eabb05e4925c1c9a17836cad57304210d6 but
it was completely unused. Both callers appear to have printed dword
headers, so we can just drop the flag and continue doing it
unconditionally.
---
src/intel/tools/aubinator.c | 9 -
1 file changed, 4 insertions(+), 5 dele
Hello,
This series makes INTEL_DEBUG=bat use the aubinator/genxml infrastructure
for decoding batches (both commands and states). It's not perfect, but
it should be significantly more usable than the old code. Our public
batch command decoder in libdrm is woefully unmaintained, as is our own
brw
gen_field_iterator_next() produces a string representing the value of
the field. For enum values, it also produced a separate "description"
string containing the textual name of the enum.
The only caller of this function combines the two, printing enums as
" ()". We may as well just store
that i
No longer necessary - the iterator gets it from the group.
---
src/intel/tools/aubinator.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 0c941322d68..739e95493b6 100644
--- a/src/intel
The iterator code already computed this value, then we stored it in
the structure name, strtok'd it back out, and also manually computed
it when printing dword headers.
Just put the value in the struct and use it. Way simpler.
---
src/intel/tools/aubinator.c | 35 +---
When the iterator encounters a structure field, it now looks up the
gen_group for that structure definition and saves a pointer to it.
This lets us drop a lot of ridiculous code in the caller, which looked
at item->value (), strtok'd the structure name back
out, and looked it up itself.
---
src/i
This should give substantially better decoding, as the public libdrm
decoder hasn't been properly maintained in years.
For now, we reuse the existing state dumping mechanism. We'll improve
that in the next patch.
---
src/mesa/drivers/dri/i965/Makefile.am | 1 +
src/mesa/drivers/dri/i965
When decoding a structure field within a group, we may want to look up
that structure type. Having a gen_spec pointer makes it easy to do so.
---
src/intel/tools/decoder.c | 1 +
src/intel/tools/decoder.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/intel/tools/decoder.c b/src/intel/
This deletes all of our handwritten code in favor of autogenerated
genxml-based decoding. This should be much more usable, as the old
code isn't entirely accurate - we updated some things for new
generations, but not everything.
Aubinator has one annoying limitation: it has no idea how many entri
It made more sense when decode_group() took a bunch of extra options,
but now that there's only one...we may as well pass 0 and call it a day.
---
src/intel/tools/aubinator.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/src/intel/tools/aubinator.c
This will be used for color output in debug messages.
---
docs/envvars.html| 1 +
src/intel/common/gen_debug.c | 1 +
src/intel/common/gen_debug.h | 1 +
3 files changed, 3 insertions(+)
Use less -FRS with INTEL_DEBUG=color,bat
diff --git a/docs/envvars.html b/docs/envvars.html
index
This lets us use it outside of the aubinator binary itself.
---
src/intel/tools/aubinator.c | 34 +++---
src/intel/tools/decoder.c | 34 ++
src/intel/tools/decoder.h | 5 +
3 files changed, 42 insertions(+), 31 deletions(-)
diff
From: Matt Turner
On IVB/BYT, region parameters and execution size for DF are in terms of
32-bit elements, so they are doubled. For evaluating the validity of an
instruction, we halve them.
v2 (Sam):
- Add comments.
Reviewed-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_eu_validate
Hi,
This series implements initial support for Ivybridge FP64 for both
align16 and align1 backends, and with that we can enable FP64 and
OpenGL 4.0 in Ivybridge.
These patches are available in our repository for testing. You can
clone it using the following command:
$ git clone -b i965-fp64-gen
From: Iago Toral Quiroga
4-wide DF operations where NibCtrl applies require and execsize of 8
in IvyBridge/BayTrail.
v2:
- Refactor NibCtrl printing (Matt)
Reviewed-by: Matt Turner
Reviewed-by: Francisco Jerez
---
src/intel/compiler/brw_disasm.c | 6 +++---
1 file changed, 3 insertions(+), 3
From: "Juan A. Suarez Romero"
The execution data size is the biggest type size of any instruction
operand.
We will use it to know if the instruction deals with DF, because in Ivy
we need to double the execution size and regioning parameters.
v2:
- Fix typo in commit log (Matt)
- Use static inli
From: Matt Turner
On HSW+, scalar DF sources can be accessed using the normal <0,1,0>
region, but on IVB and BYT DF regions must be programmed in terms of
floats. A <0,2,1> region accomplishes this.
v2:
- Apply region <0,2,1> in brw_reg_from_fs_reg() (Curro).
v3:
- Added comment explaining the
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/Makefile.sources | 2 +-
src/intel/compiler/brw_fs.cpp | 2 +-
src/intel/compiler/brw_fs.h | 2 +-
.../{brw_fs_
From: Matt Turner
Doing so allows us to use a single MOV in VEC4_OPCODE_TO_DOUBLE instead
of two.
Reviewed-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_eu_emit.c | 28 +++-
src/intel/compiler/brw_vec4_generator.cpp | 13 +
2 files change
From: Francisco Jerez
Reviewed-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs_generator.cpp | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/src/intel/compiler/brw_fs_generator.cpp
b/src/intel/compiler/brw_fs_generator.cpp
index 9e53
From: "Juan A. Suarez Romero"
According to the IVB and HSW PRMs:
"2.When the destination requires two registers and the sources are
indirect, the sources must use 1x1 regioning mode."
So for DF instructions the execution size is not limited by the number
of address registers that are available
From: "Juan A. Suarez Romero"
When converting a DF to 32-bit conversions, we set dst stride to 2,
to fulfill alignment restrictions because the upper Dword of every
Qword will be written with undefined value.
But in IVB/BYT, this is not necessary, as each DF conversion already
writes 2, the firs
The hardware applies the same channel enable signals to both halves of
the compressed instruction which will be just wrong under non-uniform
control flow. Fix this by splitting those instructions to SIMD4.
Signed-off-by: Samuel Iglesias Gonsálvez
Reviewed-by: Francisco Jerez
---
src/intel/compi
Then the SIMD lowering pass will get rid of any compressed instructions with
scalar
source (whether force_writemask_all or not) and we avoid hitting the Gen7 region
decompression bug.
Signed-off-by: Samuel Iglesias Gonsálvez
Suggested-by: Francisco Jerez
Reviewed-by: Francisco Jerez
---
src/i
Generalize it to lower any unsupported narrower conversion.
v2 (Curro):
- Add supports_type_conversion()
- Reuse existing intruction instead of cloning it.
- Generalize d2x to narrower and equal size conversions.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs.cpp
We need to split DF instructions in two on IVB/BYT as it needs an
execsize 8 to process 4 DF values (one GRF in total).
v2:
- Rename helper and make it static inline function (Matt).
- Fix indention and add braces (Matt).
v3:
- Don't edit IR instruction when doubling exec_size (Curro)
- Add comme
From: "Juan A. Suarez Romero"
In IVB and BYT, both regioning parameters and execution sizes are measured as
32-bits element size.
So when we have something like:
mov(8) g2<1>DF g3<4,4,1>DF
We are not actually moving 8 doubles (our intention), but 4 doubles.
We need to double the parameters to
On IVB, DF instructions have lowered the SIMD width to 4 but the
exec_size will be later doubled. Fix the assert to avoid crashing in
this case.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_vec4_generator.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/co
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_vec4.h | 3 ++-
src/intel/compiler/brw_vec4_nir.cpp | 15 ---
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/src/intel/compiler/brw_vec4.h b/src/intel/compiler/brw_vec4.h
index d12405c22e1..fea
Now the VEC4_OPCODE_FROM_DOUBLE's destination data is written with
stride 2. We need to take into account this when doing the split
so we don't overwrite data.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_vec4.cpp | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
This is required for correctness in presence of multiple 4-wide flag
writes (e.g. 4-wide instructions with a conditional mod set) which
update a different portion of the same 8-bit flag subregister.
Right now we keep track of flag dataflow with 8-bit granularity and
consider flag writes to have ki
horiz_offset() doesn't make sense to destination registers on some
cases like null registers.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_ir_vec4.h | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_ir_vec4.h
From: Matt Turner
In commit c35fa7a, we changed the "width" of DF source registers to 2,
which is conceptually fine. Unfortunately a VertStride of 2 is not
allowed by align16 instructions on IVB/BYT, and the regular VertStride
of 4 works fine in any case.
See
generated_tests/spec/arb_gpu_shader
From: Matt Turner
Otherwise for a pack_double_2x32_split opcode, we emit:
vec1 64 ssa_135 = pack_double_2x32_split ssa_133, ssa_134
mov(8) g5<1>UD g5<4>.xUD { align16 1Q
compacted };
mov(8) g7<2>UD g5<4,4,1>UD { alig
From: "Juan A. Suarez Romero"
Keep the original type when dealing with null registers. Especially
because we do no want to introduce an implicit conversion between
types that could affect the conditional flags.
This affects especially when the original type is DF, and we are working
on Ivybridge
When doing a 64-bit to a smaller data type size conversion, the destination
should
be aligned to 64-bits. Because of that, we need to gather the data after the
actual conversion.
Until now, these two operations were done by VEC4_OPCODE_FROM_DOUBLE but
now we split them explicitely in two differen
Signed-off-by: Samuel Iglesias Gonsálvez
Reviewed-by: Francisco Jerez
---
src/mesa/drivers/dri/i965/intel_extensions.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_extensions.c
index 30f2c37695
From: "Juan A. Suarez Romero"
Take into account offset values less than a full register (32 bytes)
when getting the var from register.
This is required when dealing with an operation that writes half of the
register (like one d2x in IVB/BYT, which uses exec_size == 4).
v2:
- Take in account thi
From: "Juan A. Suarez Romero"
In the generator we must generate slightly different code for
Ivybridge/Baytrail, because of the way the stride works in
this hardware.
v2:
- Use stride and don't need to fix dst (Curro)
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_vec4_gen
Signed-off-by: Samuel Iglesias Gonsálvez
Acked-by: Francisco Jerez
---
docs/features.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/features.txt b/docs/features.txt
index b4e54a7d1a5..d34bef157c8 100644
--- a/docs/features.txt
+++ b/docs/features.txt
@@ -107,7 +
Signed-off-by: Samuel Iglesias Gonsálvez
Reviewed-by: Francisco Jerez
---
src/mesa/drivers/dri/i965/intel_extensions.c | 2 ++
src/mesa/drivers/dri/i965/intel_screen.c | 6 --
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/s
Recent change to use drmGetDevices2() made me realize that
build configured using
PKG_CONFIG_PATH=my_drm_lib_path/pkgconfig ./autogen.sh
considers the libdrm path gotten from pkgconfig only during
make. When invoking "make install" the relink command puts
system library ahead of the path gotten f
It doesn't hang here with RadeonSI although I didn't test a lot. Now,
the game should just start as-is without any override envvars.
On 03/19/2017 01:31 AM, Ernst Sjöstrand wrote:
Are you sure? I still need the workaround, otherwise the game hangs
very quickly.
2017-03-15 15:13 GMT+01:00 Samue
On Mon, Mar 20, 2017 at 11:28 AM, Topi Pohjolainen
wrote:
> Recent change to use drmGetDevices2() made me realize that
> build configured using
>
> PKG_CONFIG_PATH=my_drm_lib_path/pkgconfig ./autogen.sh
>
> considers the libdrm path gotten from pkgconfig only during
> make. When invoking "make ins
On 20/03/17 09:13, Kenneth Graunke wrote:
gen_field_iterator_next() produces a string representing the value of
the field. For enum values, it also produced a separate "description"
string containing the textual name of the enum.
The only caller of this function combines the two, printing enums
Hello Constantine,
1/1
- rebase needed
- line wrap needed
apart from that:
Tested-by: Dieter Nützel
1/2
Acked-by: Dieter Nützel
@Marek:
There are several r600/r600g patches/fixes floating around.
I'll try to test all and who is responsible for them (r600g) and commit
them later on?
Greetin
Tested-by: Dieter Nützel
Am 17.03.2017 10:25, schrieb Gregory Hainaut:
Improve speed on PCSX2
v2:
Add ppbo/ubpo status in XML file
Disable variable parameter (as the pointer would be a fixed offset)
Signed-off-by: Gregory Hainaut
---
src/mapi/glapi/gen/ARB_direct_state_access.xml | 16 +
Hello Constantine,
rebase again, please?
Shouldn't we try to land?
Thanks,
Dieter
Am 23.02.2017 22:00, schrieb Constantine Charlamov:
The author is Heiko Przybyl(CC'ing), the patch is rebased on top of
Bartosz Tomczyk's one per Dieter Nützel's comment.
Tested-by: Constantine Charlamov
--
Mesa 13.0.6 is now available.
Note: this is the final anticipated release in the 13.0 series. Users are
encouraged to migrate to the 17.0 series in order to obtain future fixes.
In this release we have:
On the GLX/EGL front we have crash fixes in GLX/DRI3, ResetNotificationStrategy
matches the s
Hello Bartosz,
can you please rebase?
I think this could land.
Thanks,
Dieter
Am 08.02.2017 17:16, schrieb Bartosz Tomczyk:
fc_sp variable should indicate number of elements in
fc_stack array, but fc_sp was increased at beginning of fc_pushlevel
function. It leads to situation where idx=0 was
Do not initialize counter inside 'for' loop to fix the following build errors
on mips64el:
cube-tex.c: In function 'get_fd_rgba':
cube-tex.c:230:2: error: 'for' loop initial declarations are only allowed in
C99 mode
for (uint32_t i = 0; i < texh; i++) {
^
cube-tex.c:230:2: note: use option -s
https://bugs.freedesktop.org/show_bug.cgi?id=98604
--- Comment #14 from Dieter Nützel ---
Any progress?
Michel?
DRI2 vs DRI3
Wouldn't it be nice to have this in 7.1?
--
You are receiving this mail because:
You are on the CC list for the bug.___
mesa
Patches 2-11 are :
Reviewed-by: Lionel Landwerlin
On 20/03/17 09:13, Kenneth Graunke wrote:
Hello,
This series makes INTEL_DEBUG=bat use the aubinator/genxml infrastructure
for decoding batches (both commands and states). It's not perfect, but
it should be significantly more usable than the
On 20 March 2017 at 09:13, Kenneth Graunke wrote:
> This should give substantially better decoding, as the public libdrm
> decoder hasn't been properly maintained in years.
>
> For now, we reuse the existing state dumping mechanism. We'll improve
> that in the next patch.
Can you share the size o
The second check in the old code looked pretty much unreachable, esp.
because it's not obvious that "max_entries" could be zero. To find out
that it was intentional I had to run some checks, and to dig into
the old versions of the file.
So, rewrite the check to make the intention clear.
v2: s/r60
v2: s/r600/r600g in the title
Signed-off-by: Constantine Kharlamov
---
src/gallium/drivers/r600/sb/notes.markdown | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/notes.markdown
b/src/gallium/drivers/r600/sb/notes.markdown
index 056497754a
I resent, though the rebase is unneeded, r600_asm.c didn't see a change for
more than year.
On 20.03.2017 14:45, Dieter Nützel wrote:
> Hello Constantine,
>
> 1/1
> - rebase needed
> - line wrap needed
> apart from that:
> Tested-by: Dieter Nützel
>
> 1/2
> Acked-by: Dieter Nützel
>
> @Marek
On Sun, Mar 19, 2017 at 10:09 PM, Chih-Wei Huang
wrote:
> 2017-03-20 9:33 GMT+08:00 Rob Herring :
>> Any users of KitKat are likely using an older version of Mesa and
>> KitKat support adds complexity to the make files. Dropping support
>> allows removing the MESA_LOLLIPOP_BUILD make variable in v
The patch still applies to master, rebase is unneeded.
On 20.03.2017 14:53, Dieter Nützel wrote:
> Hello Constantine,
>
> rebase again, please?
> Shouldn't we try to land?
>
> Thanks,
> Dieter
>
> Am 23.02.2017 22:00, schrieb Constantine Charlamov:
>> The author is Heiko Przybyl(CC'ing), the pa
On 20.03.2017 14:53, Dieter Nützel wrote:
> Hello Constantine,
>
> rebase again, please?
> Shouldn't we try to land?
Sorry, forgot to addres this. Yes, the patch is nice, I am running the
system with the patch since its first revision, everything is fine.
> Thanks,
> Dieter
>
> Am 23.02.2017 2
Do not declare counter inside 'for' loop to fix the following build errors
on mips64el:
cube-tex.c: In function 'get_fd_rgba':
cube-tex.c:230:2: error: 'for' loop initial declarations are only allowed in
C99 mode
for (uint32_t i = 0; i < texh; i++) {
^
cube-tex.c:230:2: note: use option -std=
Constantine,
you missed my
1/1
Tested-by: Dieter Nützel
1/2
Acked-by: Dieter Nützel
they should be appended under your Signed-off-by during resend/rebase.
Anyway, looks good.
Dieter
PS ...Dieter's comment... is enough ;-)
Am 20.03.2017 13:19, schrieb Constantine Kharlamov:
The second check
Aah, I see… Should I resend again?
On 20.03.2017 15:40, Dieter Nützel wrote:
> Constantine,
> you missed my
>
> 1/1
> Tested-by: Dieter Nützel
> 1/2
> Acked-by: Dieter Nützel
>
> they should be appended under your Signed-off-by during resend/rebase.
>
> Anyway, looks good.
> Dieter
>
> PS ..
On 03/19/2017 11:21 PM, Emil Velikov wrote:
On 19 March 2017 at 19:30, Jason Ekstrand wrote:
On March 19, 2017 9:33:02 AM Grazvydas Ignotas wrote:
On Sun, Mar 19, 2017 at 3:03 PM, Emil Velikov
wrote:
Hi Grazvydas,
On 17 March 2017 at 22:05, Grazvydas Ignotas wrote:
Fixes build witho
Am 20.03.2017 13:43, schrieb Constantine Kharlamov:
Aah, I see… Should I resend again?
Mhhhmmm,
I think it should be smarter for the committer and I do not have that
right ;-)
Marek your turn?
Who is the 'man' for older cards?
On 20.03.2017 15:40, Dieter Nützel wrote:
Constantine,
you mis
On 14.03.2017 03:08, Timothy Arceri wrote:
Otherwise we will always remove old cache entries from the same dirs.
Seeding the global RNG from within a driver is a no-no as others pointed
out. I'd suggest you extract the xorshift128plus generator from
r600_test_dma.c into a common utility and u
On 17.03.2017 18:59, gregory hainaut wrote:
On Fri, 17 Mar 2017 13:11:31 +0100
Markus Wick wrote:
Hi gregory,
Am 2017-03-17 10:25, schrieb Gregory Hainaut:
diff --git a/src/mesa/main/marshal.c b/src/mesa/main/marshal.c
index f8cad30..43a70d4 100644
--- a/src/mesa/main/marshal.c
+++ b/src/mes
Seems like we ended up all over the place, so let me try afresh.
Above all:
- Saying "I don't care" about your users is arrogant - let us _not_
do that, please ?
Even Linux distribution maintainers have responded that "upstream does
not care us", which is indicative that we should be more careful
Mesa 17.0.2 is now available.
In this release we have:
One dozen fixes in each of the Vulkan drivers - ANV and RADV. Misc.
Improvements in the i965, nouveau (nvc0) and radeons drivers.
To top it up we have a build fix for the clover (OpenCL) state-tracker.
Alex Smith (3):
radv: Emit pend
On Sun, Mar 19, 2017 at 9:49 AM, Christian König
wrote:
> Hi Peter,
>
> Adding Michel and Marek for the Mesa interop side and Harry for the display
> side.
>
> How do you want us to display the decoded surfaces?
>
> Well to make a long story short: I don't have the slightest idea. Ideally we
> wou
https://bugs.freedesktop.org/show_bug.cgi?id=97260
--- Comment #69 from Alex Deucher ---
(In reply to Alex Deucher from comment #68)
> The firmware was fixed a while ago. Please make sure your distro is using
> the latest firmware.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
https://bugs.freedesktop.org/show_bug.cgi?id=97260
--- Comment #68 from Alex Deucher ---
The firmware was fixed a while ago. Please make sure your distro is using the
latest firmware.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug._
On 17 March 2017 at 19:38, Jason Ekstrand wrote:
> On Fri, Mar 17, 2017 at 11:07 AM, Emil Velikov
> wrote:
>>
>> Hello list,
>>
>> The candidate for the Mesa 17.0.2 is now available. Currently we have:
>> - 42 queued
>> - 3 nominated (outstanding)
>> - and 1 rejected patch(es)
>>
>>
>> Current
On 20/03/17 12:14, Emil Velikov wrote:
On 20 March 2017 at 09:13, Kenneth Graunke wrote:
This should give substantially better decoding, as the public libdrm
decoder hasn't been properly maintained in years.
For now, we reuse the existing state dumping mechanism. We'll improve
that in the nex
On 8 March 2017 at 18:11, Emil Velikov wrote:
> On 7 March 2017 at 21:14, Dylan Baker wrote:
>> There are a number of small style cleanups and simplifications in this
>> series,
>> but the main changes are:
>> - use a mako template to generate the header and code rather than prints
>> - be pyt
On 20 March 2017 at 15:07, Lionel Landwerlin
wrote:
> On 20/03/17 12:14, Emil Velikov wrote:
>>
>> On 20 March 2017 at 09:13, Kenneth Graunke wrote:
>>>
>>> This should give substantially better decoding, as the public libdrm
>>> decoder hasn't been properly maintained in years.
>>>
>>> For now,
From: Emil Velikov
Spotted while skimming through similar hunks for the Autotools build.
Cc: Tapani Pälli
Signed-off-by: Emil Velikov
---
Tapani, can you throw this on the back-burner - I'm 99% sure that its
dead.
---
src/intel/Android.vulkan.mk | 1 -
1 file changed, 1 deletion(-)
diff --gi
From: Emil Velikov
At the moment, we would honour any system headers - vulkan_intel.h in
particular over the ones in-tree.
Thus, if one does inclemental build of mesa, without the vulkan.h
already installed (or at least not in the same directory as
vulkan_intel.h) the build will fail.
In the fu
On Mon, Mar 20, 2017 at 8:17 AM, Emil Velikov
wrote:
> On 20 March 2017 at 15:07, Lionel Landwerlin
> wrote:
> > On 20/03/17 12:14, Emil Velikov wrote:
> >>
> >> On 20 March 2017 at 09:13, Kenneth Graunke
> wrote:
> >>>
> >>> This should give substantially better decoding, as the public libdrm
Reviewed-by: Marek Olšák
Marek
On Thu, Mar 16, 2017 at 3:25 PM, Julien Isorce wrote:
> Like in a few other places in that radeon_drm_bo.c file.
>
> CID 715739.
>
> Signed-off-by: Julien Isorce
> ---
> src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 de
NAK. sscreen is never NULL here.
Marek
On Thu, Mar 16, 2017 at 3:25 PM, Julien Isorce wrote:
> CID 1354483
>
> Signed-off-by: Julien Isorce
> ---
> src/gallium/drivers/radeonsi/si_pipe.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/drivers/r
Reviewed-by: Marek Olšák
Marek
On Thu, Mar 16, 2017 at 3:25 PM, Julien Isorce wrote:
> CID 1313492
>
> Signed-off-by: Julien Isorce
> ---
> src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/winsys/radeon
NAK. zstex can't be NULL here. It's a false coverity defect.
db_depth_clear and db_stencil_clear can be true only if zstex is non-NULL.
Marek
On Thu, Mar 16, 2017 at 3:25 PM, Julien Isorce wrote:
> Few lines before there is a if (zstex && zstex->htile_buffer ...)
> which tells that there are so
Reviewed-by: Marek Olšák
Marek
On Thu, Mar 16, 2017 at 3:25 PM, Julien Isorce wrote:
> CID 1399479: Dereference before null check (REVERSE_INULL)
> check_after_deref: Null-checking velems suggests that it may be null,
> but it has already been dereferenced on all paths leading to the check.
>
>
From: Marek Olšák
This should fix OpenCL getting stuck.
---
src/gallium/drivers/radeonsi/si_compute.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index ed02f49..19a9189 100644
--- a/
Include to fix the following build error seen on mips64el:
drm-legacy.c: In function 'legacy_run':
drm-legacy.c:45:2: error: unknown type name 'fd_set'
fd_set fds;
^
drm-legacy.c:55:2: warning: implicit declaration of function 'FD_ZERO'
[-Wimplicit-function-declaration]
FD_ZERO(&fds);
^
Nit:
Subject: Android: kill off {MESA_}ANDROID_VERSION defines aka Android
4.1 and older
On 20 March 2017 at 01:33, Rob Herring wrote:
> The Android version defines are only needed for versions less than 4.2
> which aren't really supported or tested.
>
> Signed-off-by: Rob Herring
> ---
> Andr
On Sun, Mar 19, 2017 at 2:49 PM, Christian König
wrote:
> Hi Peter,
>
> Adding Michel and Marek for the Mesa interop side and Harry for the display
> side.
>
> How do you want us to display the decoded surfaces?
>
> Well to make a long story short: I don't have the slightest idea. Ideally we
> wou
On 20 March 2017 at 01:33, Rob Herring wrote:
> Any users of KitKat are likely using an older version of Mesa and
> KitKat support adds complexity to the make files. Dropping support
> allows removing the MESA_LOLLIPOP_BUILD make variable in various make
> files.
>
Please mention why we're safe t
On 20 March 2017 at 01:33, Rob Herring wrote:
> LLVM enabled builds are broken with AOSP master. If building all targets
> using "mmma external/mesa3d", the libmesa_amd_common will get built and
> fail due to LLVM dependencies. Fix this by making it dependent on
> MESA_ENABLE_LLVM.
>
> Signed-off-
For the series:
Reviewed-by: Marek Olšák
Marek
On Fri, Mar 17, 2017 at 1:06 AM, Samuel Pitoiset
wrote:
> Game ported from D3D9 which expects sqrt() to compute the absolute
> value as explained in the spec.
>
> This gets rid of the NaN values as well as the black squares
> with RadeonSI.
>
> Bu
Should I remove
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeonsi/si_pipe.c#n687
then ? (if (!sscreen) return;)
On 20 March 2017 at 15:29, Marek Olšák wrote:
> NAK. sscreen is never NULL here.
>
> Marek
>
> On Thu, Mar 16, 2017 at 3:25 PM, Julien Isorce
> wrote:
> > CID
Pushed the series. Thanks.
Marek
On Mon, Mar 20, 2017 at 1:19 PM, Constantine Kharlamov
wrote:
> v2: s/r600/r600g in the title
>
> Signed-off-by: Constantine Kharlamov
> ---
> src/gallium/drivers/r600/sb/notes.markdown | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff -
On Mon, Mar 20, 2017 at 5:11 PM, Julien Isorce wrote:
> Should I remove
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeonsi/si_pipe.c#n687
> then ? (if (!sscreen) return;)
Yeah, that can be removed.
Marek
>
> On 20 March 2017 at 15:29, Marek Olšák wrote:
>>
>> NAK. ssc
1 - 100 of 342 matches
Mail list logo
