https://bugs.freedesktop.org/show_bug.cgi?id=90162
--- Comment #6 from Tapani Pälli ---
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 bug.
--
You are
https://bugs.freedesktop.org/show_bug.cgi?id=62142
ye.tian changed:
What|Removed |Added
Status|VERIFIED|CLOSED
--
You are receiving this mail because
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
>>
>> 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 look if
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
Can you add a test to piglit to check this case?
I was hoping you had some te
https://bugs.freedesktop.org/show_bug.cgi?id=90162
--- Comment #7 from Martina Kollarova ---
>glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT,
>GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, &type);
This query generated a GL_INVALID_ENUM for me.
--
You are receivi
Reviewed-by: Marek Olšák
Marek
On Wed, May 13, 2015 at 4:36 AM, wrote:
> From: Roland Scheidegger
>
> This was missing, and drivers relying on the target in the view could get
> into quite some trouble.
> ---
> src/gallium/auxiliary/util/u_blitter.c | 1 +
> 1 file changed, 1 insertion(+)
>
https://bugs.freedesktop.org/show_bug.cgi?id=90162
--- Comment #8 from Tapani Pälli ---
(In reply to Martina Kollarova from comment #7)
> >glGetFramebufferAttachmentParameteriv(GL_FRAMEBUFFER,
> > GL_DEPTH_ATTACHMENT,
> >GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE, &type);
>
> This query
https://bugs.freedesktop.org/show_bug.cgi?id=90162
--- Comment #9 from Tapani Pälli ---
Created attachment 115736
--> https://bugs.freedesktop.org/attachment.cgi?id=115736&action=edit
fix for invalid enum issue
This helps in getting GL_NONE as object type when there is no attachment in
given a
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 wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=90397
--- Comment #4 from Samuel Iglesias ---
Created attachment 115737
--> https://bugs.freedesktop.org/attachment.cgi?id=115737&action=edit
patch to GetProgramResourceIndex() to fix arrays of UBOs behavior
I found another issue when modifying
arb_
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
> >> wrote:
> >>> Hi all,
> >>>
> >>> Last year I spent a whole bunch of time profi
On 05/12/2015 08:36 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
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 debug validation to
On 05/12/2015 08:36 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
Some bits were already there for texture views but some were missing.
In particular for cube map views things needed to change a bit.
For simplicity I ended up removing the separate face addr bit (just use
the z bit) - c
https://bugs.freedesktop.org/show_bug.cgi?id=90438
Bug ID: 90438
Summary: glxinfo should have a quiet mode
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority
On 2014-12-11 16:14, Jose Fonseca wrote:
From: José Fonseca
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 GCC ... yes
Checkin
https://bugs.freedesktop.org/show_bug.cgi?id=90438
--- Comment #1 from Brian Paul ---
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.
--
You are recei
On May 13, 2015 8:01 AM, "kallisti5" wrote:
>
> On 2014-12-11 16:14, Jose Fonseca wrote:
>>
>> From: José Fonseca
>>
>> 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/
>
Matt Turner writes:
> On Tue, May 5, 2015 at 2:17 PM, Francisco Jerez wrote:
>> Kenneth Graunke 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 uncomfortable
>>> with how much code is added - and d
On Mon 11 May 2015, Emil Velikov wrote:
> On 11 May 2015 at 20:07, Emil Velikov wrote:
> > On 11 May 2015 at 14:23, Marc-André Lureau
> > wrote:
> >> s/EGL_MESA_dma_buf_image_export/EGL_MESA_image_dma_buf_export as defined
> >> by the spec
> >> ---
> >> src/egl/main/eglapi.c | 2 +-
> >>
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
--- a/sr
---
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
+++ b/src/me
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
Signed-off-by: Emil Velikov
---
src/util/u_atomic.h | 26 +---
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 Wed, May 13, 2015 at 10:37 AM, Emil Velikov 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 us when this go wrong.
>
> Cc: Matt Turner
> Signed-off-by: Em
v2: Add SKL support.
---
src/mesa/drivers/dri/i965/brw_context.h | 2 +
src/mesa/drivers/dri/i965/brw_surface_formats.c | 109 +++
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 77
3 files changed, 188 insertions(+)
diff --git a/src/mesa/driv
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 symbols
> for each new function an EGL extension adds.
>
> Thi
On 05/11/2015 03:37 AM, 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 case, that if statement is not needed. Right now m
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 th
On 2015-05-13 10:42, Jason Ekstrand wrote:
On May 13, 2015 8:01 AM, "kallisti5" wrote:
src/mesa/drivers/haiku/swrast/SoftwareRast.cpp:28:
> include/no_extern_c.h:47:1: error: template with C linkage
>
> template class _IncludeInsideExternCNotPortable;
>
> Any alternative fix ideas besides
Am 13.05.2015 um 16:32 schrieb Brian Paul:
> On 05/12/2015 08:36 PM, srol...@vmware.com wrote:
>> From: Roland Scheidegger
>>
>> 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 b
---
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 +1
* 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 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
---
src/mapi/glapi/glapi_priv.h |8
1 files chang
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
> 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 us when this go w
On Tue, May 5, 2015 at 2:48 PM, Francisco Jerez 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 it makes a lot of
Emil Velikov 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() is implemented by
exp
On Wed, May 13, 2015 at 12:07 PM, Jason Ekstrand wrote:
> On Tue, May 5, 2015 at 2:48 PM, Francisco Jerez 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 b
From: Ian Romanick
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
between 10.3.7 and this commit, the only change is the removal of
glFramebufferTextureFaceARB. This function was removed a couple commits
previously.
glClipControl was, at the time 10.3 shipped, a
From: Ian Romanick
Comparing the output of
nm libGL.so | grep ' T gl[^X]' | sed 's/.* T //'
between 10.4.7 and this commit, the only change is the removal of
glFramebufferTextureFaceARB. This function was removed a couple commits
previously.
None of these functions are particuarly new. I
From: Ian Romanick
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 exported by either of the ma
From: Ian Romanick
Signed-off-by: Ian Romanick
---
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
--- a/src/mapi/glapi/gen/gl_API.dtd
+++ b/src/mapi/glapi/gen/gl_API.dtd
From: Ian Romanick
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
mv x $i
From: Ian Romanick
Without this the next patch will try to put these functions in the
dispatch table in indirect_init.c.
Signed-off-by: Ian Romanick
---
src/mapi/glapi/gen/gl_API.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mapi/glapi/gen/gl_API.xml b/src/map
From: Ian Romanick
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 not and some OpenGL ES
1.1
From: Ian Romanick
The set of functions with static dispatch is (supposed to be) defined by
the Linux OpenGL ABI. We export quite a few more functions than that
for historical reasons. However, this list should never grow.
This table is used instead of the static_dispatch tag in the XML to
gen
From: Ian Romanick
Changes generated by:
cd src/mapi/glapi/gen
for i in *.xml; do
cat $i |\
sed 's/[[:space:]]*static_dispatch="[^"]*">/>/' |\
sed 's/[[:space:]]*static_dispatch="[^"]*"[[:space:]]*$//' |\
sed 's/[[:space:]]*static_dispatch="[^"]*"[[:space:
From: Ian Romanick
Signed-off-by: Ian Romanick
---
src/mapi/glapi/gen/static_data.py | 56 +++
1 file changed, 56 insertions(+)
diff --git a/src/mapi/glapi/gen/static_data.py
b/src/mapi/glapi/gen/static_data.py
index cf909fc..142c503 100644
--- a/src/mapi/g
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
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/drivers/dri/common/dri_util.c | 4
src/mesa/main/context.c
From: Ian Romanick
Signed-off-by: Ian Romanick
---
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 +-
.../glapi/gen/ARB_vertex_type_2_10_10_10_rev.xml | 90 ++--
From: Ian Romanick
Signed-off-by: Ian Romanick
---
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
--- a/src/mapi/glapi/gen/gl_API.dtd
+++ b/src/mapi/glapi/gen/gl_API.dtd
From: Ian Romanick
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
---
src/mapi/glapi/gen/ARB_geometry_shader4.xml | 2 +-
src/mapi
From: Ian Romanick
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 functions are particuarly new. I
We've known for a long time that having all those tags in the
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 small steps
From: Ian Romanick
Signed-off-by: Ian Romanick
---
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 ++--
src/mapi/glapi/gen/OES_single_precision.xml | 1
From: Ian Romanick
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 be used to verify that th
From: Ian Romanick
Signed-off-by: Ian Romanick
Cc: Dylan Baker
---
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 b/src/mapi/glapi/gen/gl_XML.py
index 89b09f2..67aba81 100644
--- a/src/mapi/g
On 05/13/2015 12:44 PM, Ian Romanick wrote:
> We've known for a long time that having all those tags in the
> 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
On 05/13/2015 01:18 PM, Francisco Jerez wrote:
Emil Velikov 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.
https://bugs.freedesktop.org/show_bug.cgi?id=90438
--- Comment #2 from Bryan Quigley ---
Created attachment 115750
--> https://bugs.freedesktop.org/attachment.cgi?id=115750&action=edit
adds quiet option
Adds -q quiet option to glxinfo. Just changes what is printed,
not what is collected.
Exa
On 13 May 2015 at 21:01, Brian Paul wrote:
> On 05/13/2015 01:18 PM, Francisco Jerez wrote:
>>
>> Emil Velikov 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 ki
On 13 May 2015 at 17:46, Chad Versace 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 symbols
>>
* Haiku's egl driver is C++ due to the interface natively being C++
---
src/egl/main/eglapi.h | 10 ++
src/egl/main/eglarray.h|8
src/egl/main/eglcompiler.h |8
src/egl/main/eglconfig.h |8
src/egl/main/eglcontext.h |8
src/
---
src/egl/drivers/haiku/egl_haiku.cpp |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/egl/drivers/haiku/egl_haiku.cpp
b/src/egl/drivers/haiku/egl_haiku.cpp
index 4cf2ccb..4d9888d 100644
--- a/src/egl/drivers/haiku/egl_haiku.cpp
+++ b/src/egl/drivers/haiku/egl_haiku
On 05/13/2015 04:14 PM, Emil Velikov wrote:
On 13 May 2015 at 17:46, Chad Versace 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 gr
69 matches
Mail list logo
