When selecting a mesa_format to use for a texture, we are constrained by
the user's requested internalFormat. If the requested internalFormat is
generic (e.g. GL_RGBA) it imposes no preferred type or layout and so we
are free to choose any compatible mesa_format. In this case, we can
inspect the in
On Fri, Sep 04, 2015 at 08:51:25AM +0100, Chris Wilson wrote:
> + /* We use the user's pixel format and type as a guide for the texture
> +* format preferrring to store the texels in a matching format to the
> +* incoming pixels. This ideally allows for a conversion free upload
> +* a
If we have spilled/unspilled a register in the current instruction, avoid
emitting unspills for the same register in the same instruction or consecutive
instructions following the current one as long as they keep reading the spilled
register. This should allow us to avoid emitting costy unspills th
On Thu, 2015-09-03 at 15:37 +0300, Francisco Jerez wrote:
> Iago Toral writes:
>
> > On Wed, 2015-09-02 at 14:32 +0300, Francisco Jerez wrote:
> >> Iago Toral writes:
> >>
> >> > On Thu, 2015-07-30 at 16:13 +0300, Francisco Jerez wrote:
> >> >> Iago Toral writes:
> >> >>
> >> >> > On Thu, 201
On Fri, Sep 04, 2015 at 09:00:39AM +0100, Chris Wilson wrote:
> On Fri, Sep 04, 2015 at 08:51:25AM +0100, Chris Wilson wrote:
> > + /* We use the user's pixel format and type as a guide for the texture
> > +* format preferrring to store the texels in a matching format to the
> > +* incomi
This is required to store information about packed varyings, currently
these variables get lost and cannot be retrieved later in sensible way
for program interface queries. List will be utilized by next patch.
Signed-off-by: Tapani Pälli
---
src/glsl/lower_packed_varyings.cpp | 16 --
Hi;
Here's a solution to a problem with lower_packed_varyings pass. I
wanted to ask if this seems OK approach for everyone or should I try
to think of some alternative way of solving this, not sure how though.
If this is OK, I will do some cleanups and send these again.
Problem is that shader mig
This makes sure that user is still able to query properties about
variables that have gotten packed by lower_packed_varyings pass.
Fixes following OpenGL ES 3.1 test:
ES31-CTS.program_interface_query.separate-programs-vertex
Signed-off-by: Tapani Pälli
---
src/glsl/linker.cpp | 55 ++
Wow, that's a blast from the past ;)
> On Sep 3, 2015, at 21:36, Matt Turner wrote:
>
> From: Jeremy Huddleston
>
> Cc: "10.6 11.0"
> Bugzilla: https://bugs.gentoo.org/240956
> ---
> After talking with Ian today, we determined that this disables an
> optimization.
>
> And FWIW, NVIDIA's fork
Iago Toral writes:
> On Thu, 2015-09-03 at 15:37 +0300, Francisco Jerez wrote:
>> Iago Toral writes:
>>
>> > On Wed, 2015-09-02 at 14:32 +0300, Francisco Jerez wrote:
>> >> Iago Toral writes:
>> >>
>> >> > On Thu, 2015-07-30 at 16:13 +0300, Francisco Jerez wrote:
>> >> >> Iago Toral writes:
On 03/08/15 10:04, Tapani Pälli wrote:
Fixes rest of the failures with
ES31-CTS.program_interface_query.no-locations
v2: make additional check only for GS inputs
Signed-off-by: Tapani Pälli
---
src/mesa/main/shader_query.cpp | 11 +--
1 file changed, 9 insertions(+), 2 deletions
On Fri, Sep 4, 2015 at 1:17 AM, Roland Scheidegger wrote:
> Oh, that's quite a subtle bug...
>
> Reviewed-by: Roland Scheidegger
>
Indeed, and it caused over 350 piglit tests to fail on ppc64le.
See before and after:
http://people.freedesktop.org/~gabbayo/ppc64le_imm_fixed/fixes.html
Oded
On 09/04/2015 01:39 PM, Martin Peres wrote:
On 03/08/15 10:04, Tapani Pälli wrote:
Fixes rest of the failures with
ES31-CTS.program_interface_query.no-locations
v2: make additional check only for GS inputs
Signed-off-by: Tapani Pälli
---
src/mesa/main/shader_query.cpp | 11 +--
If we have spilled/unspilled a register in the current instruction, avoid
emitting unspills for the same register in the same instruction or consecutive
instructions following the current one as long as they keep reading the spilled
register. This should allow us to avoid emitting costy unspills th
All found from the spec,
Reviewed-by: Tapani Pälli
On 08/10/2015 02:24 PM, Marta Lofstedt wrote:
From: Marta Lofstedt
Signed-off-by: Marta Lofstedt
---
src/mesa/main/get_hash_params.py | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/get_ha
On 03/09/15 16:26, Tom Stellard wrote:
On Thu, Sep 03, 2015 at 06:15:26PM +0300, Oded Gabbay wrote:
round(val*dscale) produces a double result, as val and dscale are double.
However, LLVMConstInt receives unsigned long long, so there is an
implicit conversion from double to unsigned long long.
T
Series looks good to me, I verified GetInteger* and GetVertexAttrib*
values from ES 3.1 spec state tables;
Reviewed-by: Tapani Pälli
On 08/19/2015 09:25 PM, Marta Lofstedt wrote:
These patches enable some Vertex Binding functionality for OpenGL ES 3.1,
that is currently limited to desktop GL.
X11_CFLAGS is undefined, so these tests will fail to build if x11proto is
installed in a non-standard location.
(See also commits 35189d76, bc93c3798, 54b028ba, d901d7e08, etc.)
Signed-off-by: Jon TURNEY
---
src/glx/tests/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -
X11_CFLAGS is never defined. Path to X11 headers is not needed here, so
just remove.
Future work: Using AM_CFLAGS here looks wrong, as this Makefile only builds
C++ files
Signed-off-by: Jon TURNEY
---
src/mesa/main/tests/Makefile.am | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/m
Reviewed-by: Tapani Pälli
On 08/31/2015 04:04 PM, Marta Lofstedt wrote:
From: Marta Lofstedt
According to OpenGL ES 3.1 specification table : 20.2 and
OpenGL specification 4.4 table 23.4. The glGetIntegeri_v
functions should report the name of the buffer bound
when called with GL_VERTEX_BIND
X11_CFLAGS isn't defined by configure.ac since commmit 35189d76 removed
PKG_CHECK_MODULES([X11],[x11])
Fix the remaining uses of X11_CFLAGS. There are no uses of X11_LIBS
Jon TURNEY (2):
Use X11_INCLUDES instead of X11_CFLAGS
Remove unneeded X11_CFLAGS
src/glx/tests/Makefile.am | 2
Iago Toral Quiroga writes:
> If we have spilled/unspilled a register in the current instruction, avoid
> emitting unspills for the same register in the same instruction or consecutive
> instructions following the current one as long as they keep reading the
> spilled
> register. This should allo
Hi,
On 03-09-15 19:36, Ilia Mirkin wrote:
On Thu, Sep 3, 2015 at 7:09 AM, Hans de Goede wrote:
Hi,
On 02-09-15 16:44, Ilia Mirkin wrote:
On Wed, Sep 2, 2015 at 5:48 AM, Hans de Goede wrote:
Hi Ilia
Of course I don't really see how MS can work at all with nv30 since it
doesn't suppo
Hi,
On 03-09-15 19:14, Ilia Mirkin wrote:
On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote:
Hi All,
Here is a bunch of fixes for nv30 cards, the first patch is a resend of
a patch I send a while back. AFAICT that one is ready for merging, but
it is not entirely clear to me what the process
When checking for LLVM shared libraries, use IMP_LIB_EXT for the extension for
shared libraries appropriate to the target, rather than hardcoding '.so'
Also add some comments to explain why we have this circus of pain.
Signed-off-by: Jon TURNEY
---
configure.ac | 33 +++-
Hi,
On 03-09-15 19:32, Ilia Mirkin wrote:
On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote:
On nv3x we will likely end up using the cpu to do color resolving for msaa
blits. Disable msaa on these cards so that we do not end up using the cpu.
Actually the CPU fallback won't do scaled, so i
Hi,
On 03-09-15 19:33, Ilia Mirkin wrote:
On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote:
On nv4x with a msaa visual after a while the gpu locks up, attach gdb to
impress shows it is hanging waiting for a fence which never comes.
Killing ooimpress at this point works exactly once, trying
I've just noticed that I never really added Ian in the CC...
On Thu, 2015-08-06 at 08:35 +0200, Iago Toral wrote:
> On Thu, 2015-08-06 at 08:53 +0300, Tapani Pälli wrote:
> > Reviewed-by: Tapani Pälli
> >
> > On 08/05/2015 11:30 AM, Iago Toral Quiroga wrote:
> > > From: Samuel Iglesias Gonsalvez
This is a new version of the mini-series that fixes the regression described at
https://bugs.freedesktop.org/show_bug.cgi?id=91582.
The first patch is not directly related with fixing the regression, but it
addresses an issue uncovered by it and at the same time fixes a failing dEQP
test.
The
This function will be needed as part of validating the combination of format,
type and internal format of texture pixel operations, which happens in
glformats files. Specifically, we want to be able to obtain the base format
of a resolved effective internal format, to compare it with the original
i
The more specific GLES constrains should be checked after the general
validation performed by _mesa_error_check_format_and_type(). This is also
for consistency with the error checks order of glTexSubImage ops.
v3: The change of order uncovered a bug that regresses a couple of piglit
tests written
When validating format+type+internalFormat for texture pixel operations
on GLES3, the effective internal format should be used if the one
specified is an unsized internal format. Page 127, section "3.8 Texturing"
of the GLES 3.0.4 spec says:
"if internalformat is a base internal format, the ef
On 03/07/2015 16:34, Emil Velikov wrote:
On 02/07/15 16:32, Jon TURNEY wrote:
On 02/07/2015 13:42, Emil Velikov wrote:
On 27 June 2015 at 12:21, Jon TURNEY wrote:
This smells to me like there's something not quite right about the
partitioning of stuff between libmesa and libglapi, but I don't
On 13/07/2015 16:32, Emil Velikov wrote:
P.S. Why is there no appledriproto package, similar to xf86driproto
and friends ? Having appledri{,str}.h duplicated seems fragile and
ill-advised.
I think this all pre-dates X.org modularization
It would probably make sense to have it as a separate pac
On Fri, Sep 04, 2015 at 09:37:37AM +0100, Chris Wilson wrote:
> On Fri, Sep 04, 2015 at 09:00:39AM +0100, Chris Wilson wrote:
> > On Fri, Sep 04, 2015 at 08:51:25AM +0100, Chris Wilson wrote:
> > > + /* We use the user's pixel format and type as a guide for the texture
> > > +* format preferr
On Thu, Sep 3, 2015 at 2:32 PM, Kenneth Graunke wrote:
> Prevents regressions in ~128 tests when fixing unlink_block_successors
> in the next commit.
>
> XXX: Zero thought has been put into whether this is the right solution
I'm confused as to how this can happen. The fake link is only for the
si
On Thu, Sep 3, 2015 at 2:32 PM, Kenneth Graunke wrote:
> Calling unlink_blocks(block, block->successors[0]) will successfully
> unlink the first successor, but then will shift block->successors[1]
> down to block->successor[0]. So the successors[1] != NULL check will
> always fail.
>
> Signed-off
On Fri, Sep 4, 2015 at 9:10 AM, Hans de Goede wrote:
> Hi,
>
> On 03-09-15 19:32, Ilia Mirkin wrote:
>>
>> On Thu, Sep 3, 2015 at 7:25 AM, Hans de Goede wrote:
>>>
>>> On nv3x we will likely end up using the cpu to do color resolving for
>>> msaa
>>> blits. Disable msaa on these cards so that we
Gen9 changes the meaning of this to coarse LOD quality mode. Although that's a
desirable thing to be setting, it doesn't match the gen8 behavior and this was
unintentional. More importantly, we don't ever use this field. So instead of
getting it "wrong" drop it entirely.
This is a respin of a patc
By my count, this series fixes 59 separate dEQP tests on various
platforms. I found no regressions.
Tested-by: Mark Janes
Eduardo Lima Mitev writes:
> This is a new version of the mini-series that fixes the regression described
> at https://bugs.freedesktop.org/show_bug.cgi?id=91582.
>
> The
On Friday, September 04, 2015 10:42:33 AM Ben Widawsky wrote:
> Gen9 changes the meaning of this to coarse LOD quality mode. Although that's a
> desirable thing to be setting, it doesn't match the gen8 behavior and this was
> unintentional. More importantly, we don't ever use this field. So instead
Signed-off-by: Benjamin Bellec
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index ed5d1da..2a8d906 100644
--- a/src/gallium/drive
Forgot this one.
I will resend correctly, just trying to understand how git-format-patch and
git-send-mail works...
2015-09-04 20:18 GMT+02:00 Benjamin Bellec :
> Signed-off-by: Benjamin Bellec
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 del
- split nvc0_decoder_bsp in begin/next/end
- preserve content buffer when calling nvc0_decoder_bsp_next
- implement pipe_video_codec::begin_frame/end_frame
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nvc0/nvc0_video.c | 44
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c
b/src/gallium/drivers/nouveau/nouveau_vp3_video_bsp
vainfo fails in vaDriverInit because "dd_create_screen"
does not reach strcmp(driver_name, "nouveau") code.
Indeed when compiling the va target.c, the macro GALLIUM_NOUVEAU
is not defined.
This patch define the macro the same it is done for dri and
vdpau targets.
Tested with:
./autogen.sh --enable
It allows to call nouveau_vp3_bsp_next multiple times
between one begin/end.
It is required to support st/va.
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nouveau_vp3_video.h| 17 ++-
.../drivers/nouveau/nouveau_vp3_video_
Currently nouveau does not support chunk decoding
which is required to support st/va.
The low level code is already there since it supports
vpau. But it is missing the possibility to feed
the nouveau_bo buffers gradually.
Resizing is already there too. But it also requires
to preserve the content
The tiled memcpy fast paths perform a simple blit (with only a couple of
trivial pixel conversion routines) and do not accommodate PixelTransfer
operations. Therefore if any are set, fallback to the regular routines.
Note that PixelTransfer only applies to TexImage and ReadPixels, not to
GetTexImag
Reviewed-by: Jason Ekstrand
On Fri, Sep 4, 2015 at 11:24 AM, Chris Wilson wrote:
> The tiled memcpy fast paths perform a simple blit (with only a couple of
> trivial pixel conversion routines) and do not accommodate PixelTransfer
> operations. Therefore if any are set, fallback to the regular ro
Signed-off-by: Benjamin Bellec
---
src/gallium/drivers/radeon/r600_pipe_common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index ed5d1da..2a8d906 100644
--- a/src/gallium/drive
Signed-off-by: Benjamin Bellec
---
src/gallium/auxiliary/hud/hud_context.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 95eed26..71529bc 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/s
On Friday, September 04, 2015 07:24:54 PM Chris Wilson wrote:
> The tiled memcpy fast paths perform a simple blit (with only a couple of
> trivial pixel conversion routines) and do not accommodate PixelTransfer
> operations. Therefore if any are set, fallback to the regular routines.
> Note that Pi
On 08/28/2015 11:03 AM, Jason Ekstrand wrote:
On Fri, Aug 28, 2015 at 7:43 AM, Brian Paul wrote:
On 08/28/2015 12:43 AM, Jason Ekstrand wrote:
On Thu, Aug 27, 2015 at 11:42 PM, Jason Ekstrand
wrote:
From: Brian Paul
Previously, core Mesa's _mesa_CopyImageSubData() created temporary
textu
On 09/04/2015 12:30 PM, Benjamin Bellec wrote:
Signed-off-by: Benjamin Bellec
---
src/gallium/auxiliary/hud/hud_context.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 95eed26..71529bc 100644
--
On Fri, Sep 04, 2015 at 11:34:29AM -0700, Kenneth Graunke wrote:
> On Friday, September 04, 2015 07:24:54 PM Chris Wilson wrote:
> > The tiled memcpy fast paths perform a simple blit (with only a couple of
> > trivial pixel conversion routines) and do not accommodate PixelTransfer
> > operations. T
Currently, the temperature is displayed with a "%" symbol in gallium/hud,
which is quite odd.
Marek suggested to only change the value "100" to another value so that
this symbol is no more displayed. That works very well. This is the patch
#1. I choose "125" because it can be divided nicely by 5, t
On Friday, September 04, 2015 07:47:31 PM Chris Wilson wrote:
> On Fri, Sep 04, 2015 at 11:34:29AM -0700, Kenneth Graunke wrote:
> > On Friday, September 04, 2015 07:24:54 PM Chris Wilson wrote:
> > > The tiled memcpy fast paths perform a simple blit (with only a couple of
> > > trivial pixel conve
On Fri, Sep 04, 2015 at 11:59:01AM -0700, Kenneth Graunke wrote:
> On Friday, September 04, 2015 07:47:31 PM Chris Wilson wrote:
> > On Fri, Sep 04, 2015 at 11:34:29AM -0700, Kenneth Graunke wrote:
> > > On Friday, September 04, 2015 07:24:54 PM Chris Wilson wrote:
> > > > The tiled memcpy fast pat
Emil Velikov writes:
> On 26 August 2015 at 12:52, Boyan Ding wrote:
>> This avoids generation of undefined packing in qir and qpu instructions,
>> fixing a lot of rendering errors.
>>
>> Fixes 8b36d107fdd (vc4: Pack the unorm-packing bits into a src MUL
>> instruction when possible.)
>>
>> Cc:
Mark Janes writes:
> By my count, this series fixes 59 separate dEQP tests on various
I incorrectly attributed 54 of those test fixes to this patch series. I
had applied this patch on top of Iago's
96ea1663082c4a17eaf59873190f1e9677623d91, which also improved dEQP.
> platforms. I found no reg
The values for resource word 6 have been taken from Catalyst traces.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_descriptors.c | 5 +
src/gallium/drivers/radeonsi/si_pipe.h| 1 +
src/gallium/drivers/radeonsi/si_state.c | 13 +++--
3 files chan
This patch series enables delta color compression (DCC) for Vulcanic
Islands GPU's. This should reduce memory bandwidth to increase
performance.
I have found no documentation on this feature, so most of the work is
based on guesswork, register names and Catalyst traces.
Some benchmarks I've ran:
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_blit.c| 18 --
src/gallium/drivers/radeonsi/si_descriptors.c | 2 +-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi
As the alignment requirements can be 32 KiB or more, also adding
an aligned buffer creation function.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeon/r600_buffer_common.c | 20 +++
src/gallium/drivers/radeon/r600_pipe_common.h | 6
src/gallium/drivers/radeon/r600_
This is needed by DCC when using compressed textures.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeonsi/si_state.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 5c9c866..3e11922 10064
The DCC fast clear for multisampled textures is still disabled
as that does not work correctly yet.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeon/r600_texture.c | 3 ++-
src/gallium/drivers/radeonsi/si_blit.c | 2 +-
src/gallium/winsys/amdgpu/drm/amdgpu_surface.c |
We cannot use the clear words from the cmask fast clear, so the
fast clears are somewhat limited.
The clear patterns have been taken from Catalyst traces.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeon/r600_texture.c | 48 ---
1 file changed, 38 inse
The flags to be enabled in the control registers have been taken from
Catalyst traces.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
src/gallium/drivers/radeon/r600_texture.c | 2 ++
src/gallium/drivers/radeon/r600d_common.h | 1 +
src/galli
As textures can be sampled without decompression and the fastclear bits
can be erased without decompressing, so add a new set of flags.
Signed-off-by: Bas Nieuwenhuizen
---
src/gallium/drivers/radeon/r600_pipe_common.h | 2 ++
src/gallium/drivers/radeonsi/cik_sdma.c | 6 --
src/galli
On Fri, Sep 4, 2015 at 12:43 PM, Julien Isorce wrote:
> It allows to call nouveau_vp3_bsp_next multiple times
> between one begin/end.
>
> It is required to support st/va.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=89969
>
> Signed-off-by: Julien Isorce
> ---
> src/gallium/drivers/nouveau/
With the introduction of ARB_shader_image_load_store, shaders
are able to perform random memory accesses to texture that
are not easily tracked by the driver. Rather than see if this
texture is bound to an ImageUnit when we perform a TexImage command
via the GPU, and so its dirty state untracked by
SHA1 is now used in all builds when HAVE_SHA1 is defined. Adjust src to
do the same thing, rather than predicating on shader cache.
Fixes: 04e201d0c02 ("mesa: change 'SHADER_SUBST' facility to work with env
variables")
Signed-off-by: Ilia Mirkin
---
src/util/Makefile.am | 4
src/util/
On Fri, Sep 4, 2015 at 3:47 PM, Bas Nieuwenhuizen
wrote:
> This patch series enables delta color compression (DCC) for Vulcanic
> Islands GPU's. This should reduce memory bandwidth to increase
> performance.
>
> I have found no documentation on this feature, so most of the work is
> based on guess
On Fri, Sep 4, 2015 at 7:11 AM, Oded Gabbay wrote:
> On Fri, Sep 4, 2015 at 1:17 AM, Roland Scheidegger wrote:
>> Oh, that's quite a subtle bug...
>>
>> Reviewed-by: Roland Scheidegger
>>
> Indeed, and it caused over 350 piglit tests to fail on ppc64le.
> See before and after:
> http://people.fr
On Fri, Sep 4, 2015 at 1:22 PM, Chris Wilson wrote:
> With the introduction of ARB_shader_image_load_store, shaders
> are able to perform random memory accesses to texture that
> are not easily tracked by the driver. Rather than see if this
> texture is bound to an ImageUnit when we perform a TexI
On Friday, September 04, 2015 05:00:47 PM Alex Deucher wrote:
> On Fri, Sep 4, 2015 at 3:47 PM, Bas Nieuwenhuizen
>
> wrote:
> > This patch series enables delta color compression (DCC) for Vulcanic
> > Islands GPU's. This should reduce memory bandwidth to increase
> > performance.
> >
> > I have
On Wed, Sep 02, 2015 at 01:03:43PM +0100, Chris Wilson wrote:
> On Wed, Aug 26, 2015 at 10:52:58AM -0700, Ben Widawsky wrote:
> > Docs suggest this is no longer required starting with Gen8.
> >
> > Perf (no regressions in n=20)
> > OglMultithread 0.67%
> > OglTerrainPanInst0.12%
> > trex
Both are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 04/09/2015 23:49, Bas Nieuwenhuizen wrote :
With DRI2, my system always gives me SCANOUT framebuffers, even when the
application is not running fullescreen, which means that decompression will
not happen in this common case. Although I realize now that I am not sure that
flag is always set wh
Thank you very much. I'm impressed.
Sorry, but this will take some time for me to review because I'm very
busy currently. I will have to check with internal documentation if
everything is correct. The idea of not using DCC for scanout/shared
buffers is great.
Marek
On Fri, Sep 4, 2015 at 9:47 PM
On Fri, Sep 04, 2015 at 02:40:54PM -0700, Jason Ekstrand wrote:
> On Fri, Sep 4, 2015 at 1:22 PM, Chris Wilson wrote:
> > With the introduction of ARB_shader_image_load_store, shaders
> > are able to perform random memory accesses to texture that
> > are not easily tracked by the driver. Rather th
On Thu, Sep 3, 2015 at 8:15 AM, Oded Gabbay wrote:
> round(val*dscale) produces a double result, as val and dscale are double.
> However, LLVMConstInt receives unsigned long long, so there is an
> implicit conversion from double to unsigned long long.
> This is an undefined behavior. Therefore, we
On Fri, Sep 4, 2015 at 6:57 PM, Matt Turner wrote:
> On Thu, Sep 3, 2015 at 8:15 AM, Oded Gabbay wrote:
>> round(val*dscale) produces a double result, as val and dscale are double.
>> However, LLVMConstInt receives unsigned long long, so there is an
>> implicit conversion from double to unsigned
On Fri, Sep 04, 2015 at 02:58:30PM -0700, Ben Widawsky wrote:
> On Wed, Sep 02, 2015 at 01:03:43PM +0100, Chris Wilson wrote:
> > On Wed, Aug 26, 2015 at 10:52:58AM -0700, Ben Widawsky wrote:
> > > Docs suggest this is no longer required starting with Gen8.
> > >
> > > Perf (no regressions in n=20
Hi,
This could then be applied with the correction s/i915/i965/ in the
commit message, right?
Regards, Joonas
On to, 2015-08-13 at 09:06 -0700, Ben Widawsky wrote:
> On Thu, Aug 13, 2015 at 10:38:43AM +0300, Joonas Lahtinen wrote:
> > Hi,
> >
> > On ke, 2015-08-12 at 18:34 -0700, Ben Widawsky w
Am 03.09.2015 um 10:48 schrieb Kenneth Graunke:
> This patch also introduces a lowering pass to convert the simple GS
> intrinsics to the new ones. See the comments above that for the
> rationale behind the new intrinsics.
>
> This should be useful for i965; it's a generic enough mechanism that I
Hi,
I compiled a toolchain based on LLVM/Clang v3.7.0 today and tested it
with an updated version of my Linux Graphics driver stack (see
attached logs).
Here on Ubuntu/precise AMD64 I required two patches (see attached 0001
and 0002) post-mesa-10.6.5+ to build it successfully.
Feel free to cherry
On Fri, Sep 04, 2015 at 12:39:52PM -0600, Brian Paul wrote:
> On 08/28/2015 11:03 AM, Jason Ekstrand wrote:
> >On Fri, Aug 28, 2015 at 7:43 AM, Brian Paul wrote:
> >>On 08/28/2015 12:43 AM, Jason Ekstrand wrote:
> >>>
> >>>On Thu, Aug 27, 2015 at 11:42 PM, Jason Ekstrand
> >>>wrote:
>
>
On Friday, September 04, 2015 11:56:29 AM Connor Abbott wrote:
> On Thu, Sep 3, 2015 at 2:32 PM, Kenneth Graunke wrote:
> > Prevents regressions in ~128 tests when fixing unlink_block_successors
> > in the next commit.
> >
> > XXX: Zero thought has been put into whether this is the right solution
90 matches
Mail list logo
