https://bugs.freedesktop.org/show_bug.cgi?id=79440
Priority: medium
Bug ID: 79440
Keywords: regression
CC: i...@freedesktop.org, juhapekka.heikk...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: prog_hash_table.c:146
Reviewed-by: Juha-Pekka Heikkila
On Fri, May 30, 2014 at 7:47 AM, Tapani Pälli wrote:
> So that prog_hash_table can use _mesa_error_no_memory function.
>
> Signed-off-by: Tapani Pälli
> ---
> src/glsl/Makefile.am | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/glsl/Makefile.am b/s
On 05/28/2014 09:41 PM, Ian Romanick wrote:
> On 05/22/2014 09:37 PM, Tapani Pälli wrote:
>> On 05/21/2014 07:52 PM, Ian Romanick wrote:
>>> On 05/21/2014 08:11 AM, Tapani wrote:
On 05/21/2014 05:43 PM, Tapani wrote:
> On 05/21/2014 01:27 AM, Ian Romanick wrote:
>> On 05/19/2014 10:08
The math instruction was Align1-only on Gen6 and we never updated this
to let it use Align16 features like writemasking on newer platforms.
total instructions in shared programs: 1686120 -> 1685507 (-0.04%)
instructions in affected programs: 48593 -> 47980 (-1.26%)
---
src/mesa/drivers/dri/i9
This breaks 'make check', I've send a patch that fixes it for me.
On 05/14/2014 08:55 PM, Juha-Pekka Heikkila wrote:
> Check calloc return values in hash_table_insert() and
> hash_table_replace()
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/mesa/program/prog_hash_table.c | 8
> 1
So that prog_hash_table can use _mesa_error_no_memory function.
Signed-off-by: Tapani Pälli
---
src/glsl/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/glsl/Makefile.am b/src/glsl/Makefile.am
index fd0e837..00261fd 100644
--- a/src/glsl/Makefile.am
+++ b/src/glsl/Makefile.am
On Thu, May 29, 2014 at 8:50 PM, Pavel Popov wrote:
> Signed-off-by: Pavel Popov
> ---
> src/mesa/drivers/dri/i965/brw_defines.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index c
Signed-off-by: Pavel Popov
---
src/mesa/drivers/dri/i965/brw_defines.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index c38e447..ed8efca 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
On 29/05/2014 23:31, Michel Dänzer a wrote :
On 30.05.2014 12:02, Axel Davy wrote:
Could you tell me what are your configure flags?
I tried the patches on top of febec731475a5b288cc50660b2d32780e395b950
I can still reproduce it on top of that.
and I didn't have any compiling issues, even w
On 30.05.2014 12:02, Axel Davy wrote:
> On 29/05/2014 04:58, Michel Dänzer wrote :
>> Still doesn't build here (on top of
>> http://lists.freedesktop.org/archives/mesa-dev/2014-May/060312.html
>> to fix today's build failure), see below. This fixes it, but I'm not
>> sure it's the proper fix:
>>
>
On 29/05/2014 04:58, Michel Dänzer wrote :
Still doesn't build here (on top of
http://lists.freedesktop.org/archives/mesa-dev/2014-May/060312.html
to fix today's build failure), see below. This fixes it, but I'm not
sure it's the proper fix:
Could you tell me what are your configure flags?
I t
I have just some comments below.
On Wed, May 28, 2014 at 8:37 PM, Eric Anholt wrote:
> Here's a series I started back in January as a little experiment.
> Basically, I feel guilty for pushing GLSL IR into the driver, and wish I'd
> just fixed up Mesa IR back in the day. But, given that we're sti
On Thu, May 29, 2014 at 8:15 PM, Axel Davy wrote:
> On 29/05/2014 13:37, Marek Olšák wrote :
>
>> Hi Axel,
>>
>> Could you please describe what "GPU offloading" means?
>
> It's using a different GPU to render and to display.
>
> Basically the gpu offloading support added by the patches is similar
From: Roland Scheidegger
This made sense when swizzled storage layout was used for rendering to tiles.
But nowadays the name just adds confusion (and makes for long lines).
---
src/gallium/drivers/llvmpipe/lp_rast.c | 16 +--
src/gallium/drivers/llvmpipe/lp_rast_priv.h | 42
From: Roland Scheidegger
Framebuffers can have NULL attachments since a while. llvmpipe handled
that properly for lp_rast_shade_quads_mask but it seems the change didn't
make it to lp_rast_shade_tile.
This fixes piglit fbo-drawbuffers-none test (though I need to increase
the FB_SIZE from 32 to 25
https://bugs.freedesktop.org/show_bug.cgi?id=79421
--- Comment #1 from Roland Scheidegger ---
I can't reproduce this, and valgrind didn't show anything suspicious neither.
Is this a regression?
I see the problem though, we're missing a test for non-zero cbuf in
lp_rast_shade_tile (which we alread
On 05/29/2014 10:47 AM, Adam Jackson wrote:
> This is entirely pointless. The DRI driver does not need any symbols
> from libGL, even if it did libGL would already be available to resolve
> them because that's how dlopen works.
That code was originally added by:
commit 061a3fe34051327fba418cc995
From: Ian Romanick
After compilation (and before linking) we can eliminate quite a few
built-in variables. Basically, any uniform or constant (e.g.,
gl_MaxVertexTextureImageUnits) that isn't used (with one exception) can
be eliminated. System values, vertex shader inputs (with one
exception), a
On Thu, May 29, 2014 at 2:26 PM, Ian Romanick wrote:
> On 05/29/2014 02:20 PM, Matt Turner wrote:
>> On Wed, May 28, 2014 at 6:35 PM, Ian Romanick wrote:
>>> From: Ian Romanick
>>>
>>> After compilation (and before linking) we can eliminate quite a few
>>> built-in variables. Basically, any uni
On 05/29/2014 02:20 PM, Matt Turner wrote:
> On Wed, May 28, 2014 at 6:35 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> After compilation (and before linking) we can eliminate quite a few
>> built-in variables. Basically, any uniform or constant (e.g.,
>> gl_MaxVertexTextureImageUnits) tha
On Wed, May 28, 2014 at 6:35 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> After compilation (and before linking) we can eliminate quite a few
> built-in variables. Basically, any uniform or constant (e.g.,
> gl_MaxVertexTextureImageUnits) that isn't used (with one exception) can
> be elimina
Reviewed-by: Chris Forbes
On Thu, May 29, 2014 at 7:32 PM, Chris Forbes wrote:
> Did this test run include forcing ARB_gpu_shader5 on?
>
> On Thu, May 29, 2014 at 7:06 PM, Kenneth Graunke
> wrote:
>> As far as I can tell, Broadwell doesn't need any of the SURFACE_STATE
>> workarounds for textu
---
src/gallium/drivers/svga/svga_state_fs.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 7931528..8f419fa 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium
To check if a shader bytcode exceeds the device limit. There's no
limit when using GBS.
---
src/gallium/drivers/svga/svga_shader.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/src/gallium/drivers/svga/svga_shader.h
b/src/gallium/drivers/svga/svga_shader.h
index 34
And rework the dummy shader code to match the fragment shader case.
---
src/gallium/drivers/svga/svga_state_vs.c | 44 --
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_vs.c
b/src/gallium/drivers/svga/svga_state_vs.
gen6 does not support multiple miplevels with stencil. Therefore we
need to layout it's miptree with no LOD0 spacing between the slices of
each miplevel.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_fbo.c | 3 ++-
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 31
(bc1acaa for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 2 ++
src/mesa/drivers/d
(08ef1dd for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 3 +++
src/mesa/drivers/dri/i965/gen6_depth_state.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/ge
(a23cfb8 for gen6)
In layered rendering this will be 0. Otherwise it will be the
selected slice.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 3 +++
src/mesa/drivers/dri/i965/gen6_depth_state.c | 10 ++
2 files changed, 13 insertions(+)
diff --git a/
(f3c886b for gen6)
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/intel_fbo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index e43e18b..22f707f 100644
--- a/src/mesa/drivers/dr
(bf25ee2 for gen6)
Previously we would always find the 2D sub-surface of interest,
and then program the surface to this location. Now we always
program the 3DSTATE_DEPTH_BUFFER at the start of the surface.
To select the lod/slice, we utilize the lod & minimum array
element fields.
We also must di
TODO: Find a good documented reason for this change.
This could be related to PRM Volume 1 Part 1: Graphics Core, Section
7.18.3.7.1 (Surface Arrays For all surfaces other than separate
stencil buffer):
"[DevSNB] Errata: Sampler MSAA Qpitch will be 4 greater than the
value calculated in the eq
gen6 stencil only supports LOD0 for stencil, forcing us to use an
array_spacing_lod0 type of miptree layout.
We use a combination of array_spacing_lod0 and a regular miptree in
that all slices of a particular LOD are combined without spacing for
additional LODs. This allows the surface to be set u
We will program the gen6 renderbuffer surface state differently to
enable layered rendering on gen6.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_context.c| 4 +
src/mesa/drivers/dri/i965/brw_state.h |
Previously array spacing lod0 was only used with a single mip level.
It indicated that no mip level spacing should be used between array
slices.
gen6 stencil only support LOD0, so we need to allocate the miptree
similar to array spacing lod0, except we also need space for more
than just one mip l
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 8a0912d..9293229 100644
--- a/src/mesa/d
Since gen6 stencil only supports LOD0, we need to program an offset to
the LOD when emitting the stencil/hiz.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 10 -
src/mesa/drivers/dri/i965/gen6_depth_state.c | 32 ++--
2 files chan
(e3a49e1 for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_
Rather than pointing the surface_state directly at a single
sub-image of the texture for rendering, we now point the
surface_state at the top level of the texture, and configure
the surface_state as needed based on this.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/brw_defines.h
(171e633 for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 17 ++
src/m
We will program the gen6 depth state differently to enable layered
rendering on gen6.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_context.c | 2 +-
src/mesa/drivers/dri/i965/brw_context.h | 13 ++
src/mesa/driv
The goal for this series was to allow layered rendering to work with
gen6. It also fixes 10 piglit tests, and a performance regression bug
(https://bugs.freedesktop.org/show_bug.cgi?id=56127).
This series is available on my gen6-layered branch in
git://people.freedesktop.org/~jljusten/mesa
I ran
On Wed, May 28, 2014 at 6:35 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> After compilation (and before linking) we can eliminate quite a few
> built-in variables. Basically, any uniform or constant (e.g.,
> gl_MaxVertexTextureImageUnits) that isn't used (with one exception) can
> be elimina
I think you misunderstood my suggestion. This code won't actually get
executed when running that test. What I was suggesting was to change
the shift/width argument passed to extbf when converting BREV, which
should in turn cause the test to start failing. The way in which you
need to modify the exp
How did you test this? I'm like 99% sure it's wrong. (But I'm avoiding
saying how it's wrong so that you don't just fix it to match what I
say, but instead work it out yourself by doing the tests that you
should have been doing in the first place. Or prove me wrong.)
On Thu, May 29, 2014 at 3:43 P
Tested with:
MESA_EXTENSION_OVERRIDE=GL_ARB_gpu_shader5 ./shader_runner
../tests/spec/arb_gpu_shader5/execution/built-in-functions/fs-bitfieldReverse.shader_test
-> green output, so this should be ok
the test was not change though...
On 29.05.2014 21:47, Ilia Mirkin wrote:
Can you verify th
On Thu, May 29, 2014 at 3:43 PM, Tobias Klausmann
wrote:
> Signed-off-by: Tobias Klausmann
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
> b/src/galli
Can you verify that you tested how the HW handles this, as well as
exactly how you did it (i.e. how did you modify the code + piglit
test, what the results were, etc)
On Thu, May 29, 2014 at 3:43 PM, Tobias Klausmann
wrote:
> Signed-off-by: Tobias Klausmann
> ---
> src/gallium/drivers/nouveau/c
Signed-off-by: Tobias Klausmann
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 93f7c2a..68b9a6d
Signed-off-by: Tobias Klausmann
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
index 68b9a6d..a567
Signed-off-by: Tobias Klausmann
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp
ind
Some operations (e.g. OP_MUL/OP_MAD/OP_EXTBF might have a subop set.
After folding, make sure that it is cleared
Signed-off-by: Tobias Klausmann
---
src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/nouveau/codegen/nv
Hi,
please review the following 4 patches:
1b1cfc6 nvc0/ir: Handle OP_BFIND when folding constant expressions
d2d2727 nvc0/ir: Handle OP_POPCNT when folding constant expressions
86a1ee6 nvc0/ir: Handle reverse subop for OP_EXTBF when folding constant
expressions
84563bf nvc0/ir: clear subop whe
- Original Message -
> On 29/05/14 16:45, Jose Fonseca wrote:
> > I'm happy however you guys want to address this, as long as it builds.
> >
> > The only reason I added $(top_builddir)/src/loader/libloader.la was because
> > the autotools build was broken for almost a week. I don't care
https://bugs.freedesktop.org/show_bug.cgi?id=79382
Emil Velikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: José Fonseca
Just happened to stumble across this registry key while debugging
something else.
This technique is much neater than trying to override opengl32.dll.
Also a few minors cleanups.
---
docs/llvmpipe.html | 52
1 file changed,
https://bugs.freedesktop.org/show_bug.cgi?id=79263
Emil Velikov changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 29/05/14 16:45, Jose Fonseca wrote:
> I'm happy however you guys want to address this, as long as it builds.
>
> The only reason I added $(top_builddir)/src/loader/libloader.la was because
> the autotools build was broken for almost a week. I don't care as much for
> autotools build breakage
On 29/05/2014 13:18, Marek Olšák wrote :
Hi Axel,
flush_resource should be called before ctx->st->flush.
Marek
Thanks, I'll update for the next version of the patch.
Axel Davy
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.fr
On 29/05/2014 13:37, Marek Olšák wrote :
Hi Axel,
Could you please describe what "GPU offloading" means?
It's using a different GPU to render and to display.
Basically the gpu offloading support added by the patches is similar to
enduro.
Some checks can be modified to:
info->src.box.width >
On 29/05/14 18:47, Adam Jackson wrote:
> This is entirely pointless. The DRI driver does not need any symbols
> from libGL, even if it did libGL would already be available to resolve
> them because that's how dlopen works.
>
FWIW Reviewed-by: Emil Velikov
-Emil
> Signed-off-by: Adam Jackson
>
humble ping
People interested in taking a look at the series ? Any input is appreciated
even if people are not familiar with mesa's build.
Francisco
Can you take a look the pipe-loader patches 04/23 - 08/23 ? They add a few
functions needed to make the pipe-loader st/dri aware. Patch 22 just move
Series is
- Original Message -
> From: Roland Scheidegger
>
> ---
> src/gallium/drivers/softpipe/sp_surface.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/drivers/softpipe/sp_surface.c
> b/src/gallium/drivers/softpipe/sp_surface.c
> index 102e8e8..768e898 10
- Original Message -
> This is entirely pointless. The DRI driver does not need any symbols
> from libGL, even if it did
I think DRI drivers did at one point depend on getting some glapi symbols from
libGL.so. I don't recall which situations the DRI driver could be loaded
without libG
This is entirely pointless. The DRI driver does not need any symbols
from libGL, even if it did libGL would already be available to resolve
them because that's how dlopen works.
Signed-off-by: Adam Jackson
---
src/glx/dri_common.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
di
Hi Axel,
Could you please describe what "GPU offloading" means?
Some checks can be modified to:
info->src.box.width > 0 &&
info->src.box.height > 0 &&
... resource->nr_samples <= 1
You don't have to check if the box depth equals 1. You just need to
make sure the box depths are equal to each oth
Hi Axel,
flush_resource should be called before ctx->st->flush.
Marek
On Thu, May 29, 2014 at 5:22 AM, Axel Davy wrote:
> Signed-off-by: Axel Davy
> ---
> src/gallium/state_trackers/dri/drm/dri2.c | 43
> ---
> 1 file changed, 40 insertions(+), 3 deletions(-)
>
>
This is just copy-pasted from dri2_drawable_process_buffers. While
that might be the easiest thing to do for an outside contributor, it
really doesn't help the people who have to maintain the code. I'd like
this patch to be scratched and rewritten by either reusing
dri2_drawable_process_buffers or
Am 29.05.2014 15:53, schrieb Brian Paul:
> On 05/28/2014 05:23 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> ---
>> src/gallium/docs/source/context.rst | 10 +++---
>> src/gallium/include/pipe/p_state.h | 4 ++--
>> 2 files changed, 9 insertions(+), 5 deletions(-)
>>
>>
https://bugs.freedesktop.org/show_bug.cgi?id=79421
Priority: medium
Bug ID: 79421
Keywords: have-backtrace
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] SIGSEGV
src/gallium/drivers/llvmpipe/lp_rast_priv.h:218
These two are
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
These two are:
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=79382
--- Comment #4 from Fabio Pedretti ---
I cannot test myself, if it works for others, push it.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-d
I'm happy however you guys want to address this, as long as it builds.
The only reason I added $(top_builddir)/src/loader/libloader.la was because the
autotools build was broken for almost a week. I don't care as much for
autotools build breakage as scons build breakage, but I still don't like
On 05/29/2014 01:21 AM, Iago Toral wrote:
> Hi Kenneth,
>
> On Wed, 2014-05-28 at 12:42 -0700, Kenneth Graunke wrote:
>> On 05/27/2014 03:50 AM, Iago Toral Quiroga wrote:
>>> In Gen < 6 the hardware generates a runtime bit that indicates whether AA
>>> data
>>> has to be sent as part of the frame
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 68690, which changed state.
Bug 68690 Summary: Dark screen in Europa Universalis IV on Intel, R600g and
RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=68690
What|Removed |Added
On 05/28/2014 05:23 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
---
src/gallium/docs/source/context.rst | 10 +++---
src/gallium/include/pipe/p_state.h | 4 ++--
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/gallium/docs/source/context.rst
b/src/galliu
On 29/05/2014 04:58, Michel Dänzer wrote :
On 29.05.2014 12:22, Axel Davy wrote:
DRI_PRIME is not very handy, because you have to launch the executable
with it set, which is not always easy to do.
By using drirc, the user specifies the target executable
and the device to use. After that the prog
https://bugs.freedesktop.org/show_bug.cgi?id=79382
--- Comment #3 from Jos van Wolput ---
(In reply to comment #1)
> Does the following patch help ? http://patchwork.freedesktop.org/patch/26746/
Works for me too!
--
You are receiving this mail because:
You are the assignee for the bug.
___
On 29.05.2014 12:22, Axel Davy wrote:
> DRI_PRIME is not very handy, because you have to launch the executable
> with it set, which is not always easy to do.
> By using drirc, the user specifies the target executable
> and the device to use. After that the program will be launched everytime
> on th
Hi Kenneth,
On Wed, 2014-05-28 at 12:42 -0700, Kenneth Graunke wrote:
> On 05/27/2014 03:50 AM, Iago Toral Quiroga wrote:
> > In Gen < 6 the hardware generates a runtime bit that indicates whether AA
> > data
> > has to be sent as part of the framebuffer write SEND message. This affects
> > the
On 24/04/14 13:19, Frank Binns wrote:
Typically we want swaps to occur during vertical blank to avoid
tearing. However, when the swap interval is 0 we want to go
as quickly as possible even if this results in tearing.
Indicate to the X server that it should attempt to do an
asynchronise swap whe
Did this test run include forcing ARB_gpu_shader5 on?
On Thu, May 29, 2014 at 7:06 PM, Kenneth Graunke wrote:
> As far as I can tell, Broadwell doesn't need any of the SURFACE_STATE
> workarounds for textureGather() bugs, so there's no need to emit
> a second set of identical copies.
>
> To keep
As far as I can tell, Broadwell doesn't need any of the SURFACE_STATE
workarounds for textureGather() bugs, so there's no need to emit
a second set of identical copies.
To keep things simple, just point the gather surface index base to the
same place as the texture surface index base.
Signed-off-
84 matches
Mail list logo
