https://bugs.freedesktop.org/show_bug.cgi?id=90162
--- Comment #8 from Tapani Pälli lem...@gmail.com ---
(In reply to Martina Kollarova from comment #7)
glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER,
GL_DEPTH_ATTACHMENT,
GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, type);
https://bugs.freedesktop.org/show_bug.cgi?id=90397
--- Comment #4 from Samuel Iglesias sigles...@igalia.com ---
Created attachment 115737
-- https://bugs.freedesktop.org/attachment.cgi?id=115737action=edit
patch to GetProgramResourceIndex() to fix arrays of UBOs behavior
I found another issue
Hi Tom,
pipe_screen doesn't need any locking. It should already be thread-safe
(if it's not, it's a driver bug). It's implied by the fact that
pipe_screen is shared by all OpenGL contexts. I'm sure the radeon
pipe_screen is thread-safe.
Marek
On Tue, May 12, 2015 at 8:07 PM, Tom Stellard
Reviewed-by: Marek Olšák marek.ol...@amd.com
Marek
On Wed, May 13, 2015 at 4:36 AM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
This was missing, and drivers relying on the target in the view could get
into quite some trouble.
---
On Tue, 2015-05-12 at 23:09 -0700, Ian Romanick wrote:
On 05/12/2015 03:12 PM, Timothy Arceri wrote:
On Sat, 2015-04-18 at 12:26 +0200, Marek Olšák wrote:
On Fri, Apr 17, 2015 at 1:21 PM, Timothy Arceri t_arc...@yahoo.com.au
wrote:
Hi all,
Last year I spent a whole bunch of time
On 2014-12-11 16:14, Jose Fonseca wrote:
From: José Fonseca jfons...@vmware.com
This is just to help repro and fixing these issues with any C++
compiler --
commiting this will of course wait until all issues are addressed.
$ scons src/glsl/
scons: Reading SConscript files ...
Checking for
On 05/12/2015 08:36 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
All the functionality was pretty much there, just not tested.
Trivially fix up the missing pieces (take target info from view not
resource), and add some missing bits for cubes.
Also add some minimal
* The Haiku glapi has a C++ wrapper around
the dispatch code.
---
src/mapi/glapi/glapi_priv.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/mapi/glapi/glapi_priv.h b/src/mapi/glapi/glapi_priv.h
index 50f710e..337913a 100644
--- a/src/mapi/glapi/glapi_priv.h
On 05/06/2015 03:19 AM, Tapani Pälli wrote:
I've just noticed that this is wrong, sorry :/ We should to make a new
section for some of the enums that are only in GL core and ES31,
DRAW_INDIRECT_BUFFER_BINDING is one of these cases .. so this patch is
broken. Same may apply for some of your
On Wed, May 13, 2015 at 12:07 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
On Tue, May 5, 2015 at 2:48 PM, Francisco Jerez curroje...@riseup.net wrote:
Define a few transformations on register arrays which will be used
frequently during the construction of typed and untyped surface
message
From: Ian Romanick ian.d.roman...@intel.com
Without this the next patch will try to put these functions in the
dispatch table in indirect_init.c.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/gl_API.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Ian Romanick ian.d.roman...@intel.com
Comparing the output of
nm -D arch/x86_64/usr/X11R6/lib64/fglrx/fglrx-libGL.so.1.2 |\
grep ' T gl[^X]' | sed 's/.* T //'
between Catalyst 14.6 Beta and this commit, the only change is a bunch
of functions that AMD exports that Mesa does
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/static_data.py | 56 +++
1 file changed, 56 insertions(+)
diff --git a/src/mapi/glapi/gen/static_data.py
From: Ian Romanick ian.d.roman...@intel.com
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
From: Ian Romanick ian.d.roman...@intel.com
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)
From: Ian Romanick ian.d.roman...@intel.com
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 ian.d.roman...@intel.com
---
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/ARB_base_instance.xml | 9 +-
.../glapi/gen/ARB_draw_elements_base_vertex.xml| 9 +-
src/mapi/glapi/gen/ARB_framebuffer_object.xml | 18 +-
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/gl_API.dtd | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mapi/glapi/gen/gl_API.dtd b/src/mapi/glapi/gen/gl_API.dtd
index 298ba3c..bdc62f1 100644
---
From: Ian Romanick ian.d.roman...@intel.com
Changes generated by:
cd src/mapi/glapi/gen
for i in *.xml; do
cat $i |\
sed 's/[[:space:]]*offset=[^]*//' |\
sed 's/[[:space:]]*offset=[^]*[[:space:]]*$//' |\
sed 's/[[:space:]]*offset=[^]*[[:space:]]*/ /' x
From: Ian Romanick ian.d.roman...@intel.com
Comparing the output of
nm -D libGL.so.349.16 | grep ' T gl[^X]' | sed 's/.* T //'
between Catalyst NVIDIA 349.16 and this commit, the only change is a bunch
of functions that NVIDIA exports that Mesa does not.
If a function is not statically
On Tue, May 5, 2015 at 2:48 PM, Francisco Jerez curroje...@riseup.net wrote:
Define a few transformations on register arrays which will be used
frequently during the construction of typed and untyped surface
message payloads. Their purpose is simple but the implementation is
rather messy, so
I haven't said much about this series up until now. I've mostly sat
and watched and focused my time on other things. As I said in the
meeting today, I think that part of the problem here is that there are
at least 3 refactors in here besides the new feature. By
refactors, I mean new ways of
On 13/05/15 16:43, Matt Turner wrote:
On Wed, May 13, 2015 at 10:37 AM, Emil Velikov emil.l.veli...@gmail.com
wrote:
As we evaluate sizeof() at compile time, having the run-time assert()
does not provide any benefits. Move to the compile-time version
STATIC_ASSERT() which will kindly prompt
On 05/13/2015 12:25 PM, Alexander von Gluck IV wrote:
* The Haiku glapi has a C++ wrapper around
the dispatch code.
I think you can drop the * and put the comment on one line.
Otherwise, for both,
Reviewed-by: Brian Paul bri...@vmware.com
---
src/mapi/glapi/glapi_priv.h |8
From: Ian Romanick ian.d.roman...@intel.com
Mesa does not (and probably never will) support GL_ARB_geometry_shader4,
so this function will never exist. Having a function that is
exec=skip and offset=assign is just weird.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
From: Ian Romanick ian.d.roman...@intel.com
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
between 10.5.5 and this commit, the only change is the removal of
glFramebufferTextureFaceARB. This function was removed a couple commits
previously.
None of these
We've known for a long time that having all those tags in the function
entries in the XML is bad. For example, people cut-and-paste for
everything, and, as a result, we export a bunch of functions that we
should not. We also really want to just use the Khronos XML.
This series takes a couple
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/APPLE_vertex_array_object.xml | 6 +-
src/mapi/glapi/gen/ARB_internalformat_query.xml | 3 +-
src/mapi/glapi/gen/OES_fixed_point.xml | 114 ++--
From: Ian Romanick ian.d.roman...@intel.com
Since the set of functions with static will never change, there is no
reason to store it in the XML. It's just one of those fields that
confuses people adding new functions.
This is split out from the rest of the series so that in-code assertions
can
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Dylan Baker baker.dyla...@gmail.com
---
src/mapi/glapi/gen/gl_XML.py | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_XML.py
From: Ian Romanick ian.d.roman...@intel.com
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mapi/glapi/gen/gl_API.dtd | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mapi/glapi/gen/gl_API.dtd b/src/mapi/glapi/gen/gl_API.dtd
index ab321fa..298ba3c 100644
---
On 05/13/2015 01:18 PM, Francisco Jerez wrote:
Emil Velikov emil.l.veli...@gmail.com writes:
As we evaluate sizeof() at compile time, having the run-time assert()
does not provide any benefits. Move to the compile-time version
STATIC_ASSERT() which will kindly prompt us when this go wrong.
On 05/13/2015 12:44 PM, Ian Romanick wrote:
We've known for a long time that having all those tags in the function
entries in the XML is bad. For example, people cut-and-paste for
everything, and, as a result, we export a bunch of functions that we
should not. We also really want to just use
https://bugs.freedesktop.org/show_bug.cgi?id=90438
--- Comment #2 from Bryan Quigley gquigs+b...@gmail.com ---
Created attachment 115750
-- https://bugs.freedesktop.org/attachment.cgi?id=115750action=edit
adds quiet option
Adds -q quiet option to glxinfo. Just changes what is printed,
not
On 13 May 2015 at 21:01, Brian Paul bri...@vmware.com wrote:
On 05/13/2015 01:18 PM, Francisco Jerez wrote:
Emil Velikov emil.l.veli...@gmail.com writes:
As we evaluate sizeof() at compile time, having the run-time assert()
does not provide any benefits. Move to the compile-time version
On 05/13/2015 04:14 PM, Emil Velikov wrote:
On 13 May 2015 at 17:46, Chad Versace chad.vers...@intel.com wrote:
On Fri 08 May 2015, Emil Velikov wrote:
Hi all,
Just had a quick look at Debian's repo and noticed something rather
worrying - the ABI of our libEGL is not stable.
Stable in the
On 13 May 2015 at 17:46, Chad Versace chad.vers...@intel.com wrote:
On Fri 08 May 2015, Emil Velikov wrote:
Hi all,
Just had a quick look at Debian's repo and noticed something rather
worrying - the ABI of our libEGL is not stable.
Stable in the sense of - we provide a growing list of static
On May 13, 2015 8:01 AM, kallisti5 kallis...@unixzen.com wrote:
On 2014-12-11 16:14, Jose Fonseca wrote:
From: José Fonseca jfons...@vmware.com
This is just to help repro and fixing these issues with any C++ compiler
--
commiting this will of course wait until all issues are addressed.
On Mon 11 May 2015, Emil Velikov wrote:
On 11 May 2015 at 20:07, Emil Velikov emil.l.veli...@gmail.com wrote:
On 11 May 2015 at 14:23, Marc-André Lureau marcandre.lur...@gmail.com
wrote:
s/EGL_MESA_dma_buf_image_export/EGL_MESA_image_dma_buf_export as defined
by the spec
---
Matt Turner matts...@gmail.com writes:
On Tue, May 5, 2015 at 2:17 PM, Francisco Jerez curroje...@riseup.net wrote:
Kenneth Graunke kenn...@whitecape.org writes:
I like the idea of the builder refactor - having a mechanism for emitting
code at arbitrary points makes a ton of sense. But I'm
Define some utility functions to query the bitfield layout of a given
image format and whether it satisfies a number of more or less
hardware-specific properties.
v2: Drop VEC4 suport.
v3: Add SKL support.
---
src/mesa/drivers/dri/i965/brw_fs_surface_builder.h | 148 +
1 file
On Wednesday, May 13, 2015 07:33:22 PM Francisco Jerez wrote:
- Nothing prevents you from evaluating the builder framework
independent from the tiling and format conversion code.
[snip]
I think you misunderstand - we all largely agree that the fs_builder
infrastructure is a good idea. I
On Mon, 2015-05-11 at 19:27 +0200, Fredrik Höglund wrote:
This is a respin of Laura's FBO patches. I've rebased them, fixed
the issues I found, and added my R-b tags. Note that there is a
total of 57 patches, so I'm only posting the ones that don't already
have R-b tags, and the ones that
As we evaluate sizeof() at compile time, having the run-time assert()
does not provide any benefits. Move to the compile-time version
STATIC_ASSERT() which will kindly prompt us when this go wrong.
Cc: Matt Turner matts...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
This works as-is on SKL, only the assertion needs to be relaxed.
---
src/mesa/drivers/dri/i965/brw_program.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index e5c0d3c..aea26e2 100644
---
---
src/mesa/drivers/dri/i965/brw_tex_layout.c | 4 +---
1 file changed, 1 insertion(+), 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 72b02a2..6c6dc5c 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++
https://bugs.freedesktop.org/show_bug.cgi?id=90438
--- Comment #1 from Brian Paul bri...@vmware.com ---
That would be useful. Personally, I use a shell script that wraps glxinfo and
greps for version\|vendor\|renderer.
If you want to take a crack at this feature, feel free to submit a patch.
On 2015-05-13 10:42, Jason Ekstrand wrote:
On May 13, 2015 8:01 AM, kallisti5 kallis...@unixzen.com wrote:
src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:28:
include/no_extern_c.h:47:1: error: template with C linkage
templateclass T class _IncludeInsideExternCNotPortable;
Any
---
src/hgl/GLDispatcher.cpp |5 +++--
src/hgl/GLDispatcher.h |4 +---
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/hgl/GLDispatcher.cpp b/src/hgl/GLDispatcher.cpp
index 46b91d5..a1e9053 100644
--- a/src/hgl/GLDispatcher.cpp
+++ b/src/hgl/GLDispatcher.cpp
@@ -1,6
Am 13.05.2015 um 16:32 schrieb Brian Paul:
On 05/12/2015 08:36 PM, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
All the functionality was pretty much there, just not tested.
Trivially fix up the missing pieces (take target info from view not
resource), and add some
https://bugs.freedesktop.org/show_bug.cgi?id=90162
--- Comment #5 from Tapani Pälli lem...@gmail.com ---
These errors are according to the spec and happen because of following reason.
8
OpenGL 4.0 Compatibility, page 449:
If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is
On 05/12/2015 03:12 PM, Timothy Arceri wrote:
On Sat, 2015-04-18 at 12:26 +0200, Marek Olšák wrote:
On Fri, Apr 17, 2015 at 1:21 PM, Timothy Arceri t_arc...@yahoo.com.au
wrote:
Hi all,
Last year I spent a whole bunch of time profiling Mesa looking for areas
where improvements could be
https://bugs.freedesktop.org/show_bug.cgi?id=86701
--- Comment #20 from Pekka Paalanen ppaala...@gmail.com ---
(In reply to nerdopolis1 from comment #18)
Hi. I realized that the hang happens when I hover over an icon on the
desktop shell, and it tries to show a tooltip
Output of weston
https://bugs.freedesktop.org/show_bug.cgi?id=62142
ye.tian yex.t...@intel.com changed:
What|Removed |Added
Status|VERIFIED|CLOSED
--
You are
On 13/05/15 07:28, Tapani Pälli wrote:
On 05/13/2015 08:02 AM, Samuel Iglesias Gonsálvez wrote:
Thanks Tapani!
Reviewed-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
Can you add a test to piglit to check this case?
I was hoping you had some test that hit this? :) I'll take a
On 12/05/15 23:17, Timothy Arceri wrote:
On Mon, 2015-05-11 at 12:37 +0200, Alejandro Piñeiro wrote:
Since commit c0cd5b var-data.binding was set only when explicit_binding
was false, thas was wrong, should be a test to true. This prevented
to use any binding point different to 0.
In any
https://bugs.freedesktop.org/show_bug.cgi?id=90162
--- Comment #6 from Tapani Pälli lem...@gmail.com ---
Having said that, I noticed that glGetFramebufferAttachmentParameteriv is
broken if you try to query type or name of non-existing attachment point (for
desktop GL). But that should be another
On 05/13/2015 10:35 AM, Samuel Iglesias Gonsálvez wrote:
On 13/05/15 07:28, Tapani Pälli wrote:
On 05/13/2015 08:02 AM, Samuel Iglesias Gonsálvez wrote:
Thanks Tapani!
Reviewed-by: Samuel Iglesias Gonsalvez sigles...@igalia.com
Can you add a test to piglit to check this case?
I was
https://bugs.freedesktop.org/show_bug.cgi?id=90162
--- Comment #7 from Martina Kollarova martina.kollar...@intel.com ---
glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT,
GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, type);
This query generated a GL_INVALID_ENUM for
Emil Velikov emil.l.veli...@gmail.com writes:
As we evaluate sizeof() at compile time, having the run-time assert()
does not provide any benefits. Move to the compile-time version
STATIC_ASSERT() which will kindly prompt us when this go wrong.
This doesn't look right. AFAIK STATIC_ASSERT()
60 matches
Mail list logo
