Kenneth Graunke writes:
> In brw_update_renderbuffer_surfaces(), if there are no color draw
> buffers, we always set up a null render target at surface index 0 so we
> have something to use with the FB write marking the end of thread.
>
> However, when we recently began computing surface indexes
This patches add MESA_copy_sub_buffer support to the dri sw loader and
then to gallium state tracker, llvmpipe, softpipe and other bits.
It reuses the dri1 driver extension interface, and it updates the swrast
loader interface for a new putimage which can take a stride.
I've tested this with gnom
On Tue, Nov 26, 2013 at 3:59 PM, Courtney Goeltzenleuchter <
court...@lunarg.com> wrote:
> With these changes, what needs to happen to commit these changes to master?
>
I'd like to do another quick review but I'm on vacation this week and not
finding much time for email/reviewing. Maybe in a few
On 27 November 2013 14:43, Ian Romanick wrote:
> On 11/27/2013 12:44 PM, Paul Berry wrote:
> > The compiler back-ends (i965's fs_visitor and brw_visitor,
> > ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this
> > for some time. Thanks to the preceding patch, the compiler front
Hi all,
I'm working for Linaro on enabling a zero copy path in GStreamer by
using dmabuf.
To make this possible I have patched gst wayland sink to use wayland
drm protocol: https://bugzilla.gnome.org/show_bug.cgi?id=711155
Today wayland drm protocol is limited to Mesa so I have decided to
move it
Wasn't EGLStreams supposed to solve the use case of passing hardware
buffers around in a standard way?
On Wed, Nov 27, 2013 at 1:22 PM, Jason Ekstrand wrote:
>
> On Nov 27, 2013 10:53 AM, "Benjamin Gaignard" <
> benjamin.gaign...@linaro.org> wrote:
> >
> > Hi all,
> >
> > I'm working for Linaro
On Nov 27, 2013 10:53 AM, "Benjamin Gaignard"
wrote:
>
> Hi all,
>
> I'm working for Linaro on enabling a zero copy path in GStreamer by
> using dmabuf.
> To make this possible I have patched gst wayland sink to use wayland
> drm protocol: https://bugzilla.gnome.org/show_bug.cgi?id=711155
>
> Toda
Series Reviewed-by: Jordan Justen
On Tue, Nov 26, 2013 at 3:54 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> glext.h has had all the necessary bits for years.
>
> Signed-off-by: Ian Romanick
> ---
> include/GL/gl.h | 33 -
> 1 file changed, 33 deletions(-)
>
On Thu, Nov 28, 2013 at 4:13 AM, Roland Scheidegger wrote:
> Looks good to me.
> Though frankly I don't know if that really is better than your idea of
> faking 4-sample resources - it at least is simpler. But noone else
> chimed in...
>
I'm pretty ambivalent about which way to go, this is probabl
On 11/27/2013 03:00 PM, Jordan Justen wrote:
> On Tue, Nov 26, 2013 at 5:11 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if
>> intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling
>> GLX_ARB_create_context).
>>
For those of you who don't know, freedesktop.org runs an instance of
Patchwork to aid in tracking patches that are in need of review. We've
just finished getting it integrated with the Mesa-dev list. Here's a
brief run-down of what Patchwork provides for us.
Automatic flow of patches in Patchwork
On Tue, Nov 26, 2013 at 5:11 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if
> intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling
> GLX_ARB_create_context).
>
> This fixes a regression in the piglit test
> "glx/
Hmm yes doing things like 1) will get hacky pretty fast.
resource_from_handle is more like a necessary kludge, because we can't
enforce everybody to use a common object type (like pipe_resource) for
sharing outside gallium. I wouldn't know how to do this cleanly there.
I agree that we're probably g
On Tue, Nov 26, 2013 at 5:11 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if
> intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling
> GLX_ARB_create_context).
>
> This fixes a regression in the piglit test
> "glx/
On 11/27/2013 12:44 PM, Paul Berry wrote:
> The compiler back-ends (i965's fs_visitor and brw_visitor,
> ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this
> for some time. Thanks to the preceding patch, the compiler front-end
> no longer breaks this assumption.
>
> This patch
https://bugs.freedesktop.org/show_bug.cgi?id=70766
--- Comment #4 from Andreas Hartmetz ---
The LLVM patch does the trick for me. With the patch, llvm-config --cxxflags
output contains -fno-rtti (at the very end) and Mesa drivers radeonsi and
swrast can be loaded.
--
You are receiving this mai
1) resource_from_handle and resource_get_handle only support 2D
textures without mipmaps on Radeon. Adding support for more texture
types is possible, but changes are needed in the kernel driver too,
which is where we store information about the layout of the resource.
2) This is not possible with
Yikes, really sorry for the trouble.
-- Chris
On Thu, Nov 28, 2013 at 10:40 AM, Matt Turner wrote:
> On Mon, Nov 25, 2013 at 12:20 AM, Chris Forbes wrote:
>> I've pushed these now, including dropping the old names for those debug bits.
>>
>> I've left the stats stuff as-is for now, but suggeste
On Mon, Nov 25, 2013 at 12:20 AM, Chris Forbes wrote:
> I've pushed these now, including dropping the old names for those debug bits.
>
> I've left the stats stuff as-is for now, but suggested more useful
> options in the docs.
I'm really unhappy that and how 195994fe4cd ("drop old INTEL_DEBUG
na
On 11/27/2013 10:47 AM, Kenneth Graunke wrote:
> On 11/23/2013 05:45 PM, Kenneth Graunke wrote:
>> On 11/23/2013 04:03 PM, Ian Romanick wrote:
>>> Would it be better to just make _mesa_glsl_get_builtin_function_shader a
>>> friend?
>>
>> In this case, I don't think it makes much practical differenc
On 11/27/2013 12:55 PM, Ian Romanick wrote:
> On 11/26/2013 03:54 PM, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> This extension enabled the use of texture array with fixed-function and
>> assembly fragment shaders. No applications are known to use this
>> extension.
>>
>> Signed-off-by: Ian
On 27 November 2013 12:44, Paul Berry wrote:
> The compiler back-ends (i965's fs_visitor and brw_visitor,
> ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when
> ir_loop::counter is non-null, it points to a fresh ir_variable that
> should be used as the loop counter (as opposed to an i
I forced the non-replicated compilation unconditionally by
fixing 'use_simd16_replicated_data' to 'false' and saw no
regressions on Ivy Bridge. I also checked the eu-instruction
dump before and after, and they were identical:
0x: mov(16) g114<1>F g2<0,1,0>F{ align1 WE_normal 1H };
0
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 24
2 files changed, 25 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index 7
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
src/mesa/drivers/dri/i965/brw_fs.cpp | 1 +
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 1 +
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 ++
4 files changed, 5 insertions(+)
No regressions on Ivy Bridge. I also checked the eu-instruction
dump before and after, and they were identical:
0x: mov(4) g114<1>F g2<4,4,1>F { align1 WE_all };
0x0010: sendc(16) null g114<8,8,1>F
render ( RT write, 1, 1, 12) mlen 1 rlen 0 { align1 WE_normal 1H EOT };
T
Documentation for R0 and R1 is taken from
fs_visitor::setup_payload_gen6().
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
b/src/
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index a937edb..d25c6cb 100644
--- a/src/mesa/
Prepares the generator to accept hand-crafted blorp programs.
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i96
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 6626a8c..e562db8 100644
--- a/src/m
As the entire structure is memset just before compilation.
Signed-off-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_blorp_clear.cpp | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_clear.cpp
index 0
One way to enable blorp programs on gen8 is to use the already
existing assembly generator. But the generator(s) take i965 fs
instructions as input while the existing blorp programs are
represented directly using the low level EU presentation.
Hence the existing logic needs to be lifted from direc
On 11/26/2013 03:54 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> This extension enabled the use of texture array with fixed-function and
> assembly fragment shaders. No applications are known to use this
> extension.
>
> Signed-off-by: Ian Romanick
I'm going to temporarily NAK this patch
Patches 16, 17 are:
Reviewed-by: Chris Forbes
I'm not quite sure I buy the 4K alignment for i965 in patch 15 -- it's
true that any real BO mappings will be 4K-aligned, but when we have to
return a temporary chunk of memory this seems excessive.
Ian?
On Wed, Nov 27, 2013 at 11:26 PM, Siavash El
From: Ian Romanick
The intention is that things like
int;
will generate a warning. However, we were also accidentally emitting
the same warning for things like
struct Foo { int x; };
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68838
Cc: Aras Pranc
If an ir_loop has a non-null "counter" field, the variable referred to
by this field is implicitly read and written by the loop. We need to
account for this in ir_variable_refcount, otherwise there is a danger
we will try to dead-code-eliminate the loop counter variable.
Note: at the moment the d
The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when
ir_loop::counter is non-null, it points to a fresh ir_variable that
should be used as the loop counter (as opposed to an ir_variable that
exists elsewhere in the instruction str
The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this
for some time. Thanks to the preceding patch, the compiler front-end
no longer breaks this assumption.
This patch adds code to validate the assumption so that if we hav
---
src/glsl/ir.h | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 4f775da..b898d61 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -1032,13 +1032,33 @@ public:
* If \c from and \c to are the same val
This should be possible with:
struct pipe_resource * (*resource_from_handle)(struct pipe_screen *,
const struct pipe_resource
*templat,
struct winsys_handle *handle);
Nothing impedes this to w
On 11/27/2013 10:59 AM, Paul Berry wrote:
> This field was neither initialized nor used. It was just dead memory.
> ---
> src/glsl/loop_analysis.h | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/src/glsl/loop_analysis.h b/src/glsl/loop_analysis.h
> index 769d626..98414b3 100644
> --
This field was neither initialized nor used. It was just dead memory.
---
src/glsl/loop_analysis.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/src/glsl/loop_analysis.h b/src/glsl/loop_analysis.h
index 769d626..98414b3 100644
--- a/src/glsl/loop_analysis.h
+++ b/src/glsl/loop_analysis.
On 11/23/2013 05:45 PM, Kenneth Graunke wrote:
> On 11/23/2013 04:03 PM, Ian Romanick wrote:
>> Would it be better to just make _mesa_glsl_get_builtin_function_shader a
>> friend?
>
> In this case, I don't think it makes much practical difference - the
> builtin_builder class is entirely contained
.. let me try that again.
I've been looking into adding support for the KHR_gl_*_image extensions to
mesa/gallium as was attempted here:
http://lists.freedesktop.org/archives/mesa-dev/2010-September/002900.html
Looking further into how creating an eglimage out of a cubemap face has got
me wonderi
Looks good to me.
Though frankly I don't know if that really is better than your idea of
faking 4-sample resources - it at least is simpler. But noone else
chimed in...
Roland
Am 27.11.2013 10:47, schrieb Dave Airlie:
> This adds a gallium cap that allows us to fake GL3.0 by
> not exposing MSAA o
On 11/27/2013 08:37 AM, Paul Berry wrote:
> On gen6, multisamble resolve blits use the SAMPLE message to blend
> together the 4 samples for each texel. For some reason, SAMPLE
> doesn't blend together the proper samples when the source format is
> L32_FLOAT or I32_FLOAT, resulting in blocky artifa
Hi,
This is my first post to this forum, so apologies if I say anything
horrendously wrong.
I've been looking into adding support for the KHR_gl_*_image extensions to
mesa/gallium as was attempted here:
___
mesa-dev mailing list
mesa-dev@lists.freedeskt
Am 27.11.2013 18:27, schrieb jfons...@vmware.com:
> From: José Fonseca
>
> ---
> src/gallium/auxiliary/util/u_dump.h | 3 ++
> src/gallium/auxiliary/util/u_dump_defines.c | 33
> src/gallium/drivers/trace/tr_context.c | 3 +-
> src/gallium/drivers/trace/tr_dump_de
From: José Fonseca
---
src/gallium/drivers/trace/tr_context.c| 82 +--
src/gallium/drivers/trace/tr_dump_state.c | 64
src/gallium/drivers/trace/tr_dump_state.h | 2 +
3 files changed, 133 insertions(+), 15 deletions(-)
diff --git a/src/
From: José Fonseca
---
src/gallium/auxiliary/util/u_dump.h | 3 ++
src/gallium/auxiliary/util/u_dump_defines.c | 33
src/gallium/drivers/trace/tr_context.c | 3 +-
src/gallium/drivers/trace/tr_dump_defines.h | 58 +
src/gallium/drivers/
Looks great. Thanks for doing this! Future is now.
Jose
- Original Message -
> This adds a gallium cap that allows us to fake GL3.0 by
> not exposing MSAA on sw rendering. It also forces the
> extra extensions needed for GL3.2. Along with a patch to
> raise the GLSL version in llvmpipe th
On 11/26/2013 07:42 PM, Timothy Arceri wrote:
> Hi Thomas,
>
> Looks like Siavash Eliasi beat you to it.
>
> But here is some quick feedback. You seem to have made the same mistake
> with your case statements [1]
> Also you shouldn't attach the patch to your email but should use
> git-send-email
On gen6, multisamble resolve blits use the SAMPLE message to blend
together the 4 samples for each texel. For some reason, SAMPLE
doesn't blend together the proper samples when the source format is
L32_FLOAT or I32_FLOAT, resulting in blocky artifacts.
To work around this problem, sample from the
Adding assertions won't fix the errors found by the static analysis tool
because they don't exist in release builds. The technical correct way
to deal with memory allocation failures in GL is to generate
GL_OUT_OF_MEMORY and return.
On 11/27/2013 06:53 AM, Juha-Pekka Heikkila wrote:
> Signed-off-
From: Ander Conselvan de Oliveira
The DRI image extension gained a lot of new entry points lately. Some
of the new additions have a slightly different signature. The planar
image introduces the concept of an image without a format from which
different well structured images can be created. The wa
From: Ander Conselvan de Oliveira
The only field from intelScreen used by the intel_region code is the
drm_intel_bufmgr, so take that as a parameter instead of the whole
screen.
---
src/mesa/drivers/dri/i965/brw_context.c |2 +-
src/mesa/drivers/dri/i965/intel_mipmap_tree.c |4 ++--
From: Ander Conselvan de Oliveira
Both __DRIimage and intel_region have width and height fields. They
actually differ when an image is created for a texture but are the
same in all the other cases. For images created from a planar image,
a special intel_region that represents only a part of the s
From: Ander Conselvan de Oliveira
Hi,
The main motivation for this series is to split the image code out of
intel_screen.c so that this could be compiled into a separate statically
linked library that we could also use in GBM.
The last patch is quite big, but I couldn't figure out a way to spli
From: Ander Conselvan de Oliveira
Prefix everything with intel_dri_image.
---
src/mesa/drivers/dri/i965/intel_screen.c | 116 +++---
1 file changed, 59 insertions(+), 57 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/inte
Signed-off-by: Juha-Pekka Heikkila
---
src/glx/clientattrib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/glx/clientattrib.c b/src/glx/clientattrib.c
index 1b306ea..6162b49 100644
--- a/src/glx/clientattrib.c
+++ b/src/glx/clientattrib.c
@@ -76,6 +76,9 @@ __indirect_glPushClientAtt
This fixes the issue for me,
However looking at your patch, I believe you made a small mistake.
I think with your patch, the RADEON_SURF_SCANOUT flag
would be always be set for cards inferior to SI,
since your calculation of scanout:
*scanout = !(bo->rws->gen >= DRV_SI && args.tiling_flags &
RA
Signed-off-by: Juha-Pekka Heikkila
---
src/mesa/main/attrib.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index c9332bd..5185f89 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1488,6 +1488,9 @@ init_array_attrib_data
On Tue, Nov 26, 2013 at 11:34 AM, Siavash Eliasi wrote:
> Now I understand why _mesa_realloc is not appropriate to use here. From
> spec:
>
> glBufferData creates a new data store for the buffer object currently
>> bound to target. Any pre-existing data store is deleted. The new data store
>> is
Signed-off-by: Petri Latvala
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 2 ++
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 6 ++
2 files changed, 8 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 73f91a0..0cbdc98
v2: Don't add function parameters, pass the required size in
prog_data->nr_params.
Signed-off-by: Petri Latvala
---
src/mesa/drivers/dri/i965/brw_vec4.h | 5 +++--
src/mesa/drivers/dri/i965/brw_vec4_gs.c| 5 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 7 +++
src/
Third version of this patch series sent in full, both patches changed
a bit.
As per advice, I assigned the required size to prog_data->nr_params,
which is unused until vec4_visitor::setup_uniforms() sets it
again. This is done in do_vs_prog() and do_gs_prog(), with
accompanying comments that expla
Hi all,
I was taking a look in i965 taking a closer look at the upload to GPU of
param and pull_param for vertex shaders. What I found was this:
1) in vec4_visitor::move_uniform_array_access_to_pull_constants(), those
uniforms that are relatively addressed are cloned from param to pull_para
Thank you very much Alex for the tip. I'll modify commits and send a v2
series of patches. Before that I want to make sure that patch #17 is
done correctly.
I'll be thankful if someone finds time to review and comment on this patch:
[Mesa-dev] [PATCH 17/17] Deleted gl_extensions::ARB_map_buff
This adds a gallium cap that allows us to fake GL3.0 by
not exposing MSAA on sw rendering. It also forces the
extra extensions needed for GL3.2. Along with a patch to
raise the GLSL version in llvmpipe this will expose GL3.3
on llvmpipe.
However we still need Marek's code for layered clears.
Sign
https://bugs.freedesktop.org/show_bug.cgi?id=72062
Tapani Pälli changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|mesa-dev@list
https://bugs.freedesktop.org/show_bug.cgi?id=72062
--- Comment #6 from Tapani Pälli ---
(In reply to comment #5)
> Ok, but I guess both patches are needed actually, because otherwise a
> completely-non-drm build would have a similar issue?
Yep, probably so. What is the type of build you are doin
https://bugs.freedesktop.org/show_bug.cgi?id=72062
--- Comment #5 from Samuel Thibault ---
Ok, but I guess both patches are needed actually, because otherwise a
completely-non-drm build would have a similar issue?
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=72062
--- Comment #4 from Tapani Pälli ---
(In reply to comment #2)
> Created attachment 89891 [details] [review]
> fix
>
> Could you try the attached patch?
>
> I wasn't completely sure whether dri2_authenticate was supposed to fail or
> not when dr
https://bugs.freedesktop.org/show_bug.cgi?id=72062
--- Comment #3 from Tapani Pälli ---
Created attachment 89892
--> https://bugs.freedesktop.org/attachment.cgi?id=89892&action=edit
patch to fix the issue
This patch adds additional HAVE_LIBDRM for x11_platform to compile correctly.
--
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=72062
--- Comment #2 from Samuel Thibault ---
Created attachment 89891
--> https://bugs.freedesktop.org/attachment.cgi?id=89891&action=edit
fix
Could you try the attached patch?
I wasn't completely sure whether dri2_authenticate was supposed to fai
https://bugs.freedesktop.org/show_bug.cgi?id=72062
--- Comment #1 from Tapani Pälli ---
More specifically, building mesa like this:
./autogen.sh --enable-gles2 --with-egl-platforms=x11
does not result in having a working egl and gles2 implementation. Reverting
a594cec7e3ef275c386054127a357110a1
https://bugs.freedesktop.org/show_bug.cgi?id=72062
Tapani Pälli changed:
What|Removed |Added
CC||samuel.thiba...@ens-lyon.or
https://bugs.freedesktop.org/show_bug.cgi?id=72062
Priority: medium
Bug ID: 72062
Assignee: mesa-dev@lists.freedesktop.org
Summary: build broken for x11 egl apps
Severity: critical
Classification: Unclassified
OS: All
78 matches
Mail list logo
