The glx/apple code is quite dated. I think mesa has had a few architectural
changes in the years since it was brought up (~15+ years ago). If someone is
really serious about hardware rendering for X11 apps running on macOS, I'd be
happy to chat with them and point them in the right directions
Hey folks,
I finally had a little bit of time to take a look at mesa and XQuartz for the
first time in ~4 years. I am incredibly impressed that there wasn't more
bitrot. I was expecting a painful few days since I've never looked at meson,
but I was able to get it functional relatively quickly
I think we can instead revert c7f3657450683827446072ad6b1e8fce04078162. I
believe the underlying issue should instead be addressed by
a087a09fa86f9617af98f6294dd2228555a4891c. If any issues remain, we should
address them properly rather than masking them with this.
A quick audit makes me susp
From: Apple SWE
sched_yield is used but the include reference on Darwin is missing. This patch
conditionally guards on Darwin/OSX to import sched.h first.
Reviewed-by: Jeremy Huddleston Sequoia
Signed-off-by: Jeremy Huddleston Sequoia
---
src/gallium/drivers/swr/swr_fence.cpp | 4
1
patch, it is possible to use SWR as an alternate renderer on OSX to
softpipe and
llvmpipe.
Reviewed-by: Jeremy Huddleston Sequoia
Signed-off-by: Jeremy Huddleston Sequoia
---
.../drivers/swr/rasterizer/core/threads.cpp| 56 +-
1 file changed, 55 insertions(+), 1
Signed-off-by: Jeremy Huddleston Sequoia
CC: Nicolai Hähnle
CC: Matt Turner
CC: Ian Romanick
CC: Brian Paul
---
src/mesa/main/shaderapi.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index
017-03-27 at 21:48 +0300, Andres Gomez wrote:
>> Signed-off-by: Andres Gomez
>> Cc: Emil Velikov
>> Cc: Jeremy Huddleston Sequoia
>> ---
>> docs/releasing.html | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/docs/releasing.html b/doc
LGTM
Reviewed-by: Jeremy Sequoia
> On Jan 16, 2017, at 07:45, Emil Velikov wrote:
>
> From: Emil Velikov
>
> Analogous to previous commit.
>
> Cc: "12.0 13.0"
> Cc: Jeremy Huddleston Sequoia
> Signed-off-by: Emil Velikov
> ---
> src/glx/app
> On Dec 6, 2016, at 06:04, Emil Velikov wrote:
>
> On 5 December 2016 at 22:50, Jeremy Huddleston Sequoia
> wrote:
>>
>>> On Dec 5, 2016, at 11:52 AM, Emil Velikov wrote:
>>>
>>> From: Emil Velikov
>>>
>>> No point in havin
eader uses the
> correct GLXPbufferSGIX and both types are a typedef of the same
> primitive XID.
>
> Cc: Jeremy Huddleston Sequoia
> Signed-off-by: Emil Velikov
Reviewed-by: Jeremy Sequoia
(not tested yet, though)
> ---
> Jeremy, humble poke to send any/all Macports patches to
> On Aug 12, 2016, at 05:11, Tapani Pälli wrote:
>
>
>
> On 08/12/2016 01:31 PM, Jeremy Huddleston Sequoia wrote:
>>
>>> On Aug 12, 2016, at 00:41, Tapani Pälli wrote:
>>>
>>>
>>> On 07/18/2016 07:07 PM, Jeremy Huddleston Sequoia
> On Aug 12, 2016, at 00:41, Tapani Pälli wrote:
>
>
> On 07/18/2016 07:07 PM, Jeremy Huddleston Sequoia wrote:
>> Will do. Thanks for pinging me. Early June was very busy and I didn't see
>> this come through. I'll get back to you within a couple day
> reviewed by Emil.
>
> // Tapani
>
>
> On 06/07/2016 01:33 PM, Tapani Pälli wrote:
>> Signed-off-by: Tapani Pälli
>> Cc: Jeremy Huddleston Sequoia
>> ---
>> src/glx/apple/apple_xgl_api_stereo.c | 4 ++--
>> src/glx/apple/apple_xgl_api_viewport.c
> On Jun 7, 2016, at 03:25, Emil Velikov wrote:
>
> On 31 May 2016 at 10:53, Tapani Pälli wrote:
>> From: Daniel Czarnowski
>>
>> GLX documentation states:
>>glXCreateNewContext can generate the following errors: (...)
>>GLXBadFBConfig if config is not a valid GLXFBConfig
>>
Signed-off-by: Jeremy Huddleston Sequoia
CC: Nicolai Hähnle
CC: Matt Turner
CC: Ian Romanick
---
src/mesa/main/shaderapi.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 8c1fba8
Signed-off-by: Jeremy Huddleston Sequoia
CC: Nicolai Hähnle
CC: Matt Turner
---
src/mesa/main/shaderapi.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index a988f41..7a0d19a 100644
--- a/src/mesa
> On Jan 21, 2016, at 07:51, Nicolai Hähnle wrote:
>
> Wow... did you actually run into that crash?
No. I was just paying attention to compiler warnings ;)
>
> On 20.01.2016 20:14, Jeremy Huddleston Sequoia wrote:
>> Signed-off-by: Jeremy Huddleston Sequoia
>
This series includes 3 changes related to help reconcile the differences in
declaration between Apple's vs Mesa's GLhandleARB type. The first, I expect to
be mostly uncontroversial as they are mainly cleaning up and correcting some
prototypes. The second is just a casting which should be fine.
: incompatible pointer types passing 'void
(GLhandleARB)' (aka 'void (unsigned long)') to parameter of type 'void
(*)(GLuint)' (aka 'void (*)(unsigned
int)')
[-Wincompatible-pointer-types]
SET_UseProgram(table, save_UseProgramObjectARB);
"glDeleteObjectARB(%u)\n", obj);
~~ ^~~
%lu
Signed-off-by: Jeremy Huddleston Sequoia
---
src/mesa/main/shaderapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 9512e3b..a988f41 100644
--- a/src/mesa/main/sha
Signed-off-by: Jeremy Huddleston Sequoia
---
src/mesa/main/shaderapi.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index a988f41..75fc17c 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main
Sorry, I thought I responded to this a while ago.
Reviewed-by: Jeremy Huddleston Sequoia
Tested-by: Jeremy Huddleston Sequoia
--Jeremy
> On Jan 19, 2016, at 05:21, Andreas Boll wrote:
>
> Jeremy, did you have a chance to test this patch?
> This patch would be still useful for O
The general concept of this change seems fine to me.
Given the desire to keep glapi as similar as possible across platforms, would
it be better to just move this into glx/apple rather than leaving it in glapi?
> On Dec 9, 2015, at 09:07, Emil Velikov wrote:
>
> On 9 December 2015 at 14:11, And
r, then the best thing might be
> to remove it entirely.
>
> On Sat, Sep 26, 2015 at 5:56 PM, Jeremy Huddleston Sequoia
> wrote:
> Reviewing diffs of code that generates code is always ick. =(
>
> This *looks* right to me, but has it been given a beating for correctness?
>
Sorry, been slammed and trying to catch up. I forget if I replied to this or
not, but if you're still waiting on me:
Reviewed-by: Jeremy Huddleston Sequoia
> On Jul 9, 2015, at 10:55, Ian Romanick wrote:
>
> I can't really speak to the Android.mk or SConscript changes
Reviewing diffs of code that generates code is always ick. =(
This *looks* right to me, but has it been given a beating for correctness? If
not, let me know, and I'll give it a whirl when I have some cycles.
Reviewed-by: Jeremy Huddleston Sequoia
---
You're right that this used to
Wow, that's a blast from the past ;)
> On Sep 3, 2015, at 21:36, Matt Turner wrote:
>
> From: Jeremy Huddleston
>
> Cc: "10.6 11.0"
> Bugzilla: https://bugs.gentoo.org/240956
> ---
> After talking with Ian today, we determined that this disables an
> On May 20, 2015, at 13:59, Emil Velikov wrote:
>
> Hi Jeremy,
>
> On 11 February 2015 at 20:36, Jeremy Huddleston Sequoia
> wrote:
>>
>> Signed-off-by: Jeremy Huddleston Sequoia
>> ---
>> include/GL/glext.h | 1 +
>> 1 file changed, 1 inser
Looks right to me. I think this was also mentioned in the bugzilla ticket
where this change was committed from.
Reviewed-by: Jeremy Huddleston Sequoia
> On May 15, 2015, at 19:05, Alan Coopersmith
> wrote:
>
> Fixes regression from commit 5b2d3480f57168d50ad24cf0b8c9
Signed-off-by: Jeremy Huddleston Sequoia
---
include/GL/glext.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index 256ad35..0328cf6 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -4470,6 +4470,7 @@ GLAPI void APIENTRY glVertexBlendARB
> On Feb 11, 2015, at 05:02, Emil Velikov wrote:
>
> On 11 February 2015 at 10:32, Jeremy Huddleston Sequoia
> wrote:
>> libOSMesa is a library, not a module
>>
> Fwiw I'm not 100% sure that's the case. But considering it's been like
> that* for a
libOSMesa is a library, not a module
Signed-off-by: Jeremy Huddleston Sequoia
---
src/mesa/drivers/osmesa/Makefile.am | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/osmesa/Makefile.am
b/src/mesa/drivers/osmesa/Makefile.am
index 589b5ee..8d69915 100644
--- a/src/mesa
Is there any indication on when is this "temporary" hack going to be removed?
This kind of linking is not legal in many toolchains (eg on darwin), and I
imagine behavior is not well defined in places where this hack actually works.
--Jeremy
commit 7414552b1826ece48a622c14b48cad3a37b68025
Autho
Fixes regression from commit 64b1dc44495890cbc2c7c5509cb830264020998c
Signed-off-by: Jeremy Huddleston Sequoia
CC: Emil Velikov
CC: jon.tur...@dronecode.org.uk
CC: io...@macports.org
---
src/mesa/drivers/dri/swrast/swrast.c | 16
1 file changed, 16 insertions(+)
diff --git a
e we don't even want to return
the full size of system memory for __DRI2_RENDERER_VIDEO_MEMORY.
> On Jan 1, 2015, at 20:10, Jeremy Huddleston Sequoia
> wrote:
>
> Fixes regression from commit 64b1dc44495890cbc2c7c5509cb830264020998c
>
> Signed-off-by: Jeremy Huddleston
I'm trying to take a stab at adding core profile support to XQuartz. As a
first step, I'm trying to add GLX_ARB_create_context and
GLX_ARB_create_context_profile.
For now, I want to make sure that GLX_ARB_create_context and
GLX_ARB_create_context_profile are only advertised as being available
On May 24, 2014, at 19:55, Emil Velikov wrote:
> On 25/05/14 02:12, Jeremy Huddleston Sequoia wrote:
>> I'm getting this build failure:
>>
>> main/shader_query.cpp:49:7: error: no matching function for call to
>> '_mesa_lookup_shader_program_err'
&
I'm getting this build failure:
main/shader_query.cpp:49:7: error: no matching function for call to
'_mesa_lookup_shader_program_err'
_mesa_lookup_shader_program_err(ctx, program, "glBindAttribLocation");
^~~
../../src/mesa/main/shaderobj.h:81:1: note: cand
On May 20, 2014, at 05:57, Jon TURNEY wrote:
> On 20/05/2014 09:57, Jeremy Huddleston Sequoia wrote:
>> Reviewed-by: Jeremy Huddleston Sequoia with one minor change (see below):
>
> Thanks very much for taking the time to review these.
No, thank you for taking the time to do th
Reviewed-by: Jeremy Huddleston Sequoia
On May 13, 2014, at 05:15, Jon TURNEY wrote:
> - Don't require xcb-dri[23] etc. if we aren't building for a target with DRM,
> as
> we won't be using dri[23]
>
> - Enable a more fine-grained control of what DRI code is bui
Reviewed-by: Jeremy Huddleston Sequoia with one minor
change (see below):
On May 13, 2014, at 05:15, Jon TURNEY wrote:
...
> diff --git a/src/glx/Makefile.am b/src/glx/Makefile.am
> index eee7c2c..c18d1c5 100644
> --- a/src/glx/Makefile.am
> +++ b/src/glx/Makefile.am
>
On Feb 17, 2014, at 13:29, Emil Velikov wrote:
> On 17/02/14 06:49, Jeremy Huddleston Sequoia wrote:
>>
>> On Feb 16, 2014, at 17:15, Emil Velikov wrote:
>>
>>> On 16/02/14 02:00, Jeremy Huddleston Sequoia wrote:
>>>> Mesa master hasn't built fo
On Feb 16, 2014, at 17:15, Emil Velikov wrote:
> On 16/02/14 02:00, Jeremy Huddleston Sequoia wrote:
>> Mesa master hasn't built for OSX for over a year now, unfortunately, but I
>> agree excluding in Makefile.am is preferable to cpp-guards. Hopefully
>> "
Mesa master hasn't built for OSX for over a year now, unfortunately, but I
agree excluding in Makefile.am is preferable to cpp-guards. Hopefully
"someone" will have the time and patience to get it working again in the near
future.
--Jeremy
Sent from my iPad
> On Feb 13, 2014, at 8:29, Ian Ro
Yep, looks right to me.
Reviewed-by: Jeremy Huddleston Sequoia:
On Feb 10, 2014, at 07:57, Ian Romanick wrote:
> Perhaps Jeremy can review this patch...
>
> On 02/10/2014 01:58 AM, Siavash Eliasi wrote:
>> ---
>> src/glx/apple/apple_glx_context.c | 1 +
>>
Tested-by: Jeremy Huddleston Sequoia
I tried applying that change to current master
(a0698b000b693fc1345fadd6d418dfd8d7548e44), and it didn't work at first, but
after a make clean it did. It looks like the Makefile dependencies were
insufficient to propagate this change properly. O
Mesa master stopped building successfully on my tinderbox on 7/6. The relevant
changes from the previous successful build were 95ce454..c445b0f, and I
bisected it to the upgrade of gl2ext.h to version 18099 (see below).
../../../src/mapi/glapi/glapitemp.h:4635:1: error: no previous prototype fo
On May 24, 2012, at 11:36, Matt Turner wrote:
> On Thu, May 24, 2012 at 2:20 PM, Jeremy Huddleston wrote:
>> This is still a problem with the 8.0.3 release. Can this please get
>> addressed in 8.0.4 =):
>>
>> python -t -O -O ../../src/mapi/glapi/gen/gl_table.py
This is still a problem with the 8.0.3 release. Can this please get addressed
in 8.0.4 =):
python -t -O -O ../../src/mapi/glapi/gen/gl_table.py -f
../../src/mapi/glapi/gen/gl_and_es_API.xml -m remap_table -c es1 >
main/api_exec_es1_dispatch.h
python -t -O -O ../../src/mapi/glapi/gen/gl_table.p
On May 11, 2012, at 08:58, Bryan Henderson wrote:
>> Android does not have strtod_l. Yet, the old co de successfully compiled
>> because Android does not define _GNU_SOURCE.
>
> Just to make sure we're all on the same page: NOBODY defines _GNU_SOURCE.
> At least they shouldn't.
Tell that to th
rote:
> From: Bryan Henderson
>
> [v2/Kayden: rebased version of Bryan's original patch from:
> https://bugs.freedesktop.org/show_bug.cgi?id=33447]
>
> Cc: Jeremy Huddleston
> Cc: Chad Versace
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33447
> Signe
On Mar 19, 2012, at 5:18 AM, Jakob Bornecrantz wrote:
> - Original Message -
>> Please make sure to include python-generated C files in the 8.0.2
>> tarball. They were not there in 8.0.1's:
>>
>> python -t -O -O main/es_generator.py -S main/APIspec.xml -V GLES1.1 >
>> main/api_exec_es1
Please make sure to include python-generated C files in the 8.0.2 tarball.
They were not there in 8.0.1's:
python -t -O -O main/es_generator.py -S main/APIspec.xml -V GLES1.1 >
main/api_exec_es1.c
Traceback (most recent call last):
File "main/es_generator.py", line 26, in
import APIspecu
On Jan 2, 2012, at 7:03 PM, Ian Romanick wrote:
> On 01/02/2012 06:18 PM, Jeremy Huddleston wrote:
>> xdriinfo is failing to build in tinderbox (through no change of its own).
>> The relevant changes in mesa were bce506f..7705833. My guess is that this
>> was caused by on
xdriinfo is failing to build in tinderbox (through no change of its own). The
relevant changes in mesa were bce506f..7705833. My guess is that this was
caused by one of:
glx: Add __glX_send_client_info super function
glx: Initial implementation of glXCreateContextAttribsARB
Here's the tinderb
6, 7, and 13 look good to me, but I haven't tested them yet.
Reviewed-by: Jeremy Huddleston
On Dec 16, 2011, at 11:55 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> Cc: Jeremy Huddleston
> ---
> src/glx/Makefile |1 +
&
On Nov 28, 2011, at 6:56 PM, Jakob Bornecrantz wrote:
> On Mon, Nov 28, 2011 at 3:13 AM, Ian Romanick wrote:
>> All,
>>
>> I'm starting to work on GLX_ARB_create_context. This extension and the
>> layered GLX_ARB_create_context_profile extension add some GLX protocol. Is
>> there any reason t
>>> So the original complaint, that he is "forced to accept the GPLv3
>>> to use autoconf" seems a little confused.
>>
>> From the 2.62 release notes at
>> http://lists.gnu.org/archive/html/autotools-announce/2008-04/msg2.html:
>>
>> """
>> Meanwhile, several source files within the Autoconf
On Sep 28, 2011, at 23:28, Miles Bader wrote:
> 2011/9/29 Alan Coopersmith :
>>> _Why_ is the GPLv3 "not acceptable", when the GPLv2 was?
>>
>> Note his employer, which is well known as not accepting the GPLv3,
>> possibly due to it being a mobile phone manufacturer, and the GPLv3's
>> free pate
That looks like it:
Reviewed-by: Jeremy Huddleston
Tested-by: Jeremy Huddleston
You can probably revert the --dereference one as well.
On Jul 26, 2011, at 12:09 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> Cc: Jeremy Huddleston
> Cc: Andreas Radke
> ---
> Please l
On Jul 25, 2011, at 8:02 PM, Ian Romanick wrote:
>
>> Can we please get a 7.10.4 release with this fixed? It's not a bug
>> in libarchive; you just get lucky that gnutar doesn't complain (which
>> I think *is* a bug in gnutar).
>
> Does this still occur in the 7.11-rc3 tarballs?
It's the same
Can we please get a 7.10.4 release with this fixed? It's not a bug in
libarchive; you just get lucky that gnutar doesn't complain (which I think *is*
a bug in gnutar).
Some users are running into problems using gnutar with this archive, so that's
not really a great fallback either:
https://tra
In applegl, GLX advertises the same extensions provided by OpenGL.framework
even if such extensions are not provided by glapi. This allows a client
to get access to such API.
Signed-off-by: Jeremy Huddleston
---
src/glx/applegl_glx.c |9 +
src/glx/dri2_glx.c |1 +
src/glx
We want to bind to our context before calling __glXSetCurrentContext or
messing with the gc rect in order to properly handle error conditions.
Signed-off-by: Jeremy Huddleston
---
src/glx/glxcurrent.c | 25 -
1 files changed, 16 insertions(+), 9 deletions(-)
diff
FramebufferTextureLayer is an alias of FramebufferTextureLayerEXT, so
FramebufferTextureLayerARB needs to be listed as an alias of
FramebufferTextureLayerEXT rather than FramebufferTextureLayer.
Signed-off-by: Jeremy Huddleston
---
src/mapi/glapi/gen/ARB_geometry_shader4.xml |2 +-
1 files
This fixes a regression introduced by 49d7e48b33264d94e30af6129c281b6acafa9427
Signed-off-by: Jeremy Huddleston
---
src/glx/glxcurrent.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git origin/master/src/glx/glxcurrent.c origin/master/src/glx/glxcurrent.c
FramebufferTextureLayer is an alias of FramebufferTextureLayerEXT, so
FramebufferTextureLayerARB needs to be listed as an alias of
FramebufferTextureLayerEXT rather than FramebufferTextureLayer.
Signed-off-by: Jeremy Huddleston
---
src/mapi/glapi/gen/ARB_geometry_shader4.xml |2 +-
1 files
-Brian
>
> On 06/14/2011 01:33 PM, Jeremy Huddleston wrote:
>> Hi Brian,
>>
>> Please give this change a try. It should clear up the gcc -pedantic
>> warnings and also replaces the NULL entries with noops since that seems to
>> be done in other tables as
_proc) dlsym(handle, symboln);
+void ** procp = (void **) &disp->%(name)s;
+*procp = dlsym(handle, symboln);
}
"""
On Jun 13, 2011, at 3:13 PM, Brian Paul wrote:
> On 06/13/2011 03:53 PM, Jeremy Huddleston wrote:
>> b44d13e67bfe81b2d7af4aeda2c3
We want to bind to our context before calling __glXSetCurrentContext or
messing with the gc rect in order to properly handle error conditions.
Signed-off-by: Jeremy Huddleston
---
src/glx/glxcurrent.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git
b44d13e67bfe81b2d7af4aeda2c3caf7f252bd0f should work for you. Thanks for
letting me know.
--Jeremy
On Jun 13, 2011, at 2:27 PM, Brian Paul wrote:
> On 06/13/2011 02:05 PM, Jeremy Huddleston wrote:
>> Hi Brian,
>>
>> Does this get rid of your warnings? (you'
Alright... looks like it needs the cast.
Thanks.
On Jun 13, 2011, at 2:27 PM, Brian Paul wrote:
> On 06/13/2011 02:05 PM, Jeremy Huddleston wrote:
>> Hi Brian,
>>
>> Does this get rid of your warnings? (you'll need to regenerate the
>> glapi_gentable.c)
>
;"
body_template = """
if(!disp->%(name)s) {
snprintf(symboln, sizeof(symboln), "%%s%(entry_point)s",
symbol_prefix);
- SET_%(name)s(disp, dlsym(handle, symboln));
+ disp->%(name)s = dlsym(handle, symboln);
}
""&q
isn't checked in to git. Please let me know
if I should keep the generated code out of git.
Thanks,
Jeremy
The patch was rejected by the list due to size, so see it here:
http://cgit.freedesktop.org/~jeremyhu/mesa/commit/?id=45aed4cea5b938cce9bfd8e93d16255b2b7a466a
On Jun 8, 2011, at 12
In moving src/glx/apple over to glapi this past week, I used our dispatch table
code from xserver/hw/xquartz/GL/indirect.c as the model for creating our
_glapi_table. Our table should contain pointers into OSX's OpenGL
implementation, so the call is just passed along to that implementation.
C
Hi Chia,
Thanks for your help untangling the web.
--Jeremy
On Jun 7, 2011, at 2:51 PM, Chia-I Wu wrote:
> On Wed, Jun 8, 2011 at 3:08 AM, Jeremy Huddleston wrote:
>>
>> On Jun 7, 2011, at 2:13 PM, Brian Paul wrote:
>>
>>>> Ok, I see what is happening. conf
On Jun 7, 2011, at 2:13 PM, Brian Paul wrote:
>> Ok, I see what is happening. configs/darwin bitrotted and included the
>> -lGL, but other configs have since removed that. It looks like I should
>> just remove -lGL from OSMESA_LIB_DEPS in addition to the other changes that
>> I've already se
On Jun 7, 2011, at 1:01 PM, Jeremy Huddleston wrote:
>
> On Jun 7, 2011, at 12:01 PM, Jeremy Huddleston wrote:
>
>> So what is the proper fix here? How should libOSMesa be getting built?
>>
>> Should libmesa.a be providing those stubs (rather than my change which
On Jun 7, 2011, at 12:01 PM, Jeremy Huddleston wrote:
> So what is the proper fix here? How should libOSMesa be getting built?
>
> Should libmesa.a be providing those stubs (rather than my change which put
> them in mesa/osmesa)? Should the stubs be getting exported by li
On Jun 7, 2011, at 7:19 AM, Chia-I Wu wrote:
> In indirect rendering, glGenTextures and glGenTexturesEXT, for
> example, use different opcodes. However, those functions are assigned
> the same dispatch offset in glapi. If glapi defines both of them,
> they will be dispatched to the same function
When GLX_INDIRECT_RENDERING is defined, some symbols are used in
libglapi.a but are not defined. Define them through the help of
glapitemp.h.
Signed-off-by: Jeremy Huddleston
Signed-off-by: Chia-I Wu
---
Please see my previous post for discussion. This patch fixes the build as
discussed in
I'm having trouble understanding why GLX_INDIRECT_RENDERING changes what is
built into glapi. I assumed that glapi was agnostic to the actual
implementation, so why does glapi care about GLX_INDIRECT_RENDERING?
I'm trying to build mesa with support for (only) indirect rendering on darwin.
lib
src/glx/apple should land in MesaLib. What magic needs to be done to make sure
it lands up there? This was a problem with 7.8.x, and I just solved it by
putting out my own MesaLibApple-7.8.2. 7.9.x and 7.10.x didn't build on
darwin, so it wasn't really a concern.
I've gone through and fixed
I think I've figured out those issues... I just need to now figure out how to
properly implement applegl_glx.c ...
On Jun 5, 2011, at 6:34 PM, Jeremy Huddleston wrote:
> So I've finally sat down and tried to fix regressions on master due to glx
> restructuring last year ...
So I've finally sat down and tried to fix regressions on master due to glx
restructuring last year ... mostly these are changes where people forgot to
make corresponding changes in the apple subdirectory.
There is one standout that I'm not sure how to fix (glxext.c). This is a build
failure in
See:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=bb4d145bd25e2aee988b100ecf1105ea3b6a40b8
I suggest you do something similar for mesa.
On Apr 9, 2011, at 04:28, Sedat Dilek wrote:
> Just as an addendum to configure-option "--enable-glx-tls" (see [1] and [2]).
>
> - Sedat -
>
> [1]
> h
something we can have a sit-down about during XDC. So from a
high-level point of view:
Reviewed-by: Jeremy Huddleston
but this should also be reviewed by someone who has more understanding of GLX.
--Jeremy
On May 6, 2011, at 14:01, Jesse Barnes wrote:
> On Fri, 6 May 2011 13:00:19 -
Yeah, that looks about right.
This in combination with the latest version of "xserver/glx/dri2: use new
GLX/DRI2 swap event types"
Reviewed-by: Jeremy Huddleston
On May 6, 2011, at 10:39, Jesse Barnes wrote:
> On Fri, 06 May 2011 09:25:35 +0200
> Michel Dänzer wrote:
>
For *proto/mesa:
Reviewed-by: Jeremy Huddleston
For xserver:
This looks incomplete. You also need to update swap_count in DRI2DrawableRec
to be CARD32.
On May 5, 2011, at 12:45 PM, Jesse Barnes wrote:
> Use the new event types so we can pass a valid SBC value to clients.
> Fix
>> Yes, I realize that there are some areas that use 64bit for sbc. Do we
>> really need 64bits for this? If so, how do we properly to communicate the
>> 64bit value between server/client? Currently, your changes result in an
>> implicit cast from 64bit to 32bits in DRI2SwapComplete which wil
On May 5, 2011, at 1:09 PM, Jesse Barnes wrote:
> On Thu, 05 May 2011 12:59:50 -0700
> Jeremy Huddleston wrote:
>
>> For *proto/mesa:
>> Reviewed-by: Jeremy Huddleston
>
> Thanks.
>
>> For xserver:
>> This looks incomplete. You also need to upda
We just prefix the $CLANG environment variable in configure.ac with acv_mesa_
Found by: tinderbox
Signed-off-by: Jeremy Huddleston
---
configure.ac |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configure.ac b/configure.ac
index 54d9c29..f3f0fda 100644
--- a
ent);
}
On May 5, 2011, at 08:28, Jesse Barnes wrote:
> On Wed, 4 May 2011 21:29:23 -0700
> Jeremy Huddleston wrote:
>
>> Yeah... so considering the comments in mesa-dev earlier today, I was really
>> surprised to see that glproto and dri2proto were tagged today. I thi
Yeah... so considering the comments in mesa-dev earlier today, I was really
surprised to see that glproto and dri2proto were tagged today. I think we need
to brownbag retract and rethink this.
These changes break API. I'm all for fixing the structs, but anything that
breaks API (or worse, pro
On May 4, 2011, at 11:04, Jesse Barnes wrote:
> libGL is missing the change and version requirement bump, so you'll
> have to use the last glproto release until I land the Mesa fix along
> with a new glproto release. Sorry for the trouble; I pushed glproto
> yesterday assuming I'd be able to pus
Well, it's not building correctly on my tinderbox which uses master glproto and
master libGL, so either libGL has bad C, or libGL is using the system's glproto
instead of the one it queries out of PKG_CONFIG_PATH. Either way, it's a mesa
bug happening on both of my linux tinderboxes (gentoo ppc
The 7.8.2 release is missing src/glx/apple ... I have made these bits available
here:
http://static.macosforge.org/xquartz/downloads/src/MesaApple-7.8.2.tar.bz2
sha1476f177ec6cbe8d5718a2109516a5121ab1574d2
rmd160 c2dd3363883c5826a9797ef631f668958660e740
What needs to be done to make sure t
Yeah, this is likely on my end. I needed to backup the version installed on
the system, and I don't build mesa in the tinderbox. Please ignore.
On Jun 30, 2010, at 06:03, Chris Ball wrote:
> http://tinderbox.x.org/builds/2010-06-30-0016/logs/xserver/#configure
>
> configure: error: Package re
On Jun 16, 2010, at 16:25, Dan Nicholson wrote:
> On Wed, Jun 16, 2010 at 4:20 PM, Jeremy Huddleston
> wrote:
>> Hey Tom,
>>
>> What version of OSX do you have? I hadn't pulled changes into my tree
>> (http://cgit.freedesktop.org/~jeremyhu/mesa/log/?h=7.8)
Hey Tom,
What version of OSX do you have? I hadn't pulled changes into my tree
(http://cgit.freedesktop.org/~jeremyhu/mesa/log/?h=7.8) since the
beginning of May, but I'm building that version just fine on Leopard
and Snow Leopard with 'make darwin'. I haven't given the autoconf
route a
1 - 100 of 103 matches
Mail list logo
