Hi Andy,
Thanks for trying it.
I figured out that there are some problems in the patch.
Firstly, I need to send a u_rect to bicubic_filter_render to take care of
the destination_video_rect, as to avoid writing on the entire surface.
Secondly, I also need to set destination_rect clip. I am not y
https://bugs.freedesktop.org/show_bug.cgi?id=96629
Bug ID: 96629
Summary: dEQP-GLES2.functional.texture.completeness.cube.not_po
sitive_level_0: Assertion `width >= 1' failed.
Product: Mesa
Version: git
Hardware: Other
Patches 3-6 are:
Reviewed-by: Timothy Arceri
On Tue, 2016-06-21 at 20:02 -0700, Kenneth Graunke wrote:
> Constant propagation on arrays doesn't make a lot of sense. If the
> array is only accessed with constant indexes, then
> opt_array_splitting
> would split it up. Otherwise, we have variabl
On Sat, Jun 11, 2016 at 09:02:17AM -0700, Jason Ekstrand wrote:
> We were adding in the base which is wrong because the values given in the
> miptree are relative to zero and not the base layer/level.
Thanks for fixing my mistake!
Reviewed-by: Topi Pohjolainen
>
> Cc: "11.1 11.2 12.0"
> ---
>
On Tue, 2016-06-21 at 20:02 -0700, Kenneth Graunke wrote:
> Previously, we failed to split constant arrays. Code such as
>
> int[2] numbers = int[](1, 2);
>
> would generates a whole-array assignment:
>
> (assign () (var_ref numbers)
> (constant (array int 4) (constant int 1)
The new uniform may need precise as well.
Fixes copy propagation of constant array uniforms in Tomb Raider shaders.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Kenneth Graunke
---
src/compiler/glsl/linker.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compiler/glsl/linker.
There's really no point in looking at ir_dereference_array of a
constant. It also misses cases like:
(assign () (var_ref tmp) (constant (array ...) ...))
No changes in shader-db, but keeps it working after the next commit.
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Kenneth Graunke
Constant propagation on arrays doesn't make a lot of sense. If the
array is only accessed with constant indexes, then opt_array_splitting
would split it up. Otherwise, we have variable indexing. If there's
multiple accesses, then constant propagation would end up replicating
the data.
The lower
opt_constant_propagation.cpp contains constant folding code which can
actually do constant propagation in some cases. It was happily
propagating constants into the left-hand-side of assignments.
For example,
(assign () (var_ref temp) (constant ...))
would brilliantly be turned into:
(ass
Previously, we failed to split constant arrays. Code such as
int[2] numbers = int[](1, 2);
would generates a whole-array assignment:
(assign () (var_ref numbers)
(constant (array int 4) (constant int 1) (constant int 2)))
opt_array_splitting generally tried to visit ir_derefe
The scalar backend currently doesn't support variable indexing on
temporary arrays, but it does support it on uniform arrays, and
some stages support it for input arrays. Make sure these are
propagated through before exploding indirects into piles of
if-ladders unnecessarily.
On Broadwell, no ins
Hello!
This series fixes the TressFX advanced hair rendering technique used
in Tomb Raider (2013). Prior to this series, the shaders would fail
to link because a uvec4[327] constant array would get replicated a
ton of times, and then each copy would get promoted to a uniform array,
wildly exceedi
We already store these in gl_shader and gl_program here we
remove it from gl_shader_program and just use the values
from gl_shader.
This will allow us to keep the shader cache restore code as
simple as it can be while making it somewhat clearer where these
values originate from.
---
src/compiler/
We already store this in gl_shader and gl_program here we
remove it from gl_shader_program and just use the values
from gl_shader.
This will allow us to keep the shader cache restore code as
simple as it can be while making it somewhat clearer where these
values originate from.
V2: remove unessis
https://bugs.freedesktop.org/show_bug.cgi?id=96617
Ilia Mirkin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 22 June 2016 at 11:06, Ilia Mirkin wrote:
> Is that correct in the case where I have something like
>
> dvec4 foo = ...
> bool x = (foo == dvec4(0, 1, 2, 3));
>
> ?
Yes, since immediates are repacked, and relooked up.
So if you do dvec4(1, 2, 2, 1) you only end up using two immediate
location
On Mon, 2016-06-20 at 17:38 +0200, Iago Toral wrote:
> On Mon, 2016-06-20 at 21:11 +1000, Timothy Arceri wrote:
> >
> > We will reuse this for fs key generation for the on disk shader
> > cache.
> > ---
> > src/mesa/drivers/dri/i965/brw_vs.c | 72 ++--
> > --
> > s
On 21.06.2016 18:49, Emil Velikov wrote:
> On 21 June 2016 at 07:39, Michel Dänzer wrote:
>> On 21.06.2016 15:24, Axel Davy wrote:
>>> On 21/06/2016 01:26, Michel Dänzer wrote:
On 20.06.2016 20:06, Frank Binns wrote:
> On 20/06/16 10:48, Michel Dänzer wrote:
>> On 18.06.2016 02:41, Fr
Is that correct in the case where I have something like
dvec4 foo = ...
bool x = (foo == dvec4(0, 1, 2, 3));
?
Can you elaborate a little bit more as to why this is right? Shouldn't
this be based on the swizzle of the src[j] argument? [Note, I haven't
carefully read all the surrounding code.]
O
From: Dave Airlie
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 9de603c..3d8ddc3 100644
--- a/src/mesa/s
On Tue, 2016-06-21 at 17:45 +0200, Iago Toral wrote:
> On Tue, 2016-06-21 at 12:21 +1000, Timothy Arceri wrote:
> >
> > We already store this in gl_shader and gl_program here we
> > remove it from gl_shader_program and just use the values
> > from gl_shader.
> >
> > This will allow us to keep the
Ivybridge and Baytrail have a pretty harsh limit of 12kB scratch space
per thread. However, we can exceed this limit with some clever tricks.
Later platforms have a 2MB limit, which is much more reasonable, but
we may as well apply the same trick there.
We can probably extend this trick to other
The RenderTargetViewExtent field of RENDER_SURFACE_STATE is supposed to be
set to the depth of a 3-D texture when rendering. Unfortunatley, that
field is only 9 bits on Sandy Bridge and prior so we can't actually bind
a 3-D texturing for rendering if it has depth > 512. On Ivy Bridge, this
field
So that we do copies host-side rather than in the guest with map/memcpy.
Tested with piglit arb_copy_buffer-subdata-sync test and new
arb_copy_buffer-intra-buffer-copy test.
---
src/gallium/drivers/svga/svga_pipe_blit.c | 35 +--
1 file changed, 29 insertions(+), 6 del
To be consistent with the pipe_context function name.
---
src/gallium/drivers/svga/svga_pipe_blit.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_pipe_blit.c
b/src/gallium/drivers/svga/svga_pipe_blit.c
index 8050b13..4eec927 1
We previously only did a buffer readback if it was dirty and we were
about to do a read-transfer. Now also do a readback for write-transfers
when not overwriting the entire buffer. We have to do that to keep the
guest/host buffers synchronized in order to support host-side buffer
copies with SVGA
From: Neha Bhende
Reviewed-by: Brian Paul
---
src/gallium/drivers/svga/svga_cmd.h| 6 ++
src/gallium/drivers/svga/svga_cmd_vgpu10.c | 24
2 files changed, 30 insertions(+)
diff --git a/src/gallium/drivers/svga/svga_cmd.h
b/src/gallium/drivers/svga/svga_cm
---
src/gallium/auxiliary/util/u_blitter.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blitter.c
b/src/gallium/auxiliary/util/u_blitter.c
index 1257bb6..d06b3a8 100644
--- a/src/gallium/auxiliary/util/u_blit
There's no reason for doing so.
---
src/gallium/drivers/svga/svga_pipe_blit.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_pipe_blit.c
b/src/gallium/drivers/svga/svga_pipe_blit.c
index 526018a..8050b13 100644
--- a/src/g
Andy Furniss wrote:
Nayan Deshmukh wrote:
I forgot to CC the list, so I am attaching our conversation here. Also
probably my R7 M265 uses
a progressive shader.
OK, maybe that could be it.
I may be able to try progressive, but need to remember what to change...
Seems I can't test progressive
On Tue, Jun 21, 2016 at 10:42:45PM +0200, Marek Olšák wrote:
> On Tue, Jun 21, 2016 at 9:27 PM, Tom Stellard wrote:
> > On Tue, Jun 21, 2016 at 08:17:15PM +0200, Marek Olšák wrote:
> >> On Tue, Jun 21, 2016 at 7:21 PM, Tom Stellard wrote:
> >> > On Mon, Jun 13, 2016 at 06:27:02PM +0200, Marek Olš
Nayan Deshmukh wrote:
I forgot to CC the list, so I am attaching our conversation here. Also
probably my R7 M265 uses
a progressive shader.
OK, maybe that could be it.
I may be able to try progressive, but need to remember what to change...
I have done it before when testing 4:2:2 (which does
I forgot to CC the list, so I am attaching our conversation here. Also
probably my R7 M265 uses
a progressive shader.
Regards,
Nayan.
Nayan Deshmukh wrote:
> Hi Andy,
>
> I am not sure why it's not working. It is working on my R7 M265.
>
> Is it working on switching to full screen?
>
> Have you
On Tue, Jun 21, 2016 at 9:27 PM, Tom Stellard wrote:
> On Tue, Jun 21, 2016 at 08:17:15PM +0200, Marek Olšák wrote:
>> On Tue, Jun 21, 2016 at 7:21 PM, Tom Stellard wrote:
>> > On Mon, Jun 13, 2016 at 06:27:02PM +0200, Marek Olšák wrote:
>> >> From: Marek Olšák
>> >>
>> >> ---
>> >> src/gallium
Nayan Deshmukh wrote:
Hi Andy,
I forgot to change the feature in query.c, which is responsible for the
information about the capabilities of the mixer. I'll send the patch with
change.
Ok, I tried the new patch and with mplayer or mpv the output is corrupted.
I am using R9285 tonga.
There's special logic around finding gl_FragData. It latches onto any
array with FRAG_RESULT_DATA0. However gl_SecondaryFragDataEXT[], added
by GL_EXT_blend_func_extended, fits those parameters as well. The real
frag data array should have index 0 though, so we can use that to
distinguish them.
Bu
On Tuesday, June 21, 2016 3:01:16 PM PDT Ilia Mirkin wrote:
> There's special logic around finding gl_FragData. It latches onto any
> array with FRAG_RESULT_DATA0. However gl_SecondaryFragDataEXT[], added
> by GL_EXT_blend_func_extended, fits those parameters as well. The real
> frag data array sho
On Tue, Jun 21, 2016 at 08:17:15PM +0200, Marek Olšák wrote:
> On Tue, Jun 21, 2016 at 7:21 PM, Tom Stellard wrote:
> > On Mon, Jun 13, 2016 at 06:27:02PM +0200, Marek Olšák wrote:
> >> From: Marek Olšák
> >>
> >> ---
> >> src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
> >> src/gallium/dr
https://bugs.freedesktop.org/show_bug.cgi?id=96617
Ilia Mirkin changed:
What|Removed |Added
Component|Drivers/DRI/i965|Mesa core
Assignee|i...@freedesk
use bicubic filtering as high quality scaling L1.
v2: fix a typo and add a newline to code
v3: -render the unscaled image on a temporary surface (Christian)
-apply noise reduction and sharpness filter on
unscaled surface
-render the final scaled surface using bicubic
interpolati
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Kai changed:
What|Removed |Added
Depends on||96622
Referenced Bugs:
https://bugs.freedesktop.
Hi Andy,
I forgot to change the feature in query.c, which is responsible for the
information about the capabilities of the mixer. I'll send the patch with
change.
Thanks.
Regards,
Nayan.
On Wed, Jun 22, 2016 at 12:13 AM, Andy Furniss wrote:
> Nayan Deshmukh wrote:
>
>> use bicubic filtering a
There's special logic around finding gl_FragData. It latches onto any
array with FRAG_RESULT_DATA0. However gl_SecondaryFragDataEXT[], added
by GL_EXT_blend_func_extended, fits those parameters as well. The real
frag data array should have index 0 though, so we can use that to
distinguish them.
Bu
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 96602, which changed state.
Bug 96602 Summary: [radeonsi] Dreamfall Chapters: one shader fails to compile,
minor visual corruption
https://bugs.freedesktop.org/show_bug.cgi?id=96602
What|Removed
Nayan Deshmukh wrote:
use bicubic filtering as high quality scaling L1.
Nice, but it doesn't show up in vdpauinfo as a "y".
What player/options are you using to test this?
Thanks.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lis
Ping? I got a R-b from Eric Engestrom (thanks!) but I was hoping some
more experienced Mesa contributors could give this a look and see if
this makes sense or if I'm still missing some crucial bits.
On Mon, Jun 13, 2016 at 11:43 PM, Ilia Mirkin wrote:
> Previously we were only restricting based o
On Tue, Jun 21, 2016 at 11:11 AM, Emil Velikov wrote:
> P.S. Ensuring new code matches coding standards can be rather easily
> enforced with git hooks.
I think that would be ideal.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.f
On Tue, Jun 21, 2016 at 7:21 PM, Tom Stellard wrote:
> On Mon, Jun 13, 2016 at 06:27:02PM +0200, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
>> src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
>> src/gallium/drivers/radeonsi/si_
On 15 June 2016 at 22:16, Eric Anholt wrote:
> Jose Fonseca writes:
>
>> On 15/06/16 18:13, Emil Velikov wrote:
>>> On 15 June 2016 at 15:58, Brian Paul wrote:
Why is this change needed? Does some compiler balk at 1.f?
>>> Since I'm the one 'to blame' for these patches I'll answer - c
Gentle ping. I would appreciate feedbaçk on what (if anything) I
should do to get this patch into shape.
Regards,
Lars Hamre
On Mon, Jun 6, 2016 at 9:00 AM, Lars Hamre wrote:
> v2:
> - ES version check (Tapani Pälli)
> v3/v4:
> - compare varying slot locations rather than names (Ilia Mirkin)
>
use bicubic filtering as high quality scaling L1.
v2: fix a typo and add a newline to code
v3: -render the unscaled image on a temporary surface
-apply noise reduction and sharpness filter on
unscaled surface
-render the final scaled surface using bicubic
interpolation
Signed-o
On Mon, Jun 13, 2016 at 06:27:02PM +0200, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
> src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
> src/gallium/drivers/radeonsi/si_shader.c | 16
> 3 files changed, 18 in
Nicolai Hähnle writes:
> On 21.06.2016 16:50, Marek Olšák wrote:
>> On Tue, Jun 21, 2016 at 4:40 PM, Nicolai Hähnle wrote:
>>> On 21.06.2016 14:17, Marek Olšák wrote:
From: Marek Olšák
for debugging
---
src/gallium/auxiliary/util/u_queue.c | 10
Vedran Miletić writes:
> On 06/21/2016 03:13 AM, Michel Dänzer wrote:
>> On 21.06.2016 08:17, Vedran Miletić wrote:
[ ... ]
>>
>> P.S. I recommend adding your Signed-off-by for patches you want to be
>> applied.
>>
>
> Will do. Thanks for explaining what that is used for.
>
> Regards,
> Vedran
On Tue, 2016-06-21 at 12:21 +1000, Timothy Arceri wrote:
> We already store this in gl_shader and gl_program here we
> remove it from gl_shader_program and just use the values
> from gl_shader.
>
> This will allow us to keep the shader cache restore code as
> simple as it can be while making it so
There a few places in the code where clearing and reading are done on incorrect
buffers for GLES contexts. See comments for details. This fixes 75 GLES3
dEQP tests on the surfaceless platform with no regressions.
---
src/mesa/main/buffers.c | 14 --
src/mesa/main/clear.c | 8 +
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_vce.c| 171 +++
src/gallium/drivers/radeon/radeon_vce.h| 1 +
src/gallium/drivers/radeon/radeon_vce_52.c | 447 +++--
3 files changed, 533 insertions(+), 86 deletions(-)
diff --git a/src/g
On 21.06.2016 16:50, Marek Olšák wrote:
On Tue, Jun 21, 2016 at 4:40 PM, Nicolai Hähnle wrote:
On 21.06.2016 14:17, Marek Olšák wrote:
From: Marek Olšák
for debugging
---
src/gallium/auxiliary/util/u_queue.c | 10 ++
src/gallium/auxiliary/util/u_queue.h
On Tue, Jun 21, 2016 at 4:40 PM, Nicolai Hähnle wrote:
> On 21.06.2016 14:17, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> for debugging
>> ---
>> src/gallium/auxiliary/util/u_queue.c | 10 ++
>> src/gallium/auxiliary/util/u_queue.h | 2 ++
>> src/galliu
Signed-off-by: Boyuan Zhang
---
src/gallium/include/pipe/p_video_state.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/gallium/include/pipe/p_video_state.h
b/src/gallium/include/pipe/p_video_state.h
index d353be6..d519d17 100644
--- a/src/gallium/include/pipe/p_video_sta
Signed-off-by: Boyuan Zhang
---
src/gallium/drivers/radeon/radeon_vce.h | 297
1 file changed, 297 insertions(+)
diff --git a/src/gallium/drivers/radeon/radeon_vce.h
b/src/gallium/drivers/radeon/radeon_vce.h
index e438148..da61285 100644
--- a/src/gallium/driver
On 21.06.2016 14:17, Marek Olšák wrote:
Hi,
This improves u_queue to be more usable in more cases.
With this, the size of the queue (maximum number of jobs waiting) is
configurable as well as the number of threads executing the jobs. The
semaphores are ditched in favor of simpler condvars, an
On Tue, Jun 21, 2016 at 4:31 PM, Nicolai Hähnle wrote:
> On 21.06.2016 14:17, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> and allow specifying its size in util_queue_init.
>> ---
>> src/gallium/auxiliary/util/u_queue.c | 55
>> ---
>> src/gallium/auxiliary
On 21.06.2016 14:17, Marek Olšák wrote:
From: Marek Olšák
independent jobs don't have to be stuck on only one thread
(there is just one deadlock situation in util_queue_destroy that
will be fixed in a later patch)
---
src/gallium/auxiliary/util/u_queue.c | 66 +++
On 21.06.2016 14:17, Marek Olšák wrote:
From: Marek Olšák
for debugging
---
src/gallium/auxiliary/util/u_queue.c | 10 ++
src/gallium/auxiliary/util/u_queue.h | 2 ++
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 2 +-
src/gallium/winsys/radeon/drm
The fourth release candidate for Mesa 12.0.0 is now available.
Note: this is the final release candidate, with Mesa 12.0.0 expected in a
couple of days.
Emil Velikov (1):
Update version to 12.0.0-rc4
Iago Toral Quiroga (1):
i965/fs: Fix single-precision to double-precision conversi
On 21.06.2016 14:17, Marek Olšák wrote:
From: Marek Olšák
and allow specifying its size in util_queue_init.
---
src/gallium/auxiliary/util/u_queue.c | 55 ---
src/gallium/auxiliary/util/u_queue.h | 8 ++--
src/gallium/winsys/amdgpu/drm/amdgpu_w
Am 21.06.2016 um 15:53 schrieb Rob Herring:
On Mon, Jun 20, 2016 at 1:15 PM, Christian König
wrote:
Am 20.06.2016 um 17:39 schrieb Rob Herring:
On Mon, Jun 20, 2016 at 9:27 AM, Christian König
wrote:
Am 20.06.2016 um 16:13 schrieb Rob Herring:
On Mon, Jun 20, 2016 at 8:31 AM, Nicolai Hähnle
Reviewed-by: Marek Olšák
Marek
On Tue, Jun 21, 2016 at 11:08 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> This avoids costly address recomputations, function overhead, and may trigger
> large copy optimizations.
> ---
> src/mesa/state_tracker/st_cb_readpixels.c | 23 +++---
On Mon, Jun 20, 2016 at 1:15 PM, Christian König
wrote:
> Am 20.06.2016 um 17:39 schrieb Rob Herring:
>>
>> On Mon, Jun 20, 2016 at 9:27 AM, Christian König
>> wrote:
>>>
>>> Am 20.06.2016 um 16:13 schrieb Rob Herring:
On Mon, Jun 20, 2016 at 8:31 AM, Nicolai Hähnle
wrote:
>
>
Reviewed-by: Marek Olšák
Marek
On Tue, Jun 21, 2016 at 4:21 AM, Timothy Arceri
wrote:
> We already store this in gl_shader and gl_program here we
> remove it from gl_shader_program and just use the values
> from gl_shader.
>
> This will allow us to keep the shader cache restore code as
> simple
On 06/21/2016 03:08 AM, Nicolai Hähnle wrote:
From: Nicolai Hähnle
This avoids costly address recomputations, function overhead, and may trigger
large copy optimizations.
---
src/mesa/state_tracker/st_cb_readpixels.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions
On Tue, Jun 21, 2016 at 03:51:15PM +0300, Pohjolainen, Topi wrote:
> On Mon, Jun 20, 2016 at 08:52:50PM -0700, Kenneth Graunke wrote:
> > On Friday, June 17, 2016 4:55:41 PM PDT Jason Ekstrand wrote:
> > > On Thu, Jun 16, 2016 at 10:08 AM, Chad Versace
> > > wrote:
> > >
> > > > On Sat 11 Jun 201
On Mon, Jun 20, 2016 at 08:52:50PM -0700, Kenneth Graunke wrote:
> On Friday, June 17, 2016 4:55:41 PM PDT Jason Ekstrand wrote:
> > On Thu, Jun 16, 2016 at 10:08 AM, Chad Versace
> > wrote:
> >
> > > On Sat 11 Jun 2016, Jason Ekstrand wrote:
> > > > Otherwise, we end up with a bogus value in the
From: Marek Olšák
for debugging
---
src/gallium/auxiliary/util/u_queue.c | 10 ++
src/gallium/auxiliary/util/u_queue.h | 2 ++
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 2 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 2 +-
4 files changed,
From: Marek Olšák
by converting semaphores to condvars and using the main mutex
this also fixes the deadlock situation in destroy mentioned 2 patches ago
---
src/gallium/auxiliary/util/u_queue.c | 50 +++-
src/gallium/auxiliary/util/u_queue.h | 5 ++--
2 files c
From: Marek Olšák
so that independent types of jobs can use the same queue.
---
src/gallium/auxiliary/util/u_queue.c | 12 ++--
src/gallium/auxiliary/util/u_queue.h | 10 ++
src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 3 ++-
src/gallium/winsys/a
From: Marek Olšák
independent jobs don't have to be stuck on only one thread
(there is just one deadlock situation in util_queue_destroy that
will be fixed in a later patch)
---
src/gallium/auxiliary/util/u_queue.c | 66 +++
src/gallium/auxiliary/util/u_queue.h
From: Marek Olšák
Checking "signalled" is first done without a mutex, then with a mutex.
Also, checking without waiting doesn't lock the mutex. This is racy, but
should be safe.
---
src/gallium/auxiliary/util/u_queue.c | 49 +---
src/gallium/auxiliary/util/u_queue
From: Marek Olšák
and allow specifying its size in util_queue_init.
---
src/gallium/auxiliary/util/u_queue.c | 55 ---
src/gallium/auxiliary/util/u_queue.h | 8 ++--
src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 2 +-
src/gallium/winsys/radeo
Hi,
This improves u_queue to be more usable in more cases.
With this, the size of the queue (maximum number of jobs waiting) is
configurable as well as the number of threads executing the jobs. The
semaphores are ditched in favor of simpler condvars, and multiple waiters on
fences are allowed
On 21 June 2016 at 07:39, Michel Dänzer wrote:
> On 21.06.2016 15:24, Axel Davy wrote:
>> On 21/06/2016 01:26, Michel Dänzer wrote:
>>> On 20.06.2016 20:06, Frank Binns wrote:
On 20/06/16 10:48, Michel Dänzer wrote:
> On 18.06.2016 02:41, Frank Binns wrote:
>> Up until now, DRI3 was o
From: Nicolai Hähnle
This avoids costly address recomputations, function overhead, and may trigger
large copy optimizations.
---
src/mesa/state_tracker/st_cb_readpixels.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_rea
Hi Ilia,
I'm going to push this with your ST_DEBUG suggestion. I did some more
micro-benchmarking with the attached test, which confirmed that the
current heuristic is decent for radeonsi. One might get slightly better
results with a mixed heuristic that includes the number of readpixels
call
Reviewed-by: Nicolai Hähnle
On 20.06.2016 19:07, Marek Olšák wrote:
Ping
On Mon, Jun 13, 2016 at 6:27 PM, Marek Olšák wrote:
From: Marek Olšák
---
src/gallium/drivers/radeon/r600_pipe_common.c | 1 +
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/drivers/radeonsi/si
Reviewed-by: Nicolai Hähnle
On 20.06.2016 20:22, Marek Olšák wrote:
From: Marek Olšák
This reduces time spend in glGenerateMipmap by a half.
v2: don't decompress the levels to be overwritten
---
src/gallium/drivers/radeonsi/si_blit.c | 31 +++
src/gallium/drive
On 21/06/16 07:39, Michel Dänzer wrote:
On 21.06.2016 15:24, Axel Davy wrote:
On 21/06/2016 01:26, Michel Dänzer wrote:
On 20.06.2016 20:06, Frank Binns wrote:
On 20/06/16 10:48, Michel Dänzer wrote:
On 18.06.2016 02:41, Frank Binns wrote:
Up until now, DRI3 was only used for devices that ha
On 06/21/2016 03:13 AM, Michel Dänzer wrote:
On 21.06.2016 08:17, Vedran Miletić wrote:
setLangDefaults() now requires PreprocessorOptions as an argument.
---
src/gallium/state_trackers/clover/llvm/invocation.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/st
88 matches
Mail list logo
