From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeon/r600_pipe_common.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index 42e681d..3def444 10064
From: Michel Dänzer
Based on the corresponding SI support. Same as that, this is currently
only enabled for one-dimensional buffer copies due to issues with
multi-dimensional SDMA copies.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/Makefile.sources | 1 +
src/gallium/driver
https://bugs.freedesktop.org/show_bug.cgi?id=90657
Bug ID: 90657
Summary: [Patch] Mesa 10.6.0-rc1 doesn't build on FreeBSD
Product: Mesa
Version: 10.6
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=90657
--- Comment #1 from Koop Mast ---
Created attachment 116040
--> https://bugs.freedesktop.org/attachment.cgi?id=116040&action=edit
Fix build on FreeBSD
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the ass
The new functions in gallium/radeon shouldn't be inline, because
inlining them isn't critical for performance.
Also, I don't see a point in functions that only contain one line.
Especially radeon_llvm_dispose_kernel_module looks like an unnecessary
wrapper.
Marek
On Tue, May 26, 2015 at 2:05 AM,
For the series:
Reviewed-by: Marek Olšák
Marek
On Tue, May 26, 2015 at 9:28 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src
https://bugs.freedesktop.org/show_bug.cgi?id=90657
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hello;
I'd like to ping if this approach would be ok. We've had some
discussions with Curro about it and overall it would seem nicer to move
this check to happen at compile time. However, this seems quite a
problematic move. I'll try explain below why;
The overall problem with the failing us
On 21/05/15 02:02, Dylan Baker wrote:
From: Dylan Baker
This results in slightly less code, but code that is much more readable.
It has the advantage of putting everything together in one place, all of
the code is self documenting, help messages are auto-generated, choices
are automatically enf
argparse type is a nice type saver for simple data types, but it doesn't
look a good fit for the input XML file:
- Certain implementations of argparse (particularly python 2.7.3's)
invoke the type constructor for the default argument even when an
option is passed in the command line. Causing
From: Marek Olšák
This is required by radeonsi.
The code was moved because with_egl_platforms was used before
the default was set.
---
configure.ac | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/configure.ac b/configure.ac
index 84b404e..dbe590f 1006
From: Marek Olšák
No particular reason other than most people should always build this.
---
configure.ac | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5594548..84b404e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -714,15 +71
From: Marek Olšák
v2: use less memory for the information
---
src/gallium/auxiliary/tgsi/tgsi_scan.c | 24 +---
src/gallium/auxiliary/tgsi/tgsi_scan.h | 4
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_scan.c
b/src/gall
On 05/26/2015 01:57 PM, Marek Olšák wrote:
From: Marek Olšák
No particular reason other than most people should always build this.
Is there really a reason for most people to build gles1 support? IIRC
SurfaceFlinger uses it but haven't seen much other users. Maybe it
should be enabled by d
https://bugs.freedesktop.org/show_bug.cgi?id=90600
José Fonseca changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |jfons...@vmware.com
|or
It's mainly for distributions. You can turn it off, but it won't make
the build faster, because all code is shared.
Marek
On Tue, May 26, 2015 at 1:26 PM, Tapani Pälli wrote:
>
> On 05/26/2015 01:57 PM, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> No particular reason other than most people
Without this patch, the following constructs (not an extensive list)
would crash mesa:
- mat2 foo = mat2(1); vec4 bar = vec4(foo);
- mat3 foo = mat3(1); vec4 bar = vec4(foo);
- mat3 foo = mat3(1); ivec4 bar = ivec4(foo);
The first case is explicitely allowed by the GLSL spec, as seen on
page 101
This change introduces a new field in gl_uniform_storage to
explicitely say that a uniform is built-in. In the case where it is,
no storage is defined to make it clear that it is read-only from the
mesa side. I think I fixed all the places in the code that made use of
the structure that I changed.
On 05/26/2015 04:15 AM, Jose Fonseca wrote:
argparse type is a nice type saver for simple data types, but it doesn't
look a good fit for the input XML file:
- Certain implementations of argparse (particularly python 2.7.3's)
invoke the type constructor for the default argument even when an
On 05/25/2015 01:59 PM, Thomas Helland wrote:
2015-05-25 18:20 GMT+02:00 Brian Paul :
This hasn't been updated in a long time and from recent discussion on
the mailing list, it's not always clear what's expected. Hopefully,
this will help a bit.
---
docs/devinfo.html | 155 +++
From: Marek Olšák
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 57b80a32..f8f198c 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src
From: Marek Olšák
---
src/gallium/drivers/radeon/radeon_llvm.h| 5 ++---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 15 +++
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm.h
b/src/gallium/drivers/radeon/r
From: Marek Olšák
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 719d081..792771e 100644
--- a/src/mesa/state_tra
From: Marek Olšák
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 792771e..57b80a32 100644
--- a/src/mesa/state_trac
I'm dropping this patch. I've also sent a new version of patch 2 as
well as new patches that dynamically allocate some of the arrays.
The complete patch series with all feedback comments resolved is also here:
http://cgit.freedesktop.org/~mareko/mesa/log/?h=tgsi-arrays
(starting from "glsl_to_tgsi
https://bugs.freedesktop.org/show_bug.cgi?id=90600
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
thanks
On Mon, May 25, 2015 at 5:38 PM, Marek Olšák wrote:
> Hi Rob,
>
> I've sent a patch that adds the CAP.
>
> Marek
>
> On Mon, May 25, 2015 at 3:17 PM, Rob Clark wrote:
>> Ignoring the compiler for a moment, I think this would probably break
>> my varying linking (where I match up VS out an
In case the glproto.h file isn't up to date, we provide the #define
for X_GLXCreateContextAttribsARB.
v2: fix other occurances, improve #ifndef test, per Jose.
---
src/gallium/state_trackers/glx/xlib/glx_api.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
di
On 26/05/15 16:00, Brian Paul wrote:
In case the glproto.h file isn't up to date, we provide the #define
for X_GLXCreateContextAttribsARB.
v2: fix other occurances, improve #ifndef test, per Jose.
---
src/gallium/state_trackers/glx/xlib/glx_api.c | 27 +--
1 file chang
Forgot to send to list.
>
> 26. mai 2015 15.35 skrev "Brian Paul" :
> >
> > On 05/25/2015 01:59 PM, Thomas Helland wrote:
> >>
> >> 2015-05-25 18:20 GMT+02:00 Brian Paul :
> >>>
> >>> This hasn't been updated in a long time and from recent discussion on
> >>> the mailing list, it's not always clea
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, May 26, 2015 at 3:57 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> No particular reason other than most people should always build this.
> ---
No preference from me, but the patch does what it claims:
Reviewed-by: Matt Turner
___
mesa-dev ma
On Tue, May 26, 2015 at 6:35 AM, Brian Paul wrote:
> On 05/25/2015 01:59 PM, Thomas Helland wrote:
>> I'm no expert on how to add extensions, but patch 2 and 3,
>> and the html of patch one LGTM. (Apart from what Ilia pointed out)
>
>
> Is that a R-b?
I think this might be another good thing to d
From: Marek Olšák
Reported by Ilia Mirkin.
---
src/gallium/drivers/r600/r600_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 87b6e6e..2e83143 100644
--- a/src/gallium/drivers/r600/
On Tue, May 26, 2015 at 3:28 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Based on the corresponding SI support. Same as that, this is currently
> only enabled for one-dimensional buffer copies due to issues with
> multi-dimensional SDMA copies.
>
> Signed-off-by: Michel Dänzer
For the se
From: Marek Olšák
Reported by Ilia Mirkin.
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 1cea091..0eaf1df 100644
--- a/src/gallium/auxili
From: Marek Olšák
Cc: 10.6 10.5
---
src/gallium/state_trackers/dri/dri_context.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri_context.c
b/src/gallium/state_trackers/dri/dri_context.c
index 9f11b15..3d8af65 100644
--- a/src/gall
On 05/21/2015 02:04 PM, Fredrik Höglund wrote:
> On Tuesday 19 May 2015, Ian Romanick wrote:
>> From: Ian Romanick
>>
>> Currently on the functions that are exclusive to core-profile are
>> implemented. The remainder continue to live in the XML. Additional
>> functions can be moved later.
>>
>>
---
docs/devinfo.html | 25 +
1 file changed, 25 insertions(+)
diff --git a/docs/devinfo.html b/docs/devinfo.html
index f5113b0..eb3aba1 100644
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
@@ -266,6 +266,31 @@ re-sending the whole series). Using --in-reply-to makes
it
On 05/26/2015 05:08 AM, Marek Olšák wrote:
> It's mainly for distributions. You can turn it off, but it won't make
> the build faster, because all code is shared.
If this could be used as a step towards eventually eliminating some
configure options altogether, I'm definitely in favor
> Marek
On 05/26/2015 11:33 AM, Marek Olšák wrote:
From: Marek Olšák
Cc: 10.6 10.5
---
src/gallium/state_trackers/dri/dri_context.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri_context.c
b/src/gallium/state_trackers/dri/dri_context
On Tue, May 26, 2015 at 10:41 AM, Brian Paul wrote:
> ---
Thanks Brian!
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, May 26, 2015 at 11:15:36AM +0100, Jose Fonseca wrote:
> argparse type is a nice type saver for simple data types, but it doesn't
> look a good fit for the input XML file:
>
> - Certain implementations of argparse (particularly python 2.7.3's)
> invoke the type constructor for the default
On Tue, May 26, 2015 at 2:06 PM, Dylan Baker wrote:
> On Tue, May 26, 2015 at 11:15:36AM +0100, Jose Fonseca wrote:
>> argparse type is a nice type saver for simple data types, but it doesn't
>> look a good fit for the input XML file:
>>
>> - Certain implementations of argparse (particularly pytho
On 05/21/2015 06:19 PM, Brian Paul wrote:
> Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
> _glapi_set_nop_handler() functions in the glapi dispatcher (which
> live in libGL.so). The calls to those functions from context.c
> would be undefined (i.e. an ABI break) if the libGL used
On Tue, May 26, 2015 at 02:05:41PM -0400, Ilia Mirkin wrote:
> On Tue, May 26, 2015 at 2:06 PM, Dylan Baker wrote:
> > On Tue, May 26, 2015 at 11:15:36AM +0100, Jose Fonseca wrote:
> >> argparse type is a nice type saver for simple data types, but it doesn't
> >> look a good fit for the input XML
Found when double-checking my review on Brian's series.
Signed-off-by: Thomas Helland
---
docs/devinfo.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/devinfo.html b/docs/devinfo.html
index f5113b0..3f810e9 100644
--- a/docs/devinfo.html
+++ b/docs/devinfo.html
On Tue, May 26, 2015 at 2:14 PM, Dylan Baker wrote:
> On Tue, May 26, 2015 at 02:05:41PM -0400, Ilia Mirkin wrote:
>> On Tue, May 26, 2015 at 2:06 PM, Dylan Baker wrote:
>> > On Tue, May 26, 2015 at 11:15:36AM +0100, Jose Fonseca wrote:
>> >> argparse type is a nice type saver for simple data typ
On 05/26/2015 12:07 PM, Ian Romanick wrote:
On 05/21/2015 06:19 PM, Brian Paul wrote:
Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
_glapi_set_nop_handler() functions in the glapi dispatcher (which
live in libGL.so). The calls to those functions from context.c
would be undefine
On 05/26/2015 12:14 PM, Thomas Helland wrote:
Found when double-checking my review on Brian's series.
Signed-off-by: Thomas Helland
---
docs/devinfo.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/devinfo.html b/docs/devinfo.html
index f5113b0..3f810e9 10064
On 05/26/2015 11:17 AM, Brian Paul wrote:
> On 05/26/2015 12:07 PM, Ian Romanick wrote:
>> On 05/21/2015 06:19 PM, Brian Paul wrote:
>>> Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
>>> _glapi_set_nop_handler() functions in the glapi dispatcher (which
>>> live in libGL.so). The c
On Tue, May 26, 2015 at 02:15:37PM -0400, Ilia Mirkin wrote:
> On Tue, May 26, 2015 at 2:14 PM, Dylan Baker wrote:
> > On Tue, May 26, 2015 at 02:05:41PM -0400, Ilia Mirkin wrote:
> >> On Tue, May 26, 2015 at 2:06 PM, Dylan Baker
> >> wrote:
> >> > On Tue, May 26, 2015 at 11:15:36AM +0100, Jose
On 05/26/2015 12:21 PM, Ian Romanick wrote:
On 05/26/2015 11:17 AM, Brian Paul wrote:
On 05/26/2015 12:07 PM, Ian Romanick wrote:
On 05/21/2015 06:19 PM, Brian Paul wrote:
Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
_glapi_set_nop_handler() functions in the glapi dispatcher
From: Brian Paul
Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
_glapi_set_nop_handler() functions in the glapi dispatcher (which
live in libGL.so). The calls to those functions from context.c
would be undefined (i.e. an ABI break) if the libGL used at runtime
was older.
For the
On 05/26/2015 12:38 PM, Ian Romanick wrote:
From: Brian Paul
Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
_glapi_set_nop_handler() functions in the glapi dispatcher (which
live in libGL.so). The calls to those functions from context.c
would be undefined (i.e. an ABI break) if
On 05/26/2015 11:36 AM, Brian Paul wrote:
> On 05/26/2015 12:21 PM, Ian Romanick wrote:
>> On 05/26/2015 11:17 AM, Brian Paul wrote:
>>> On 05/26/2015 12:07 PM, Ian Romanick wrote:
On 05/21/2015 06:19 PM, Brian Paul wrote:
> Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
>>
On 22/05/15 01:15, Brian Paul wrote:
> On 05/15/2015 02:28 PM, Emil Velikov wrote:
>> On 15/05/15 17:58, Brian Paul wrote:
>>> On 05/15/2015 11:14 AM, Emil Velikov wrote:
On 15/05/15 15:13, Brian Paul wrote:
> Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
> _glapi_set_
On 26/05/15 19:06, Dylan Baker wrote:
On Tue, May 26, 2015 at 11:15:36AM +0100, Jose Fonseca wrote:
argparse type is a nice type saver for simple data types, but it doesn't
look a good fit for the input XML file:
- Certain implementations of argparse (particularly python 2.7.3's)
invoke the
On 21/05/15 14:31, Boyan Ding wrote:
> On 05/16/2015 01:55 AM, Emil Velikov wrote:
>> On 09/04/15 16:05, Emil Velikov wrote:
>>> Hi Boyan,
>>>
>>> On 9 April 2015 at 16:08, Boyan Ding wrote:
For the same reason as the i965 one, as suggested by Chih-Wei Huang.
Cc: "10.4 10.5"
S
On 26/05/15 19:48, Jose Fonseca wrote:
On 26/05/15 19:06, Dylan Baker wrote:
On Tue, May 26, 2015 at 11:15:36AM +0100, Jose Fonseca wrote:
argparse type is a nice type saver for simple data types, but it doesn't
look a good fit for the input XML file:
- Certain implementations of argparse (par
On 23/05/15 12:09, Marek Olšák wrote:
> From: Marek Olšák
>
> v2: don't remove local Mesa changes
I'd say that it's nice to resolve the outstanding diff, to ensure
compatibility/portability of the EGL headers.
Obviously that can be done as a follow up commit(s) of those interested.
For the 3 pat
On 23/05/15 12:31, Marek Olšák wrote:
> Ping.
>
> Nobody has given me Reviewed-by for this series yet.
>
So I went over the spec a couple of times, and the series looks great.
Would be nice to hear from someone with more experience in the area but FWIW
Patches 1-3, 6-15 (with the ENOMEM check in
On 25/05/15 14:41, Brian Paul wrote:
> If the glPushAttrib() mask value was zero we didn't actually push
> anything onto the attribute stack. A subsequent glPopAttrib() call
> would generate a GL_STACK_UNDERFLOW error. Now push a dummy attribute
> in that case to prevent the error.
>
> Mesa now
On 05/26/2015 02:05 PM, Emil Velikov wrote:
On 25/05/15 14:41, Brian Paul wrote:
If the glPushAttrib() mask value was zero we didn't actually push
anything onto the attribute stack. A subsequent glPopAttrib() call
would generate a GL_STACK_UNDERFLOW error. Now push a dummy attribute
in that ca
On 26/05/15 14:04, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 +
> 1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
> b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
>
On 26/05/15 14:04, Marek Olšák wrote:
> From: Marek Olšák
>
> ---
> src/gallium/drivers/radeon/radeon_llvm.h| 5 ++---
> src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 15 +++
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/src/gallium/driver
On 26/05/15 10:57, Marek Olšák wrote:
> From: Marek Olšák
>
> No particular reason other than most people should always build this.
Yes please. Personally I've not seen any noticable increase in the build
time, plus anyone is welcome to disable it as they please.
If you need to go for the defaul
On 26.05.2015 09:28, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Based on the corresponding SI support. Same as that, this is currently
> only enabled for one-dimensional buffer copies due to issues with
> multi-dimensional SDMA copies.
>
What a pity, so CIK has exactly the same issues as SI?
On 26/05/15 10:57, Marek Olšák wrote:
> From: Marek Olšák
>
> This is required by radeonsi.
>
> The code was moved because with_egl_platforms was used before
> the default was set.
> ---
> configure.ac | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --g
The first two patches are just re-re-sends of the same patches.
Based on feedback from Emil and others, I changed the later patches to
use a new environment variable, MESA_GLES_VERSION_OVERRIDE, to override
GLES versions. I considered naming this MESA_GLES2_VERSION_OVERRIDE so
that we could later
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/mesa/drivers/dri/common/dri_util.c | 4
src/mesa/main/context.c| 4 +---
src/mesa/state_tracker/st_manager.c| 3 +--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_uti
From: Ian Romanick
This is a bit of a hack for now. Several of the extensions required for
OpenGL ES 3.1 have no support, at all, in Mesa. However, with this
patch and a patch to allow MESA_GL_VERSION_OVERRIDE to work with ES
contexts, people can begin testing the ES "version" of the functional
From: Ian Romanick
A couple functions are missing because there are no implementations of
them yet. These are:
glFramebufferParameteri (from GL_ARB_framebuffer_no_attachments)
glGetFramebufferParameteriv (from GL_ARB_framebuffer_no_attachments)
glMemoryBarrierByRegion
v2: Reb
From: Ian Romanick
Remove _mesa_get_gl_version_override. We don't need two functions that
do basically the same thing. This change seemed easier (esp. with the
next patch) than going the other way.
Signed-off-by: Ian Romanick
---
src/mesa/drivers/dri/common/dri_util.c | 18 +++---
From: Ian Romanick
The string is only applied when the context is API_OPENGLES2.
The bulk of the change is to prevent overriding the context to
API_OPENGL_CORE based on the requested version. If the context is
API_OPENGL_ES2, don't change it.
Signed-off-by: Ian Romanick
---
src/mesa/main/ver
On 26/05/15 19:11, Brian Paul wrote:
> On 05/26/2015 02:05 PM, Emil Velikov wrote:
>> On 25/05/15 14:41, Brian Paul wrote:
>>> If the glPushAttrib() mask value was zero we didn't actually push
>>> anything onto the attribute stack. A subsequent glPopAttrib() call
>>> would generate a GL_STACK_UNDE
I suggest we implement a thorough SDMA test first before trying to fix
it. We definitely want to test all implemented tiling modes,
dimensions, subrectangles of those (for the copies), bit depths,
number of samples, etc. and some of those parameters can differ
between src and dst. The list of teste
On Tue, May 26, 2015 at 3:29 PM, Grigori Goronzy wrote:
> On 26.05.2015 09:28, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Based on the corresponding SI support. Same as that, this is currently
>> only enabled for one-dimensional buffer copies due to issues with
>> multi-dimensional SDMA co
On 25/05/15 15:41, Brian Paul wrote:
If the glPushAttrib() mask value was zero we didn't actually push
anything onto the attribute stack. A subsequent glPopAttrib() call
would generate a GL_STACK_UNDERFLOW error. Now push a dummy attribute
in that case to prevent the error.
Mesa now matches nv
On 05/26/2015 02:53 AM, Tapani Pälli wrote:
> Hello;
>
> I'd like to ping if this approach would be ok. We've had some
> discussions with Curro about it and overall it would seem nicer to move
> this check to happen at compile time. However, this seems quite a
> problematic move. I'll try explain
26. mai 2015 20.19 skrev "Brian Paul" :
>
> On 05/26/2015 12:14 PM, Thomas Helland wrote:
>>
>> Found when double-checking my review on Brian's series.
>>
>> Signed-off-by: Thomas Helland
>> ---
>> docs/devinfo.html | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a
Ian Romanick writes:
> On 05/26/2015 02:53 AM, Tapani Pälli wrote:
>> Hello;
>>
>> I'd like to ping if this approach would be ok. We've had some
>> discussions with Curro about it and overall it would seem nicer to move
>> this check to happen at compile time. However, this seems quite a
>> prob
On 05/26/2015 02:03 PM, Jose Fonseca wrote:
On 25/05/15 15:41, Brian Paul wrote:
If the glPushAttrib() mask value was zero we didn't actually push
anything onto the attribute stack. A subsequent glPopAttrib() call
would generate a GL_STACK_UNDERFLOW error. Now push a dummy attribute
in that ca
No, it doesn't work. If I just add "drm" to the defaults and not use
--with-egl-platforms in the terminal, it fails with the message that
radeonsi requires drm. :)
Marek
On Tue, May 26, 2015 at 10:30 PM, Emil Velikov wrote:
> On 26/05/15 10:57, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> This
On 05/26/2015 02:04 PM, Francisco Jerez wrote:
> Ian Romanick writes:
>
>> On 05/26/2015 02:53 AM, Tapani Pälli wrote:
>>> Hello;
>>>
>>> I'd like to ping if this approach would be ok. We've had some
>>> discussions with Curro about it and overall it would seem nicer to move
>>> this check to hap
From: Marek Olšák
This is a fix for the EGL 1.5 patch series.
---
src/egl/main/eglapi.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c
index 7afc091..3df4968 100644
--- a/src/egl/main/eglapi.c
+++ b/src
From: Marek Olšák
---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index 4983667..c8c980d 100644
--- a/src/gallium/drivers/radeon/
From: Marek Olšák
v2: - don't use realloc (tgsi_shader_info provides the size)
---
src/gallium/drivers/radeon/radeon_llvm.h| 4 +---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 15 +++
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/src/gallium/
On Tue, May 26, 2015 at 10:19 PM, Emil Velikov wrote:
> On 26/05/15 14:04, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/gallium/drivers/radeon/radeon_llvm.h| 5 ++---
>> src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 15 +++
>> 2 files changed, 13 inse
On Wed, 2015-05-27 at 00:36 +0200, Marek Olšák wrote:
> On Tue, May 26, 2015 at 10:19 PM, Emil Velikov
> wrote:
> > On 26/05/15 14:04, Marek Olšák wrote:
> >> From: Marek Olšák
> >>
> >> ---
> >> src/gallium/drivers/radeon/radeon_llvm.h| 5 ++---
> >> src/gallium/drivers/radeon/rad
On Tue, May 26, 2015 at 10:15 PM, Emil Velikov wrote:
> On 26/05/15 14:04, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 17 +
>> 1 file changed, 9 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/mesa/state_tracker/st_glsl_
On Wed, May 27, 2015 at 12:39 AM, Jan Vesely wrote:
> On Wed, 2015-05-27 at 00:36 +0200, Marek Olšák wrote:
>> On Tue, May 26, 2015 at 10:19 PM, Emil Velikov
>> wrote:
>> > On 26/05/15 14:04, Marek Olšák wrote:
>> >> From: Marek Olšák
>> >>
>> >> ---
>> >> src/gallium/drivers/radeon/radeon_llv
Ian Romanick writes:
> On 05/26/2015 02:04 PM, Francisco Jerez wrote:
>> Ian Romanick writes:
>>
>>> On 05/26/2015 02:53 AM, Tapani Pälli wrote:
Hello;
I'd like to ping if this approach would be ok. We've had some
discussions with Curro about it and overall it would seem nic
https://bugs.freedesktop.org/show_bug.cgi?id=90669
Bug ID: 90669
Summary: make check DispatchSanity_test.GLES3 regression
Product: Mesa
Version: 10.6
Hardware: All
OS: Linux (All)
Status: NEW
Keywords: bis
https://bugs.freedesktop.org/show_bug.cgi?id=90669
Vinson Lee changed:
What|Removed |Added
Version|10.6|git
--
You are receiving this mail because
This patch fixes `make check` for me, but v2 has been pushed, so...
Who gets to make a patch to fix master?
Tested-by: Mark Janes
Ian Romanick writes:
> From: Brian Paul
>
> Commit 4bdbb588a9d38 introduced new _glapi_new_nop_table() and
> _glapi_set_nop_handler() functions in the glapi dispat
From: Ian Romanick
Encapsulate the knowledge about how to build the nop table in a new
_mesa_new_nop_table function. This makes it easier for dispatch_sanity
to keep working now and in the future.
Signed-off-by: Ian Romanick
Cc: Brian Paul
Cc: Emil Velikov
Cc: 10.6
---
I sent this just a fe
On 26/05/15 23:56, Ian Romanick wrote:
> From: Ian Romanick
>
> Encapsulate the knowledge about how to build the nop table in a new
> _mesa_new_nop_table function. This makes it easier for dispatch_sanity
> to keep working now and in the future.
>
> Signed-off-by: Ian Romanick
> Cc: Brian Paul
On 26/05/15 21:59, Marek Olšák wrote:
> From: Marek Olšák
>
> This is a fix for the EGL 1.5 patch series.
Can you squash this with the offending patches (12 and 13). Pretty
please :-)
> ---
> src/egl/main/eglapi.c | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-
On Wed, May 27, 2015 at 3:07 AM, Emil Velikov wrote:
> On 26/05/15 21:59, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> This is a fix for the EGL 1.5 patch series.
> Can you squash this with the offending patches (12 and 13). Pretty
> please :-)
>
>> ---
>> src/egl/main/eglapi.c | 25 +++
1 - 100 of 114 matches
Mail list logo