On Thu, Nov 28, 2013 at 11:45:54PM -0800, Kenneth Graunke wrote:
> On 11/27/2013 01:13 PM, Topi Pohjolainen wrote:
> > 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/s
On 11/28/2013 11:44 PM, Kenneth Graunke wrote:
> On 11/27/2013 01:13 PM, Topi Pohjolainen wrote:
>> 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 +++
>>
On 11/27/2013 01:13 PM, Topi Pohjolainen wrote:
> 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
On 11/27/2013 01:13 PM, Topi Pohjolainen wrote:
> 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(-)
>
>
On 11/28/2013 11:15 PM, Timothy Arceri wrote:
Hi guys,
I received the following submitted as an Issue on my github account.
Maybe someone here has a project they can suggest.
Is NewbieProjects too "newbie" for this?
http://wiki.freedesktop.org/dri/NewbieProjects/
--
Petri Latvala
On 11/27/2013 01:10 PM, Topi Pohjolainen wrote:
> 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/d
On Thu, Nov 28, 2013 at 4:55 AM, Ilia Mirkin wrote:
> On Thu, Nov 28, 2013 at 4:38 AM, Ilia Mirkin wrote:
>> Hi Brian,
>>
>> I've just completed a bisect which pointed out a3ed98f7aa (gallium:
>> new, unified pipe_context::set_sampler_views() function) as the bad
>> commit.
>>
>> Starting with th
Hi Eric,
I believe your commit 95bd8a332d1 might be the culprit of some crashes
I've seen. I had earlier identified a different commit via bisection,
but I believe it just happened to move some bits around that made the
memory stomping effects more noticeable.
On Thu, Nov 28, 2013 at 4:55 AM, Ili
A pipe_resource can only be used with the pipe_screen and all its
contexts. You can't use the same pipe_resource in 2 pipe_screens. The
correct way to get the pipe_resource from one pipe_screen to another
is to export it using resource_get_handle and import it in the other
pipe_screen using resourc
Hello Grigori,
works perfectly - thank you very much!
Kind regards,
Michal
"Unnamed record types are assigned to separate types per stage, e.g.
uniform struct { ... } a;
if defined in both vertex and fragment shader, will result in two
separate types of different name. When linking the sha
Hi guys,
I received the following submitted as an Issue on my github account.
Maybe someone here has a project they can suggest.
Thanks,
Tim
On Thu, 2013-11-28 at 10:19 -0800, LeonardoItalia wrote:
> Hello, I am an undergraduate Computer Science student from the
> University of Bari, in southern
Hi,
On 28 November 2013 10:04, Pekka Paalanen wrote:
> On Thu, 28 Nov 2013 10:24:33 +0100
> Benjamin Gaignard wrote:
>> From my point of view wl_drm isn't link to Mesa, it is only about
>> exchange buffers by using a file descriptor and, for example, doesn't
>> rely on EGL.
>>
>> I understand th
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 Fri, Nov 29, 2013 at 6:20 AM, Dave Airlie wrote:
>> Instead of I'd prefer that we added an optional rectangle structure pointer
>> to flush_frontbuffer. Less one entrypoint, and both paths can probably share
>> a lot of code in most cases. Ditto for sw_winsys.h.
>>
>
> Yeah I thought someone
> Instead of I'd prefer that we added an optional rectangle structure pointer
> to flush_frontbuffer. Less one entrypoint, and both paths can probably share
> a lot of code in most cases. Ditto for sw_winsys.h.
>
Yeah I thought someone might suggest that, it was just a lot larger
patch results,
https://bugs.freedesktop.org/show_bug.cgi?id=71944
--- Comment #6 from Vadim Girlin ---
(In reply to comment #5)
> I tried to look a little closer at the group of instructions where you
> thought the problem was. But I can't really wrap my head around how the
> scheduling works.
Yes, sometimes i
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) 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_var
+ /* The assignmnet to the variable in the loop must be unconditional and
+ * not inside a nested loop.
*/
s/assignmnet/assignment/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/
Previously, when visiting an ir_call, loop analysis would only mark
the innermost enclosing loop as containing a call. As a result, when
encountering a loop like this:
for (i = 0; i < 3; i++) {
for (int j = 0; j < 3; j++) {
foo();
}
}
it would incorrectly conclude tha
This function is about to get more complex.
---
src/glsl/loop_analysis.cpp | 91 +-
src/glsl/loop_analysis.h | 4 ++
2 files changed, 70 insertions(+), 25 deletions(-)
diff --git a/src/glsl/loop_analysis.cpp b/src/glsl/loop_analysis.cpp
index b08241a
Previously, loop analysis would set
this->conditional_or_nested_assignment based on the most recently
visited assignment to the variable. As a result, if a vaiable was
assigned to more than once in a loop, the flag might be set
incorrectly. For example, in a loop like this:
int x;
for (i
Previously, when visiting a variable dereference, loop analysis would
only consider its effect on the innermost enclosing loop. As a
result, when encountering a loop like this:
for (int i = 0; i < 3; i++) {
for (int j = 0; j < 3; j++) {
...
i = 2;
}
}
it would
Hi
last month Intel released an OpenGL driver and spec (
http://www.opengl.org/registry/specs/INTEL/fragment_shader_ordering.txt) of
PixelSync for OpenGL..
I didn't say much of suggesting a Mesa implementation since the ext
requires ARB_shader_image_load_store..
As recently seems Francisco Jerez "C
https://bugs.freedesktop.org/show_bug.cgi?id=71944
--- Comment #5 from Martin Andersson ---
I tried to look a little closer at the group of instructions where you thought
the problem was. But I can't really wrap my head around how the scheduling
works.
When is the data dependency checking done?
https://bugs.freedesktop.org/show_bug.cgi?id=71944
--- Comment #4 from Martin Andersson ---
Created attachment 89964
--> https://bugs.freedesktop.org/attachment.cgi?id=89964&action=edit
Output from PSC_DEBUG
--
You are receiving this mail because:
You are the assignee for the bug.
___
On 28 November 2013 09:29, Eric Anholt wrote:
> Paul Berry writes:
>
> > 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
> >
Revision 2:
- Making GL_ARB_map_buffer_alignment a desktop OpenGL extension only.
---
src/mesa/main/get.c| 1 -
src/mesa/main/get_hash_params.py | 2 +-
src/mesa/main/mtypes.h | 1 -
src/mesa/state_tracker/st_extensions.c | 2 --
4 files changed, 1 inserti
Revision 2:
- Changed allocation alignment of llvmpipe_displaytarget_layout.
---
src/gallium/drivers/llvmpipe/lp_texture.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 0088b6a.
Revision 2:
- Changed allocation alignment in softpipe_displaytarget_layout.
---
src/gallium/drivers/softpipe/sp_texture.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/softpipe/sp_texture.c
b/src/gallium/drivers/softpipe/sp_texture.c
index 370f2b4..d
Paul Berry writes:
> 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 variabl
- Original Message -
> 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 t
Hi Tim,
I've given your suggestion some thought - and while it looks like
something which would work, my time schedule currently is too tight
(regardless of money involved) to implement support for the extension. I
might think about it again in three months, if the extension has not
been imple
Hey Matt,
The speedup was only observed on discrete GPUs so far, I have no data
about APUs.
Best regards,
Tony
Am 26.11.2013 04:50, schrieb Matt Harvey:
Hi Tony,
I guess the lack of response means that neither of those extensions is
on anyone's road map for right now.
I have a quick ques
Thanks for the replies. I think my main question (feasibility) has been
answered in the negative.
As Marek says, resource_from_handle only works for 2D non-mipmapped
pipe_resources for the radeon driver. This seems to be the same for svga
driver also. Even if more drivers were supporting mipmappe
On Thu, 28 Nov 2013 10:24:33 +0100
Benjamin Gaignard wrote:
> Jason,
>
> From my point of view wl_drm isn't link to Mesa, it is only about
> exchange buffers by using a file descriptor and, for example, doesn't
> rely on EGL.
>
> I understand that other graphic stacks could have defined their o
On Thu, Nov 28, 2013 at 4:38 AM, Ilia Mirkin wrote:
> Hi Brian,
>
> I've just completed a bisect which pointed out a3ed98f7aa (gallium:
> new, unified pipe_context::set_sampler_views() function) as the bad
> commit.
>
> Starting with that commit, I see things like
>
> *** glibc detected *** glretr
Hi Brian,
I've just completed a bisect which pointed out a3ed98f7aa (gallium:
new, unified pipe_context::set_sampler_views() function) as the bad
commit.
Starting with that commit, I see things like
*** glibc detected *** glretrace: corrupted double-linked list:
0x016632f0 ***
but it ca
Jason,
>From my point of view wl_drm isn't link to Mesa, it is only about
exchange buffers by using a file descriptor and, for example, doesn't
rely on EGL.
I understand that other graphic stacks could have defined their own
way to for zero-copy (and so other protocols).
I don't aim to make gstre
---
src/gallium/drivers/ilo/ilo_screen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/ilo/ilo_screen.c
b/src/gallium/drivers/ilo/ilo_screen.c
index a345b70..466b21c 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_scree
On 10/23/2013 11:41 AM, Jørgen Lind wrote:
---
src/egl/drivers/dri2/egl_dri2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index b29eb1c..b143a95 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/
---
src/mesa/drivers/dri/nouveau/nouveau_bufferobj.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/nouveau/nouveau_bufferobj.c
b/src/mesa/drivers/dri/nouveau/nouveau_bufferobj.c
index 717c0b8..dc16585 100644
--- a/src/mesa/drivers/dri/nouveau/nouveau_b
---
src/mesa/main/get.c| 1 -
src/mesa/main/get_hash_params.py | 2 +-
src/mesa/main/mtypes.h | 1 -
src/mesa/state_tracker/st_extensions.c | 2 --
4 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
inde
---
src/mesa/drivers/dri/i915/intel_buffer_objects.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_buffer_objects.c
b/src/mesa/drivers/dri/i915/intel_buffer_objects.c
index bc58c70..4fbf954 100644
--- a/src/mesa/drivers/dri/i915/intel_buff
---
src/gallium/drivers/llvmpipe/lp_texture.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c
b/src/gallium/drivers/llvmpipe/lp_texture.c
index 0088b6a..d1ebeda 100644
--- a/src/gallium/drivers/llvmpipe/lp_texture.c
+++ b/src/galli
---
src/mesa/main/extensions.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index 104618c..6f73694 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -107,7 +107,7 @@ static const struct extensi
Revision 2:
- Fixed setting switch cases prior to PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT
incorrectly.
---
src/gallium/drivers/i915/i915_screen.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/i915/i915_screen.c
b/src/gallium/drivers/i915/i915_screen.c
index
Revision 2:
- Fixed memory leak.
---
src/mesa/main/bufferobj.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index b27f592..111bea3 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -416,9 +4
---
src/mesa/drivers/dri/radeon/radeon_buffer_objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/radeon/radeon_buffer_objects.c
b/src/mesa/drivers/dri/radeon/radeon_buffer_objects.c
index 40a16c3..ba7ab37 100644
--- a/src/mesa/drivers/dri/radeon/rad
---
src/mesa/drivers/dri/i965/brw_context.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 6e09077..679ec0e 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_conte
---
src/mesa/state_tracker/st_extensions.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index e8d0902..4707447 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_trac
---
src/gallium/drivers/i915/i915_resource_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c
b/src/gallium/drivers/i915/i915_resource_buffer.c
index 80ec43a..fd29524 100644
--- a/src/gallium/drivers/i915/i915_resource_buff
Revision 2:
- Fixed setting switch cases prior to PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT
incorrectly.
---
src/gallium/drivers/svga/svga_screen.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/svga/svga_screen.c
b/src/gallium/drivers/svga/svga_screen.c
index
Revision 2:
- Fixed setting switch cases prior to PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT
incorrectly.
---
src/gallium/drivers/llvmpipe/lp_screen.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
---
src/mesa/main/context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index 87a4a35..9c516a2 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -586,6 +586,7 @@ _mesa_init_constants(struct gl_context *ctx)
ctx->Cons
---
src/gallium/drivers/softpipe/sp_texture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/softpipe/sp_texture.c
b/src/gallium/drivers/softpipe/sp_texture.c
index 370f2b4..fb20748 100644
--- a/src/gallium/drivers/softpipe/sp_texture.c
+++ b/src/gallium/d
Hello, this is V2 series of patches to accomplish *Enable
ARB_map_buffer_alignment in all drivers* newbie project suggested by Ian
Romanick.
Revision 2:
- Fixed setting switch cases prior to PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT
incorrectly.
- Fixed memory leak.
Best regards,
Siavash Eliasi.
Sia
Revision 2:
- Fixed setting switch cases prior to PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT
incorrectly.
---
src/gallium/drivers/softpipe/sp_screen.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/softpipe/sp_screen.c
b/src/gallium/drivers/softpipe/sp_screen.c
Mesa 9.2.4 has been released. Mesa 9.2.4 is a bug fix release which
fixes bugs fixed since the 9.2.3 release, (see below for a list of
changes).
The tag in the git repository for Mesa 9.2.4 is 'mesa-9.2.4'.
Mesa 9.2.4 is available for download at
ftp://freedesktop.org/pub/mesa/9.2.4/
md5sums:
2
58 matches
Mail list logo