On Mon, 2014-03-31 at 08:10 -0600, Brian Paul wrote:
> On 03/31/2014 02:04 AM, Iago Toral Quiroga wrote:
> > Currently, we raise an error when doing this which breaks a conformance test
> > from the OpenGL samples pack. Even if this is a bit silly it is not an
> > error.
> >
> > From
> > https:/
https://bugs.freedesktop.org/show_bug.cgi?id=76856
--- Comment #5 from Matt Turner ---
(In reply to comment #4)
> Maybe check with OpenBSD to figure out why this doesn't work?
Oh, I missed the more recent comment.
--
You are receiving this mail because:
You are the assignee for the bug.
__
This is to avoid running out of query buffer space due to winsys
limitations.
v2: Correct email addresses.
Reported-and-tested-by: Brian Paul
Signed-off-by: Thomas Hellstrom
Cc: "10.1"
---
src/gallium/winsys/svga/drm/vmw_screen_pools.c | 14 +-
1 file changed, 9 insertions(+), 5
This is to avoid running out of query buffer space due to winsys
limitations.
Reported-and-tested-by: Brian Paul
Signed-off-by: Thomas Hellstrom
Cc: "10.1"
---
src/gallium/winsys/svga/drm/vmw_screen_pools.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/sr
https://bugs.freedesktop.org/show_bug.cgi?id=76856
--- Comment #4 from Matt Turner ---
Maybe check with OpenBSD to figure out why this doesn't work?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
me
https://bugs.freedesktop.org/show_bug.cgi?id=76856
--- Comment #3 from Jonathan Gray ---
So it seems DT_NEEDED entries are not added for libc and libpthread over
concerns that specific versions of those libraries would be referenced in a way
that would prevent changing the major version of those
https://bugs.freedesktop.org/show_bug.cgi?id=76856
--- Comment #2 from Jonathan Gray ---
As I said in the subject these are all symbols in libc. It seems
--Wl,--no-undefined has different behaviour on Linux.
Evolution for example does not enable this on FreeBSD/OpenBSD
https://mail.gnome.org/ar
https://bugs.freedesktop.org/show_bug.cgi?id=76848
--- Comment #6 from Emil Velikov ---
If the patch in commit 5 does not resolve the problem the following two will be
needed to resolve the "funny" situation.
[1] http://patchwork.freedesktop.org/patch/23307/
[2] http://patchwork.freedesktop.org/
On 01/04/14 03:12, Ilia Mirkin wrote:
> I presume you tested that nouveau_compiler still builds :)
>
Of course, but only build tested. Here is the full config I've used.
../autogen.sh \
--with-dri-drivers= --with-gallium-drivers="r300,r600,nouveau" \
--enable-glx-tls --enable-shared-glapi --e
I presume you tested that nouveau_compiler still builds :)
Reviewed-by: Ilia Mirkin
On Mon, Mar 31, 2014 at 10:11 PM, Emil Velikov wrote:
> The build system does not know that the static library is C++.
> Mention the cpp file to trigger generation of the proper variable
> and drop the hacky std
Reviewed-by: Ilia Mirkin
On Mon, Mar 31, 2014 at 10:11 PM, Emil Velikov wrote:
> Cc: Ilia Mirkin
> Signed-off-by: Emil Velikov
> ---
> src/gallium/drivers/nouveau/Makefile.am | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/nouveau/Makefile.am
>
Signed-off-by: Emil Velikov
---
src/gallium/Automake.inc | 2 ++
src/gallium/targets/dri-freedreno/Makefile.am | 2 --
src/gallium/targets/dri-i915/Makefile.am | 2 --
src/gallium/targets/dri-ilo/Makefile.am | 2 --
src/gallium/targets/dri-nouveau/Makefile.am | 2
Signed-off-by: Emil Velikov
---
src/gallium/drivers/r300/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r300/Makefile.am
b/src/gallium/drivers/r300/Makefile.am
index 8aa6707..a8aaf22 100644
--- a/src/gallium/drivers/r300/Makefile.am
+++ b/src/
The targets do not require expat or selinux. Use GALLIUM_COMMON_LIB_DEPS
which provides the core requirements for each gallium target.
Cc: Christian König
Signed-off-by: Emil Velikov
---
src/gallium/Automake.inc | 3 ++-
src/gallium/targets/r600/xvmc/Makefile.am| 1 -
sr
The build system will use g++ to link the static library due to the
dummy.cpp source(s). Thus one does not need the explicit link against
stdc++.
Cc: Christian König
Signed-off-by: Emil Velikov
---
src/gallium/targets/r600/omx/Makefile.am | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Rather than copying the core four dependencies all over gallium,
introduce the above variable to avoid all the duplication.
Signed-off-by: Emil Velikov
---
src/gallium/Automake.inc| 16
src/gallium/targets/egl-static/Makefile.am | 10 ++
src/gallium/
The build system does not know that the static library is C++.
Mention the cpp file to trigger generation of the proper variable
and drop the hacky stdc++ linking.
Cc: Ilia Mirkin
Signed-off-by: Emil Velikov
---
src/gallium/drivers/nouveau/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 d
Cc: Ilia Mirkin
Signed-off-by: Emil Velikov
---
src/gallium/drivers/nouveau/Makefile.am | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/gallium/drivers/nouveau/Makefile.am
b/src/gallium/drivers/nouveau/Makefile.am
index f004422..27f829f 100644
--- a/src/gallium/drivers
The targets do not require expat or selinux. Use GALLIUM_COMMON_LIB_DEPS
which provides the core requirements for each gallium target.
Cc: Christian König
Signed-off-by: Emil Velikov
---
src/gallium/Automake.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium
https://bugs.freedesktop.org/show_bug.cgi?id=76848
--- Comment #5 from Emil Velikov ---
Created attachment 96690
--> https://bugs.freedesktop.org/attachment.cgi?id=96690&action=edit
automake: move GALLIUM_DRI_LIB_DEPS to Automake.inc
Nice, I forgot the "special" handling of GALLIUM_DRI_LIB_DEP
With recent commit we started de-duplicating all of the compiler/
linker flags moving their handling inside Automake.inc.
This did not take into consideration that the above variable was set
at configure time, leading to issues on certain build combinations.
Move the variable to where it's used/h
On 29/03/14 14:24, Kai Wasserbäch wrote:
> Hi Emil,
> Emil Velikov schrieb am 29.03.2014 14:21:
>> On 29/03/14 12:37, Kai Wasserbäch wrote:
>>> I saw one of your patches currently in review touching the Makefile.am of
>>> libxatracker. Can you squeeze in another patch, that ensures, that the
>>> l
On Mon, Mar 31, 2014 at 7:42 PM, Roland Scheidegger wrote:
> I've got some ideas but I'm not sure the design would be really better -
> I'd like to hear some other opinions.
>
> Am 31.03.2014 02:52, schrieb Ilia Mirkin:
>> ---
>> src/gallium/auxiliary/tgsi/tgsi_strings.c | 5 -
>> src/galli
I've got some ideas but I'm not sure the design would be really better -
I'd like to hear some other opinions.
Am 31.03.2014 02:52, schrieb Ilia Mirkin:
> ---
> src/gallium/auxiliary/tgsi/tgsi_strings.c | 5 -
> src/gallium/docs/source/context.rst| 3 +++
> src/gallium/docs/source/
https://bugs.freedesktop.org/show_bug.cgi?id=76869
--- Comment #1 from Vinson Lee ---
f6e290f80cc6728647e9cee35546190f081197e2 is the first bad commit
commit f6e290f80cc6728647e9cee35546190f081197e2
Author: Ian Romanick
Date: Wed Mar 26 15:25:08 2014 -0700
glapi/es1: Don't mark core funct
https://bugs.freedesktop.org/show_bug.cgi?id=76869
Priority: medium
Bug ID: 76869
Keywords: regression
CC: chad.vers...@linux.intel.com, i...@freedesktop.org,
matts...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=76848
--- Comment #4 from Vinson Lee ---
2d9c33009a62b704e64b49b87ed1cee9c8dcb12b is the first bad commit
commit 2d9c33009a62b704e64b49b87ed1cee9c8dcb12b
Author: Emil Velikov
Date: Tue Mar 11 13:34:53 2014 +
gallium/targets: move LLVM_LIBS
After getting the docs to build at gallium.rtfd.org, I noticed a lot of
issues. This fixes many of them. the first patch is kind of big, but it was
just a lot of deindenting + Alt-q in emacs. I later realized that that patch
could have been less drastic by just inserting more newlines, but I had
al
---
src/gallium/docs/source/context.rst | 6 +++---
src/gallium/docs/source/cso/dsa.rst | 2 +-
src/gallium/docs/source/debugging.rst | 2 +-
src/gallium/docs/source/distro.rst| 2 ++
src/gallium/docs/source/resources.rst | 2 ++
src/gallium/docs/source/tgsi.rst | 2 +-
6 files change
---
src/gallium/docs/source/tgsi.rst | 120 +++
1 file changed, 60 insertions(+), 60 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 866d2a6..a754966 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gal
---
src/gallium/docs/source/tgsi.rst | 44 +++-
1 file changed, 16 insertions(+), 28 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 6168b89..866d2a6 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gal
---
src/gallium/docs/source/format.rst | 4 ++--
src/gallium/docs/source/index.rst | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/docs/source/format.rst
b/src/gallium/docs/source/format.rst
index f6d77d6..93faf4f 100644
--- a/src/gallium/docs/source/format.rst
---
src/gallium/docs/source/tgsi.rst | 503 ---
1 file changed, 261 insertions(+), 242 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index e184b2f..d1e3528 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/g
---
src/gallium/docs/source/tgsi.rst | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index d1e3528..4493f1e 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgs
Ilia Mirkin writes:
> On Mon, Mar 31, 2014 at 4:48 PM, Eric Anholt wrote:
>> This gets us disasm of atomic ops.
>> ---
>> src/mesa/drivers/dri/i965/brw_disasm.c | 113
>> +++--
>> 1 file changed, 106 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/mesa/drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=76848
--- Comment #3 from Emil Velikov ---
Don't have Fedora 20 at hand and the config works fine under Arch. I'm
suspecting a bug in the llvm package and/or non standard libdir (llvm-config
--libdir).
Can you bisect ?
--
You are receiving this mail
On 03/27/2014 04:10 PM, Eric Anholt wrote:
> Ian Romanick writes:
>
>> Tomorrow or Friday I'm going to send out the last of the
>> GL_ARB_separate_shader_objects patches. Shortly after that, I will send
>> out patches to enable GL_EXT_separate_shader_objects on GLES. This EXT
>> is the GLES sub
https://bugs.freedesktop.org/show_bug.cgi?id=76848
--- Comment #2 from Vinson Lee ---
Fedora 20
./autogen.sh --with-dri-drivers= --with-gallium-drivers=r300
make
make check
--
You are receiving this mail because:
You are the assignee for the bug.
___
"Dorrington, Albert" writes:
>[...]
> Then, in the soft_copy_op routine, instead of passing in the slice
> pitch size, I pass in MAX2(region[0],region[1]). I'd rather pass in
> the entire vector for the region, but I didn't want to rework the
> other mapping get routines in the template quite yet
In OpenGL 3.1 attribute 0 becomes non-magic, just like in
OpenGL ES 2.0. Earlier versions of OpenGL used attribute 0
exclusively for vertex position.
Fixes 4 Khronos OpenGL CTS failures:
glGetVertexAttrib
depth24_basic
depth24_precision
rgb8_rgba8_rgb
Cc:
Signed-off-by: Anuj Phogat
---
src/mes
Patches 1, 2, and 4 through 9 are
Reviewed-by: Ian Romanick
I sent a comment on patch 3.
The comment on patch 2 is more FYI than anything.
On 03/27/2014 01:59 PM, Rafal Mielniczuk wrote:
> Hello,
>
> This is the second version of the series implementing
> ARB_query_buffer_object in mesa.
>
On Mon, Mar 31, 2014 at 4:48 PM, Eric Anholt wrote:
> This gets us disasm of atomic ops.
> ---
> src/mesa/drivers/dri/i965/brw_disasm.c | 113
> +++--
> 1 file changed, 106 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
> b/src/
This gets us disasm of atomic ops.
---
src/mesa/drivers/dri/i965/brw_disasm.c | 113 +++--
1 file changed, 106 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
b/src/mesa/drivers/dri/i965/brw_disasm.c
index 8cd8a40..5222d53 100644
---
On 03/31/2014 01:43 PM, Ian Romanick wrote:
> On 03/31/2014 01:42 PM, Ian Romanick wrote:
>> This is usually the patch where extension_table would get updated too.
>> This way you can use MESA_EXTENSION_OVERRIDE to enable the extension
>> before the rest is ready.
>
> And it allows you to check fo
On 03/27/2014 01:59 PM, Rafal Mielniczuk wrote:
> Add QueryBuffer and initialise it to NullBufferObj
> on start
>
> Signed-off-by: Rafal Mielniczuk
> ---
> src/mesa/main/bufferobj.c | 5 +
> src/mesa/main/mtypes.h| 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/src/mesa/main/
On 03/31/2014 01:42 PM, Ian Romanick wrote:
> This is usually the patch where extension_table would get updated too.
> This way you can use MESA_EXTENSION_OVERRIDE to enable the extension
> before the rest is ready.
And it allows you to check for errors. See my comment on the next patch.
> On 03
On Mon, Mar 31, 2014 at 2:43 PM, Ilia Mirkin wrote:
> On Mon, Mar 31, 2014 at 2:39 PM, Benjamin Bellec wrote:
>> Hi,
>>
>> Correct me if I'm wrong, it looks like EXT_draw_buffers2 (OpenGL 3.0) is
>> not enabled on Radeon HD2900 (R600 codename) due to hardware limitation.
>> I have no R600 card to
This is usually the patch where extension_table would get updated too.
This way you can use MESA_EXTENSION_OVERRIDE to enable the extension
before the rest is ready.
On 03/27/2014 01:59 PM, Rafal Mielniczuk wrote:
> Signed-off-by: Rafal Mielniczuk
> ---
> src/mesa/main/mtypes.h | 1 +
> 1 file c
On 03/28/2014 01:04 PM, Anuj Phogat wrote:
> On Thu, Mar 27, 2014 at 1:29 AM, Samuel Iglesias Gonsalvez
> wrote:
>> Commit 079bdba05f870807d3ed77fa3093cdb7727aa2fd enabled the use of BLORP
>> engine for single sample scaled blit with bilinear filter.
>>
>> However piglit fails when running fbo-bli
> -Original Message-
> From: Tom Stellard [mailto:t...@stellard.net]
> Sent: Monday, March 31, 2014 3:28 PM
> >
>
> There have been a few bug-fixes to the region calculation helpers in the last
> few months. You should try porting those back to 10.1 to see if it makes a
> difference.
>
https://bugs.freedesktop.org/show_bug.cgi?id=76579
Chris Forbes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=76753
Chris Forbes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=76601
Chris Forbes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=76602
Chris Forbes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=76848
--- Comment #1 from Emil Velikov ---
Hi Vinson,
Do you have a commit/configure options that can be used to reproduce the
problem ? Running make check works fine[1] on my system using llvm 3.4
(provided by Arch) and the following config.
./a
https://bugs.freedesktop.org/show_bug.cgi?id=76856
--- Comment #1 from Emil Velikov ---
Hmm how "nice" :-)
As my *BSD fu is virtually non existent would you mind checking which
library(ies) provides those functions, so that we handle this appropriately.
Unless of course *BSD have the policy of l
On Mon, Mar 31, 2014 at 06:39:26PM +, Dorrington, Albert wrote:
> I am experimenting with adding image support to Mesa and am encountering
> something I don't understand with the mapping routines implemented in
> transfer.cpp, within the soft_copy_op function.
>
> We are working on 10.1 bran
On Mon, Mar 31, 2014 at 3:00 PM, Benjamin Bellec wrote:
> I tried to get some data in the Phoronix forum, without success for the
> moment:
> http://www.phoronix.com/forums/showthread.php?98234-Can-someone-provides-me-an-glxinfo-output-of-Radeon-HD2900-series-%28R600%29
Make sure to specify mesa
I tried to get some data in the Phoronix forum, without success for the
moment:
http://www.phoronix.com/forums/showthread.php?98234-Can-someone-provides-me-an-glxinfo-output-of-Radeon-HD2900-series-%28R600%29
Maybe we should ask Michael Larabel to write an appeal to witnesses :-)
That said, is th
On Mon, Mar 31, 2014 at 2:39 PM, Benjamin Bellec wrote:
> Hi,
>
> Correct me if I'm wrong, it looks like EXT_draw_buffers2 (OpenGL 3.0) is
> not enabled on Radeon HD2900 (R600 codename) due to hardware limitation.
> I have no R600 card to check glxinfo.
>
> David Airlie enabled this extension with
I am experimenting with adding image support to Mesa and am encountering
something I don't understand with the mapping routines implemented in
transfer.cpp, within the soft_copy_op function.
We are working on 10.1 branch of Mesa which has some tweaks to let Mesa run
OpenCL kernels build from th
Hi,
Correct me if I'm wrong, it looks like EXT_draw_buffers2 (OpenGL 3.0) is
not enabled on Radeon HD2900 (R600 codename) due to hardware limitation.
I have no R600 card to check glxinfo.
David Airlie enabled this extension with this commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=de4819
I think this was used for coalescing out partly dead large virtual
registers, but the patch that enabled that caused regressions and didn't
make it upstream.
---
src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --gi
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 +++---
src/mesa/drivers/dri/i965/brw_fs.h | 16
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 713e477..56cba0e 100644
---
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 10 +-
src/mesa/drivers/dri/i965/brw_shader.h | 10 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index bbc5f3d..ca448d0 10064
---
.../drivers/dri/i965/brw_fs_register_coalesce.cpp | 37 ++
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
index 74b22b9..ca9376f 100644
--- a/s
---
.../drivers/dri/i965/brw_fs_register_coalesce.cpp | 91 +++---
1 file changed, 47 insertions(+), 44 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
index ca9376f..5c16798 100644
--- a/s
It's more likely that we won't find writes to all channels than one will
interfere, and calculating interference is more expensive. This change
will also help prepare for coalescing load_payload instructions'
operands.
Also update the live intervals for all channels, and not just the last
that we
The function has gotten large, and brw_fs.cpp is the largest source file
in the driver.
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 +
src/mesa/drivers/dri/i965/brw_fs.cpp | 181 --
.../drivers/dri/i965/brw_fs_register_coalesce.cpp | 208
https://bugs.freedesktop.org/show_bug.cgi?id=76856
Priority: medium
Bug ID: 76856
Assignee: mesa-dev@lists.freedesktop.org
Summary: -Wl,--no-undefined gives undefined references to libc
symbols on OpenBSD
Severity: normal
Matt Turner writes:
> Previously we'd ignore the sources of instructions with non-GRF
> destinations when calculating calculating the dead channels. This would
> lead to us incorrectly removing the first instruction in this sequence:
>
>mov vgrf11, ...
>cmp.ne.f0 null, vgrf11, 1.0
>mo
On Mon, Mar 31, 2014 at 11:17 AM, Leander Bessa Beernaert
wrote:
> Hey,
>
> I'm interested in dwelling deeper in the world of GPU driver development in
> my spare time. Since I'm a fan of OpenSource, Mesa3D sounded like a good
> place to start :).
>
> I have some experience using OpenGL from a pr
On 03/31/2014 08:17 AM, Leander Bessa Beernaert wrote:
> Hey,
>
> I'm interested in dwelling deeper in the world of GPU driver development
> in my spare time. Since I'm a fan of OpenSource, Mesa3D sounded like a
> good place to start :).
>
> I have some experience using OpenGL from a programmers
On 03/28/2014 12:25 AM, Eric Anholt wrote:
> I was looking at a bug report about old software, and wanted to see what
> development branch a quoted commit was on:
>
> anholt@eliezer:anholt/src/mesa-release% git describe
> 97217a40f97cdeae0304798b607f704deb0c3558
> snb-magic-15797-g9721
Hi everyone,
I've set up a readthedocs.org build to point at the gallium docs:
http://gallium.readthedocs.org/en/latest/
I didn't find any publicly available built docs otherwise (except some
rather outdated ones[1]), and this is able to build against the latest
git and auto-updates without us d
https://bugs.freedesktop.org/show_bug.cgi?id=76848
Priority: medium
Bug ID: 76848
Keywords: regression
CC: emil.l.veli...@gmail.com
Assignee: mesa-dev@lists.freedesktop.org
Summary: /usr/bin/ld: cannot find -lLLVM-3.3
S
https://bugs.freedesktop.org/show_bug.cgi?id=74312
Fabio Pedretti changed:
What|Removed |Added
Resolution|WONTFIX |FIXED
--- Comment #4 from Fabio Pedrett
On Thu, Mar 27, 2014 at 12:16 PM, Ilia Mirkin wrote:
> On Thu, Mar 27, 2014 at 11:35 AM, Jose Fonseca wrote:
>>
>>
>> - Original Message -
>>> On Wed, Mar 26, 2014 at 4:30 AM, Roland Scheidegger
>>> wrote:
>>> > Am 26.03.2014 03:29, schrieb Marek Olšák:
>>> >> My reasoning was that it wo
On Wed, Mar 26, 2014 at 05:12:20PM -0700, Ian Romanick wrote:
> Tomorrow or Friday I'm going to send out the last of the
> GL_ARB_separate_shader_objects patches. Shortly after that, I will send
> out patches to enable GL_EXT_separate_shader_objects on GLES. This EXT
> is the GLES subset of the A
Hey,
I'm interested in dwelling deeper in the world of GPU driver development
in my spare time. Since I'm a fan of OpenSource, Mesa3D sounded like a
good place to start :).
I have some experience using OpenGL from a programmers perspective, but
would like to know more about the gritty details hi
On 31/03/14 11:55, Rogovin, Kevin wrote:
> Hi,
>
> I was doing some experiments and had linking issues with C++ code and saw
> that some Mesa header files have extern "C" wrappers and others do not. For
> example running:
>
> $ find src/mesa/main -type f -name "*.h" -exec grep -H -E -o -c "e
On 03/31/2014 02:04 AM, Iago Toral Quiroga wrote:
Currently, we raise an error when doing this which breaks a conformance test
from the OpenGL samples pack. Even if this is a bit silly it is not an error.
From
https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/wiki/Rectangle_Text
On 03/31/2014 04:55 AM, Rogovin, Kevin wrote:
Hi,
I was doing some experiments and had linking issues with C++ code and saw that some
Mesa header files have extern "C" wrappers and others do not. For example
running:
$ find src/mesa/main -type f -name "*.h" -exec grep -H -E -o -c "extern
glClearBuffer() is currently clearing all active draw color buffers (all
buffers that have not been set to GL_NONE when calling glDrawBuffers) instead
of only clearing the one it receives as parameter. Altough brw_clear()
receives a bit mask indicating the color buffers that should be cleared,
this
Hi,
I was doing some experiments and had linking issues with C++ code and saw that
some Mesa header files have extern "C" wrappers and others do not. For example
running:
$ find src/mesa/main -type f -name "*.h" -exec grep -H -E -o -c "extern
\"C\"" {} \; | grep :0 | wc -l
gives a result
Currently, we raise an error when doing this which breaks a conformance test
from the OpenGL samples pack. Even if this is a bit silly it is not an error.
>From http://www.opengl.org/wiki/Rectangle_Texture:
"Rectangle textures contain exactly one image; they cannot have mipmaps.
Therefore, any te
86 matches
Mail list logo
