On Wednesday, April 22, 2015 02:19:35 PM Ian Romanick wrote:
> Assuming this solves the GPU hangs, the series is
>
> Reviewed-by: Ian Romanick
Hmm? What GPU hangs? These patches solve misrendering in
GLbenchmark 2.7/TRex on Broadwell, where there were a bunch of stray
triangles.
When our glBu
Assuming this solves the GPU hangs, the series is
Reviewed-by: Ian Romanick
On 04/22/2015 02:13 PM, Kenneth Graunke wrote:
> The BLT engine on Gen8+ requires linear surfaces to be cacheline
> aligned. This restriction was added as part of converting the BLT to
> use 48-bit addressing.
>
> inte
The BLT engine on Gen8+ requires linear surfaces to be cacheline
aligned. This restriction was added as part of converting the BLT to
use 48-bit addressing.
intel_emit_linear_blit needs to handle blits that are not cacheline
aligned, as we use it for arbitrary glBufferSubData calls and subrange
m
The BLT engine on Gen8+ requires linear surfaces to be cacheline
aligned. This restriction was added as part of converting the BLT to
use 48-bit addressing.
The main user, intel_emit_linear_blit, now handles this properly.
But we might also have linear miptrees; just refuse to blit those.
Bugzil
On Tuesday, April 21, 2015 03:25:07 PM Matt Turner wrote:
> This was present in Eric's initial implementation of the compaction code
> for Sandybridge (commit 077d01b6). There is no documentation saying this
> is necessary, and removing it causes no regressions in piglit on any
> platform.
>
> In
Reviewed-by: Ian Romanick
On 04/17/2015 06:52 AM, Brian Paul wrote:
> This should be more efficient than the previous snprintf() solution.
> But more importantly, it avoids a buffer overflow bug that could result
> in crashes or unpredictable results when processing very large interface
> blocks.
https://bugs.freedesktop.org/show_bug.cgi?id=90130
--- Comment #5 from Roland Scheidegger ---
Or even better, a piglit test :-).
I suspect there's an issue with the prim assembler in draw.
Since from a quick look it seems like the prim assembler would always reset the
prim_id it's going to injec
FWIW, series is Reviewed-by: Ilia Mirkin
But I'm not extremely familiar with all that texture logic. May be
nice to recruit someone to review who knows this stuff... maybe Jason
Ekstrand? Or just push and sort any issues out later.
-ilia
On Tue, Apr 21, 2015 at 9:43 PM, Dave Airlie wrote:
>
Parts of this were implemented previously, so finish it off.
v2: fix getteximage falling into the integer check
add fixes for the FBO paths, (fbo-stencil8 test).
v3: fix getteximage path harder.
v4: remove swapbytes from getteximage path (Ilia)
v5: brown paper bag the swapbytes removal. (Ilia
Parts of this were implemented previously, so finish it off.
v2: fix getteximage falling into the integer check
add fixes for the FBO paths, (fbo-stencil8 test).
v3: fix getteximage path harder.
v4: remove swapbytes from getteximage path (Ilia)
Signed-off-by: Dave Airlie
---
src/mesa/main/
if we support stencil texturing, enable texture_stencil8
there is no requirement to support native S8 for this,
the texture can be converted to x24s8 fine.
v2: fold fixes from Marek in:
a) put S8 last in the list
b) fix renderable to always test for d/s renderable
fixup the texture case
This has some fixups since last version, I've moved the teximage patch
to the end someone from Intel can fix that up once they add stencil8
to i965 and test it.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/
copy drivers from the stencil_texturing list,
softpipe is definitely broken for stencil texturing
since it uses float, but I'll look at that later.
v2.1: update relnotes
Signed-off-by: Dave Airlie
---
docs/GL3.txt | 2 +-
docs/relnotes/10.6.0.html | 1 +
2 files changed, 2 insertio
This was using the wrong extension, ARB_stencil_texturing
doesn't mention any changes in this area.
(This should only be pushed once Intel supports stencil8
and fixes meta.)
Signed-off-by: Dave Airlie
---
src/mesa/main/teximage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=90130
--- Comment #4 from Ilia Mirkin ---
By the way, supplying an apitrace that demonstrates the issue would make
debugging this quite useful. (https://github.com/apitrace/apitrace)
--
You are receiving this mail because:
You are the QA Contact for
https://bugs.freedesktop.org/show_bug.cgi?id=90130
--- Comment #3 from Ilia Mirkin ---
(In reply to Ken Martin from comment #2)
> I'm not sure if I am looking up the driver correctly but a version of
> glxinfo I installed says
>
> OpenGL vendor string: VMware, Inc.
> OpenGL renderer string: Gall
https://bugs.freedesktop.org/show_bug.cgi?id=90130
--- Comment #2 from Ken Martin ---
I'm not sure if I am looking up the driver correctly but a version of glxinfo I
installed says
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits)
OpenGL vers
https://bugs.freedesktop.org/show_bug.cgi?id=90130
--- Comment #1 from Ilia Mirkin ---
Any particular driver this happens on?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-dev ma
This was present in Eric's initial implementation of the compaction code
for Sandybridge (commit 077d01b6). There is no documentation saying this
is necessary, and removing it causes no regressions in piglit on any
platform.
In fact, the BSpec says
- "[Nop and Illegal] cannot be compressed.";
Anuj Phogat writes:
> This will allow Skylake to use _mesa_meta_pbo_GetTexSubImage() for reading
> YF/YS
> tiled surfaces.
>
> V2: Make changes suggested by Neil.
>
> Signed-off-by: Anuj Phogat
> Cc: Neil Roberts
> ---
> src/mesa/drivers/common/meta.h | 1 +
> src/mesa/drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=90130
Bug ID: 90130
Summary: gl_PrimitiveId seems to reset at 340
Product: Mesa
Version: 10.5
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: cri
This extension allows the same thing you can do with MSAA visuals, but
with actual textures. Additionally it allows a tiler's pipeline to
stay MSAA until the end, at which point the resolve happens to slower
memory (and it's thus advantageous for that to not be multisampled).
I've had a few though
From: Enpeng Xu
Currently, a simple egl test case will fail like this:
eglMakeCurrent(dpy, surf, surf, ctx);
eglDestroyContext(dpy, ctx);
ctx2 = eglGetCurrentContext(); // ctx2 will be EGL_NO_CONTEXT
assert(ctx == ctx2);
It's caused by function _eglGetContextHandle, the function will check the
Le 20/04/2015 07:08, Axel Davy a écrit :
Le 20/04/2015 03:58, Michel Dänzer a écrit :
On 19.04.2015 06:17, Axel Davy wrote:
v3: put the xcb_connection in dri3_screen, instead of dri3_context
What's the rationale for that? Couldn't that result in the same
xcb_connection being used in several th
On Tue, Apr 21, 2015 at 5:45 PM, Emil Velikov wrote:
> Hmm pretty sure I've read somewhere (old version of GCC's manual?) that
> such warnings are enabled by default and cannot be controlled by the
> compiler (for C++ of course). I'm not an C++ expect so it could be that
> the standard does not re
On Tue, Apr 21, 2015 at 9:59 AM, Matt Turner wrote:
> I don't know how reasonable this suggestion is until I read further in
> the series, but I'd rather pass 'p' to the brw_inst functions instead
> of p->devinfo.
>
> That would match better with brw_$INST functions and would shorten the
> argumen
On Fri, Apr 17, 2015 at 7:11 PM, Jason Ekstrand wrote:
> Since commit 2881b123, we have used 0/~0 for representing booleans on all
> gens. However, we still had a bunch of places in the visitor code where we
> were still referring to ctx->Const.UniformBooleanTrue. Since this is
> always ~0, we c
On Fri, Apr 17, 2015 at 7:11 PM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_vec4.h | 1 +
> src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 87
> +++-
> 2 files changed, 42 insertions(+), 46 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i
On Tue, Apr 21, 2015 at 1:14 PM, Matt Turner wrote:
> On Fri, Apr 17, 2015 at 7:11 PM, Jason Ekstrand wrote:
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.h | 1 -
>> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 11 +--
>> 2 files changed, 1 insertion(+), 11 deletions(-)
>>
On Fri, Apr 17, 2015 at 7:11 PM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs.h | 1 -
> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 11 +--
> 2 files changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
> b/src/
On Fri, Apr 17, 2015 at 7:11 PM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_clip.c | 2 +-
> src/mesa/drivers/dri/i965/brw_clip_line.c| 13 ++---
> src/mesa/drivers/dri/i965/brw_clip_tri.c | 4 ++--
> src/mesa/drivers/dri/i965/brw_clip_util.c
On Fri, Apr 17, 2015 at 7:11 PM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_clip_line.c| 21 +-
> src/mesa/drivers/dri/i965/brw_clip_tri.c | 45 +-
> src/mesa/drivers/dri/i965/brw_clip_unfilled.c| 26 +-
> src/mesa/drivers/dri/i965/brw_clip_util.c
On Tue, Apr 21, 2015 at 11:56 AM, Emil Velikov wrote:
> Hi Alex,
>
> On 20 April 2015 at 23:33, Alex Deucher wrote:
>> I'm pleased to announce the initial release of the new amdgpu driver.
>> This is a partial replacement for the radeon driver for newer AMD
>> asics. A number of components are s
On 04/21/2015 06:19 PM, Matt Turner wrote:
On Mon, Apr 20, 2015 at 10:37 PM, Matt Turner wrote:
On Mon, Apr 20, 2015 at 10:27 PM, Tapani Pälli wrote:
Signed-off-by: Tapani Pälli
---
src/glsl/linker.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/link
Hi Alex,
On 20 April 2015 at 23:33, Alex Deucher wrote:
> I'm pleased to announce the initial release of the new amdgpu driver.
> This is a partial replacement for the radeon driver for newer AMD
> asics. A number of components are still shared. Here is a comparison
> of the radeon and amdgpu s
On Mon, Apr 20, 2015 at 10:37 PM, Matt Turner wrote:
> On Mon, Apr 20, 2015 at 10:27 PM, Tapani Pälli wrote:
>> Signed-off-by: Tapani Pälli
>> ---
>> src/glsl/linker.cpp | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
>> index b6baa5d..08b41
Hmm pretty sure I've read somewhere (old version of GCC's manual?) that
such warnings are enabled by default and cannot be controlled by the
compiler (for C++ of course). I'm not an C++ expect so it could be that
the standard does not require declarations/prototypes for non static
functions ?
Seem
Emil Velikov writes:
> On 21/04/15 14:04, Francisco Jerez wrote:
>> EdB writes:
>>
>>> Later we can remove the compat code
>>>
>>> According to Francisco Jerez, it happen that some time llvm requiring exotic
>>> compilation flags and it would be preferable not to to contaminate the rest
>>> of
On 21/04/15 14:04, Francisco Jerez wrote:
> EdB writes:
>
>> Later we can remove the compat code
>>
>> According to Francisco Jerez, it happen that some time llvm requiring exotic
>> compilation flags and it would be preferable not to to contaminate the rest
>> of
>> the clover build and keep th
Hi Marek,
Must admit that the current "split"/location of the new winsys looks a
bit strange. I'm thinking that if one places the new winsys alongside
the radeon one (i.e. winsys/amdgpu/drm) things should still work and
thus we'll result in shorter and cleaner patch. See below for more details.
On 04/21/2015 07:01 AM, Emil Velikov wrote:
On 16/04/15 21:52, Brian Paul wrote:
---
src/mesa/main/shader_query.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index b5f1d08..ad936e5 100644
--- a/src/mesa/main/shader_quer
EdB writes:
> Later we can remove the compat code
>
> According to Francisco Jerez, it happen that some time llvm requiring exotic
> compilation flags and it would be preferable not to to contaminate the rest of
> the clover build and keep the 3 statics libs
Not terribly informative... Without
Marek Olšák writes:
> From: Marek Olšák
>
Hi Marek, looks mostly OK to me, a few nits inline,
> ---
> src/gallium/include/state_tracker/opencl_interop.h | 42 ++
> src/gallium/state_trackers/clover/Makefile.sources | 1 +
> src/gallium/state_trackers/clover/core/event.hpp | 4 +
Later we can remove the compat code
According to Francisco Jerez, it happen that some time llvm requiring exotic
compilation flags and it would be preferable not to to contaminate the rest of
the clover build and keep the 3 statics libs
---
src/gallium/state_trackers/clover/Makefile.am | 3 ++-
1
On 20/04/15 22:23, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> .../auxiliary/target-helpers/inline_drm_helper.h | 6 +-
> src/gallium/drivers/r300/r300_chipset.c| 2 +-
> src/gallium/drivers/r300/r300_context.h| 1 -
> src/gallium/drivers/r300/r300_screen.h
On Tuesday 21 April 2015 12:54:28 Emil Velikov wrote:
> On 20/04/15 21:34, EdB wrote:
> > Later we can remove the compat code.
> > ---
> >
> > src/gallium/state_trackers/clover/Makefile.am | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/src/gallium/state_trackers
Only C warns about that. I didn't see any warning with C++.
Marek
On Tue, Apr 21, 2015 at 3:44 PM, Emil Velikov wrote:
> On 14/04/15 22:19, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/gallium/include/state_tracker/opencl_interop.h | 42 ++
>> src/gallium/state_trackers
On 04/21/2015 04:01 PM, Emil Velikov wrote:
On 16/04/15 21:52, Brian Paul wrote:
---
src/mesa/main/shader_query.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index b5f1d08..ad936e5 100644
--- a/src/mesa/main/shader_quer
On 14/04/15 22:19, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/include/state_tracker/opencl_interop.h | 42 ++
> src/gallium/state_trackers/clover/Makefile.sources | 1 +
> src/gallium/state_trackers/clover/core/event.hpp | 4 ++
> src/gallium/state_trackers/clov
On 16/04/15 13:04, Predut, Marius wrote:
>
>> -Original Message-
>> From: Emil Velikov [mailto:emil.l.veli...@gmail.com]
>> Sent: Thursday, April 16, 2015 1:53 PM
>> To: Predut, Marius
>> Cc: ML mesa-dev
>> Subject: Re: [Mesa-dev] [PATCH] main: remove __FUNCTION__ defined because it
>> is
On 16/04/15 21:52, Brian Paul wrote:
> ---
> src/mesa/main/shader_query.cpp | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
> index b5f1d08..ad936e5 100644
> --- a/src/mesa/main/shader_query.cpp
> +++ b/src/mesa/main/shader_
On 20/04/15 21:34, EdB wrote:
> Later we can remove the compat code.
> ---
> src/gallium/state_trackers/clover/Makefile.am | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/Makefile.am
> b/src/gallium/state_trackers/clover/Makefile.am
> i
Hi all,
Here is the preliminary release schedule for Mesa 10.6. Personally I
would love if we can go up to Mesa 11.0 (Spinal Tap anyone ?) although
it might happen with the September release.
May 15th 2015 - Feature freeze/Release candidate 1
May 22st 2015 - Release candidate 2
May 29th 2015 - Re
On 21/04/15 08:37, Matt Turner wrote:
On Mon, Apr 20, 2015 at 10:27 PM, Tapani Pälli wrote:
Signed-off-by: Tapani Pälli
---
src/glsl/linker.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index b6baa5d..08b4137 100644
--- a/src/glsl/linker
On 21/04/15 08:27, Tapani Pälli wrote:
Commit 34df5eb introduced regression to GetActiveUniformBlockiv
when querying one of the following properties:
GL_UNIFORM_BLOCK_ACTIVE_UNIFORMS
GL_UNIFORM_BLOCK_ACTIVE_UNIFORM_INDICES
Implementation counted all uniforms in ubo directly while quer
On 21/04/15 08:27, Tapani Pälli wrote:
Signed-off-by: Tapani Pälli
---
src/mesa/main/shader_query.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 1428058..336598d 100644
--- a/src/mesa/main/shader_qu
56 matches
Mail list logo
