Correction, we just need someone to mark all the comitted patches in
patchwork so that we can easily pick out the ones with issues.
On 7 September 2015 at 04:56, Albert Freeman wrote:
> Oops, my "plan" focuses on patches that have nothing wrong with them,
> instead of patches that have something
Oops, my "plan" focuses on patches that have nothing wrong with them,
instead of patches that have something wrong with them (which is the
problem). It is lack of reviews, not lack of commits. I have no idea
how I got so confused. Basically we need the inverse of patchwork.
On 6 September 2015 at
https://bugs.freedesktop.org/show_bug.cgi?id=91826
--- Comment #8 from Albert Freeman ---
Sorry, I just realised this is my fault. The patch has been reviewed, but due
to bad formatting of the subject line/commit message it has not been committed.
The fix should be in by next release.
--
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=91898
--- Comment #2 from Ilia Mirkin ---
This should resolve the issue:
http://patchwork.freedesktop.org/patch/58800/
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
My earlier attempt to fix this missed the fact that there was a #else
clause that assumes that you have openssh. This moves the whole thing
under #ifdef HAVE_SHA1 which should avoid this issue.
Fixes: 13bfa5201 (util: always include sha1 into the build)
Bugzilla: https://bugs.freedesktop.org/show_
This patch is necessary to avoid building error on android,
due to missing sid_tables.h generated sources
---
src/gallium/drivers/radeonsi/Android.mk | 13 -
src/gallium/drivers/radeonsi/Makefile.sources | 3 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/src
On 7 September 2015 at 08:17, Marek Olšák wrote:
> From: Marek Olšák
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91881
Might be nice to say where the regression happened in the commit, and
why we shouldn't be using the buffer size.
Otherwise,
Reviewed-by: Dave Airlie
>
> Cc: 11.
https://bugs.freedesktop.org/show_bug.cgi?id=91793
--- Comment #2 from YuGiOhJCJ ---
You mean mesa-demos does not support windows 32 bit systems?
I cannot run these examples on windows 32 bit systems?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=91898
--- Comment #1 from Ilia Mirkin ---
Hmmm... I wonder if I should just stick the #ifdef HAVE_SHA1 all the way up
top.
--
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=91898
Bug ID: 91898
Summary: src/util/mesa-sha1.c:250:25: fatal error:
openssl/sha.h: No such file or directory
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
On Sunday, September 06, 2015 10:06:38 PM Marek Olšák wrote:
> On Sun, Sep 6, 2015 at 8:38 PM, Emil Velikov wrote:
> > On 3 September 2015 at 20:33, Ilia Mirkin wrote:
> >> On Thu, Sep 3, 2015 at 3:30 PM, Marek Olšák wrote:
> >>>
> >>> 2) Using LIBGL_DRIVERS_PATH won't use the correct drirc file
From: Marek Olšák
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91881
Cc: 11.0
---
src/gallium/drivers/r600/evergreen_state.c | 4 ++--
src/gallium/drivers/r600/r600_state.c | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/ever
From: Marek Olšák
instead of always doing both.
Usually, only depth is needed, so stencil decompression is useless.
---
src/gallium/drivers/radeonsi/si_blit.c | 26 --
src/gallium/drivers/radeonsi/si_pipe.h | 4 +++-
src/gallium/drivers/radeonsi/si_state.c | 12 +++
From: Marek Olšák
Basically, do the same thing as for buffer_unmap, but use the explicit range
instead. It's for apps which want to map a whole buffer and mark touched
ranges explicitly.
---
src/gallium/drivers/radeon/r600_buffer_common.c | 62 +
src/gallium/drivers/radeo
From: Marek Olšák
instead of always doing both.
Usually, only depth is needed, so stencil decompression is useless.
---
src/gallium/drivers/r600/evergreen_state.c | 12 +---
src/gallium/drivers/r600/r600_blit.c | 25 -
src/gallium/drivers/r600/r600_pipe.h
From: Marek Olšák
We will only do depth-only or stencil-only decompress blits, whichever is
needed by textures, instead of always doing both.
---
src/gallium/drivers/r600/evergreen_state.c| 4 ++--
src/gallium/drivers/r600/r600_state_common.c | 3 +++
src/gallium/drivers/radeon/r600_pipe_co
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_pm4.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pm4.h
b/src/gallium/drivers/radeonsi/si_pm4.h
index 5282d00..309a596 100644
--- a/src/gallium/drivers/radeonsi/si_pm4.h
+++ b/src/
From: Marek Olšák
LLVM 3.3 has been unsupported for quite a while.
---
src/gallium/drivers/r600/r600_llvm.c | 106 ---
1 file changed, 106 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_llvm.c
b/src/gallium/drivers/r600/r600_llvm.c
index faf538c..3362fd
From: Marek Olšák
Packets are emitted immediately anyway.
---
src/gallium/drivers/radeonsi/si_compute.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index ed9147c..e1
From: Marek Olšák
---
src/gallium/drivers/radeonsi/si_state.c | 4 +++-
src/gallium/drivers/radeonsi/si_state.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index f698c59..d74f6e8 100644
--
From: Marek Olšák
This allows using the new tex instrinsics unconditionally.
---
configure.ac| 2 +-
src/gallium/drivers/radeon/r600_pipe_common.c | 4
src/gallium/drivers/radeon/radeon_llvm_emit.c | 6 --
src/gallium/drivers/radeon/ra
Hi,
On Sun, Sep 6, 2015 at 3:04 PM, Emil Velikov wrote:
> Have you seen an application where this causes problems ? Might if I
> add it to the commit log before pushing ?
It caused a problem for a proposed patch to cogl that I ultimately
decided not to push after discussion with Daniel Stone. See
Hi Jean-Sébastien,
On 3 September 2015 at 19:07, Jean-Sébastien Pédron
wrote:
> ... to free the ralloc context at program exit.
>
> On Linux, atexit(3) handlers are called when the program exits but also
> when a library is unloaded. The latter behavior is a Glibc extension.
>
> On systems where
https://bugs.freedesktop.org/show_bug.cgi?id=91793
--- Comment #1 from Emil Velikov ---
The answer is pretty simple none of the supported 'platforms' is detected thus
nothing gets enabled/build. Perhaps we should error out at configure time ?
Here is what I mean with "none of the supported 'plat
https://bugs.freedesktop.org/show_bug.cgi?id=91826
--- Comment #7 from Koop Mast ---
hi, this bug has been marked as fixed but the fix hasn't been committed yet, is
there some hold up? Or should the bug be reopened until it ready to be
committed?
--
You are receiving this mail because:
You are
The third release candidate for Mesa 11.0.0 is now available.
Alexander von Gluck IV (1):
egl: scons: fix the haiku build, do not build the dri2 backend
Boyan Ding (1):
vc4: Initialize pack field of qreg to 0 in qir_get_temp
Chris Wilson (2):
i965: Prevent coordinate overflow
On Sun, Sep 6, 2015 at 8:38 PM, Emil Velikov wrote:
> On 3 September 2015 at 20:33, Ilia Mirkin wrote:
>> On Thu, Sep 3, 2015 at 3:30 PM, Marek Olšák wrote:
>>>
>>> 2) Using LIBGL_DRIVERS_PATH won't use the correct drirc file. The only
>>> remaining solution to that is to kill LIBGL_DRIVERS_PATH
https://bugs.freedesktop.org/show_bug.cgi?id=91888
--- Comment #1 from Emil Velikov ---
Hmm that's quite strange... the commit mentioned has nothing to do with context
creation. I'm slightly leaning towards a "not-our-bug" but I'd appreciate a
short test app that I can use to double-check :)
Tha
https://bugs.freedesktop.org/show_bug.cgi?id=91646
--- Comment #8 from Emil Velikov ---
Did anyone find the time to bisect ? I won't mind reverting any of my commits
but I'd like to know which one as I cannot really test this here.
--
You are receiving this mail because:
You are the QA Contact
Hello Ray,
On 28 August 2015 at 19:50, Ray Strode wrote:
> From: Ray Strode
>
> At the moment if a gbm buffer is imported and the gbm buffer
> has an old-style GBM_BO_FORMAT format, the import will crash,
> since it's passed directly to DRI functions that expect
> a fourcc format (as provided by
On 3 September 2015 at 20:33, Ilia Mirkin wrote:
> On Thu, Sep 3, 2015 at 3:30 PM, Marek Olšák wrote:
>> It looks like the comments have mostly been negative.
Fwiw I'm in favour of the series. They provide a sane, up-to date
version of the config. Sort of like how nowadays xserver does not
requir
On Sun, Sep 6, 2015 at 5:31 PM, Ilia Mirkin wrote:
> Nothing in the spec allows for the reduced precision, and this also
> fixes st_QuerySamplesForFormat for nv50, which does not allow MS8 on
> RGBA32F. Now this will be respected instead of reporting MS8 as
> supported with an assumption that the
On Sun, Sep 06, 2015 at 07:48:40PM +0300, Francisco Jerez wrote:
> Chris Wilson writes:
>
> > On Sun, Sep 06, 2015 at 07:28:12PM +0300, Francisco Jerez wrote:
> >> Chris Wilson writes:
> >>
> >> > On Sun, Sep 06, 2015 at 06:12:40PM +0200, Francisco Jerez wrote:
> >> >> This stores the result of
Chris Wilson writes:
> On Sun, Sep 06, 2015 at 07:28:12PM +0300, Francisco Jerez wrote:
>> Chris Wilson writes:
>>
>> > On Sun, Sep 06, 2015 at 06:12:40PM +0200, Francisco Jerez wrote:
>> >> This stores the result of can_do_pipelined_register_writes() in the
>> >> context struct so we can find
On Sun, Sep 06, 2015 at 07:28:12PM +0300, Francisco Jerez wrote:
> Chris Wilson writes:
>
> > On Sun, Sep 06, 2015 at 06:12:40PM +0200, Francisco Jerez wrote:
> >> This stores the result of can_do_pipelined_register_writes() in the
> >> context struct so we can find out later whether LRI can be u
glCopyTexImage behaves similarly to glReadPixels with respect to the
pixel transfer operations. Therefore if any are set we cannot use the
simply blit fast paths.
Signed-off-by: Chris Wilson
Cc: Jason Ekstrand
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 4
src/m
Chris Wilson writes:
> On Sun, Sep 06, 2015 at 06:12:40PM +0200, Francisco Jerez wrote:
>> This stores the result of can_do_pipelined_register_writes() in the
>> context struct so we can find out later whether LRI can be used to
>> program the L3 configuration.
>
> LRI are whitelisted by their re
On Sun, Sep 06, 2015 at 06:12:40PM +0200, Francisco Jerez wrote:
> This stores the result of can_do_pipelined_register_writes() in the
> context struct so we can find out later whether LRI can be used to
> program the L3 configuration.
LRI are whitelisted by their register. To be generic you must
---
src/mesa/drivers/dri/i965/gen7_l3_state.c | 95 +++
1 file changed, 95 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c
b/src/mesa/drivers/dri/i965/gen7_l3_state.c
index 8f9ba5b..48bca29 100644
--- a/src/mesa/drivers/dri/i965/gen7_l3_state.c
++
According to the hardware docs a DC flush is sufficient to make
CS_STALL happy, there's no need to add STALL_AT_SCOREBOARD whenever
it's present.
---
src/mesa/drivers/dri/i965/brw_pipe_control.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_pi
---
I've split this from the patch that implements the L3 state atom so I
can move it after the state leak work-around in order to avoid
temporary regressions.
src/mesa/drivers/dri/i965/brw_context.h | 4 ++--
src/mesa/drivers/dri/i965/brw_state_upload.c | 4
2 files changed, 6 insertio
The L3 state atom calculates the target L3 partition weights when the
program bound to some shader stage is modified, and in case they are
far enough from the current partitioning it makes sure that the L3
state is re-emitted.
---
src/mesa/drivers/dri/i965/brw_context.h | 6
src/mesa/drive
Improves performance of the arb_shader_image_load_store-atomicity
piglit test by over 25x (which isn't a real benchmark it's just heavy
on atomics -- the improvement in a microbenchmark I wrote a while ago
seemed to be even greater). The drawback is one needs to be
extra-careful not to hang the GP
---
src/mesa/drivers/dri/i965/gen7_l3_state.c | 17 +
src/mesa/drivers/dri/i965/intel_debug.c | 1 +
src/mesa/drivers/dri/i965/intel_debug.h | 1 +
3 files changed, 19 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen7_l3_state.c
b/src/mesa/drivers/dri/i965/gen7_l3_s
This is going to require some rather intrusive kernel changes to fix
properly, in the meantime (and forever on at least pre-v4.1 kernels)
we'll have to restore the hardware defaults at the end of every batch
in which the L3 configuration was changed to avoid interfering with
the DDX and GL clients
---
src/mesa/drivers/dri/i965/intel_reg.h | 53 +++
1 file changed, 53 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_reg.h
b/src/mesa/drivers/dri/i965/intel_reg.h
index b4283da..412a44a 100644
--- a/src/mesa/drivers/dri/i965/intel_reg.h
+++ b/src/mesa
This will make sure that we recalculate the URB layout anytime the URB
size is modified by the L3 partitioning code.
---
src/mesa/drivers/dri/i965/brw_context.h | 2 ++
src/mesa/drivers/dri/i965/brw_state_upload.c | 1 +
src/mesa/drivers/dri/i965/gen7_urb.c | 3 +++
3 files changed, 6
The input of the L3 set-up code is a vector giving the approximate
desired relative size of each partition. This implements logic to
compare the input vector against the table of validated configurations
for the device and pick the closest compatible one.
---
src/mesa/drivers/dri/i965/gen7_l3_sta
It should be possible to use additional L3 configurations other than
the ones listed in the tables of validated allocations ("BSpec »
3D-Media-GPGPU Engine » L3 Cache and URB [IVB+] » L3 Cache and URB [*]
» L3 Allocation and Programming"), but it seems sensible for now to
hard-code the tables in or
This calculates a rather conservative partitioning of the L3 cache
based on the shaders currently bound to the pipeline and whether they
use SLM, atomics, images or scratch space. The result is intended to
be fine-tuned later on based on other pipeline state.
---
src/mesa/drivers/dri/i965/brw_con
This stores the result of can_do_pipelined_register_writes() in the
context struct so we can find out later whether LRI can be used to
program the L3 configuration.
---
src/mesa/drivers/dri/i965/brw_context.h | 5 +
src/mesa/drivers/dri/i965/intel_extensions.c | 8 +---
2 files change
This series implements dynamic partitioning of the L3 cache space
among its clients, the purpose is multiple:
- Steal a chunk of L3 space when necessary and reserve it for SLM as
required to support compute shaders with shared variables.
- Allow L3 caching of dataport DC memory access where
Nothing in the spec allows for the reduced precision, and this also
fixes st_QuerySamplesForFormat for nv50, which does not allow MS8 on
RGBA32F. Now this will be respected instead of reporting MS8 as
supported with an assumption that the format used will be RGBA16F.
Signed-off-by: Ilia Mirkin
Cc
Reviewed-by: Marek Olšák
Marek
On Sat, Sep 5, 2015 at 7:12 PM, Ilia Mirkin wrote:
> vbuf is never null. We want to make sure that a resource was allocated
> for the vbuf, which is *vbuf.
>
> Signed-off-by: Ilia Mirkin
> ---
> src/mesa/state_tracker/st_cb_bitmap.c | 2 +-
> 1 file changed, 1 i
On Sat, Sep 5, 2015 at 7:20 PM, Ilia Mirkin wrote:
> On Sun, Jul 12, 2015 at 4:14 PM, Roland Scheidegger
> wrote:
>> Am 12.07.2015 um 19:30 schrieb Ilia Mirkin:
>>> I asked this on IRC, but figured I'd get wider distribution for the
>>> question. The situation is that nv50 doesn't support RGBA32
From: Marek Olšák
This fixes corruption in Unigine Heaven on VI
Cc: 11.0
---
src/gallium/drivers/radeonsi/si_pipe.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 7dbb2e3..85ade31 100
From: Marek Olšák
Required for register spilling.
Cc: 11.0
---
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c
index
Ah, okay. I see what you mean now (i.e. you had to wait three months
for those suggestions I mentioned). I still haven't recieved a
response at all for my first patch from almost a year ago (although it
was insanely trivial). So it isn't just you :)
Committers simply don't have the time to find ev
https://bugs.freedesktop.org/show_bug.cgi?id=91169
--- Comment #5 from Béla Gyebrószki ---
(In reply to Ilia Mirkin from comment #4)
> (In reply to Béla Gyebrószki from comment #3)
> > (In reply to Ilia Mirkin from comment #2)
> > > Created attachment 118090 [details] [review] [review] [review]
>
https://bugs.freedesktop.org/show_bug.cgi?id=91314
Béla Gyebrószki changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Indications are that if the colormask indicates a single bit set on
fermi, that value will always be read from $r0 instead of a potentially
higher register (if e.g. green is set). Not to upset the counting logic,
always set the header up with a full color mask for each RT.
Fixes the following pigl
On Sat, 5 Sep 2015 23:29:05 +
Albert Freeman wrote:
> The reply from Eric Anholt made two suggestions that should not be
> difficult to implement for someone who made the patch in the first
> place. Why would code be committed when improvements could be easily
> made? From what I have seen, t
62 matches
Mail list logo
