Re: state of EGL support on MacOS?

[Jeremy Huddleston Sequoia]

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 with more future 
focus:
Wayland + Xwayland for X11 support
Metal for rendering to IOSurfaces that back the windows
DRI would be straight forward (share the IOSurface with the client)
EGL and OpenGL on top of Vulcan+MoltenVK on Metal (removing macOS' 
OpenGL.fw and OpenGLES.fw from the equation completely)

#1 and #2 are where I think we get the biggest wins in terms of code debt, 
maintainability.

If you just want to get things building, you should point out to folks that 
they should not assume GLES is available and build their apps to support 
OpenGL.  If you want to invest minimal effort, you could probably get core 
support added to glx/apple without too much more work...


> On Sep 24, 2022, at 11:36, Ken Cunningham  
> wrote:
> 
> Reading through the mesa source, it seems that GLX uses hardware OpenGL 
> support on Darwin that was supplied by Apple initially in 2010, and updated 
> since (apple subdir in glx).
> 
> But if I am reading it correctly (and I easily might not be), the EGL 
> implementation on mesa does not use Apple hardware support, but instead 
> software rendering.
> 
> So — even though mesa with EGL will build on Darwin, performance would be 
> very much below GLX, so best avoided.
> 
> I have patched the gtk4 source to avoid requiring EGL for now, and forced GLX 
> to be used always. 
> 
> If I’m way off here, appreciate anyone putting me on the right path.
> 
> Best,
> 
> Ken
> 
> 
>> On Sep 12, 2022, at 9:50 PM, Ken Cunningham 
>>  wrote:
>> 
>> Hello, first post.
>> 
>> I would like to ask about the status of EGL support in mesa for MacOS 
>> systems, whether it is mature and robust and usable at present for software 
>> builds. I know it can be toggled on in the mesa build on Darwin systems, and 
>> it generates. EGL headers and libraries. But is seems to be little used at 
>> present, as far as I can see.
>> 
>> Why:
>> 
>> I help maintain ports at MacPorts. Many of these use the gtk3 x11 version of 
>> the software, using an x11 server like xorg-server or XQuartz to display 
>> them. (A lesser number of software projects can use the gtk3 quartz 
>> interface instead.)
>> 
>> Lately, perhaps related to wayland, it seeems a number of software projects, 
>> eg gtk4, have been written assuming that x11 software will have EGL headers 
>> and libraries available, with GLX as a fallback.
>> 
>> If there are no EGL headers and support libraries available, these projects 
>> don’t readily compile without a fair bit of surgery to #ifdef out the 
>> assumed EGL support. It would be much easier to just use EGL instead, from 
>> mesa or otherwise, if it is robust.
>> 
>> Thanks,
>> 
>> Ken
> 

[Mesa-dev] Supporting macOS / XQuartz on master

[Jeremy Huddleston Sequoia]

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 have a few pull requests which I'd like to have some eyes on.

These first two are a meson configuration changes to pickup the system libexpat 
and libunwind (plus a build fix due to bad implicit casting in mesa's libunwind 
usage).  I'd appreciate someone with meson-fu to look them over and let me know 
if there's a better way to do this:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8501
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8502

This last one is probably a bit more political as it bumps our C language 
version from C99 to C11.  This is being done because we make use of 
timespec_get() which was added to C11.  Using -std=c99 will cause the prototype 
to be omitted from system headers on strictly compliant systems (eg: macOS) 
even when the system supports this function.

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8496

Thanks in advance for looking these over.

--Jeremy

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH mesa] meson: add GL/glext.h warning fix for MacOS

[Jeremy Huddleston Sequoia]

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 suspect we'll get some (benign) 32-64 pointer conversion 
warnings in some cases which can be addressed like this:

 void GLAPIENTRY
 _mesa_GetAttachedObjectsARB(GLhandleARB container, GLsizei maxCount,
 GLsizei * count, GLhandleARB * obj)
 {
GET_CURRENT_CONTEXT(ctx);
-   get_attached_shaders(ctx, (GLuint)container, maxCount, count, NULL, obj);
+   get_attached_shaders(ctx, (GLuint)(uintptr_t)container, maxCount, count, 
NULL, obj);
 }

I think that is preferable to masking the problem.  If you prefer, I can do a 
pass to fixup the casting followed by a revert of 
c7f3657450683827446072ad6b1e8fce04078162 separate from your series.

Thanks,
Jeremy

> On Jun 15, 2018, at 6:41 AM, Jon Turney  wrote:
> 
> On 12/06/2018 16:53, Dylan Baker wrote:
>> Quoting Eric Engestrom (2018-06-12 04:25:10)
>>> Copied from configure.ac:1950
>>> 
>>> Signed-off-by: Eric Engestrom 
>>> ---
>>> Is it still needed? We've been building on MacOS for a while,
>>> yet nobody noticed anything (Dylan?)
>>> If not, we should probably avoid unnecessary differences with Khronos'
>>> headers and nuke BUILDING_MESA.
>>> ---
>>>  meson.build | 1 +
>>>  1 file changed, 1 insertion(+)
>>> 
>>> diff --git a/meson.build b/meson.build
>>> index c5acc8a3587ea20e131e..04b3bdfd77f36670ff7f 100644
>>> --- a/meson.build
>>> +++ b/meson.build
>>> @@ -209,6 +209,7 @@ endif
>>>if host_machine.system() == 'darwin'
>>>with_dri_platform = 'apple'
>>> +  pre_args += '-DBUILDING_MESA'
>>>  elif ['windows', 'cygwin'].contains(host_machine.system())
>>>with_dri_platform = 'windows'
>>>  elif system_has_kms_drm
>>> -- 
>>> Cheers,
>>>   Eric
>>> 
>> I didn't notice, but I also didn't do a whole lot of testing
>> I've added Jon who did most of the meson mac work and Jeremy who's the 
>> resident
>> mac expert.
> No expert, but I believe this is unfortunately still needed.
> 
> See commit c7f36574 and the referenced BZ.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa 2/2] sched.h needs to be imported on Darwin/OSX targets.

[Jeremy Huddleston Sequoia]

From: Apple SWE <jerem...@apple.com>

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 <jerem...@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
---
 src/gallium/drivers/swr/swr_fence.cpp | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/gallium/drivers/swr/swr_fence.cpp 
b/src/gallium/drivers/swr/swr_fence.cpp
index 3005eb9aaa..b05ac8cec0 100644
--- a/src/gallium/drivers/swr/swr_fence.cpp
+++ b/src/gallium/drivers/swr/swr_fence.cpp
@@ -29,6 +29,10 @@
 #include "swr_screen.h"
 #include "swr_fence.h"
 
+#ifdef __APPLE__
+#include 
+#endif
+
 #if defined(PIPE_CC_MSVC) // portable thread yield
#define sched_yield SwitchToThread
 #endif
-- 
2.16.1 (Apple Git-102)

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH mesa 1/2] Add processor topology calculation implementation for Darwin/OSX targets.

[Jeremy Huddleston Sequoia]

From: Apple SWE <jerem...@apple.com>

The implementation for bootstrapping SWR on Darwin targets is based on the 
Linux version.
Instead of reading the output of /proc/cpuinfo, sysctlbyname is used to 
determine the
physical identifiers, processor identifiers, core counts and thread-processor 
affinities.

With this patch, it is possible to use SWR as an alternate renderer on OSX to 
softpipe and
llvmpipe.

Reviewed-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
---
 .../drivers/swr/rasterizer/core/threads.cpp| 56 +-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/swr/rasterizer/core/threads.cpp 
b/src/gallium/drivers/swr/rasterizer/core/threads.cpp
index 4d79168d2d..3eb20abcbf 100644
--- a/src/gallium/drivers/swr/rasterizer/core/threads.cpp
+++ b/src/gallium/drivers/swr/rasterizer/core/threads.cpp
@@ -36,6 +36,11 @@
 #include 
 #endif
 
+#ifdef __APPLE__
+#include 
+#include 
+#endif
+
 #include "common/os.h"
 #include "context.h"
 #include "frontend.h"
@@ -219,6 +224,56 @@ void CalculateProcessorTopology(CPUNumaNodes& out_nodes, 
uint32_t& out_numThread
 
 #elif defined(__APPLE__)
 
+auto numProcessors = 0;
+auto numCores = 0;
+auto numPhysicalIds = 0;
+
+int value;
+size_t size = sizeof(value);
+
+int result = sysctlbyname("hw.packages", , , NULL, 0);
+SWR_ASSERT(result == 0);
+numPhysicalIds = value;
+
+result = sysctlbyname("hw.logicalcpu", , , NULL, 0);
+SWR_ASSERT(result == 0);
+numProcessors = value;
+
+result = sysctlbyname("hw.physicalcpu", , , NULL, 0);
+SWR_ASSERT(result == 0);
+numCores = value;
+
+out_nodes.resize(numPhysicalIds);
+
+for (auto physId = 0; physId < numPhysicalIds; ++physId)
+{
+auto  = out_nodes[physId];
+auto procId = 0;
+
+numaNode.cores.resize(numCores);
+
+while (procId < numProcessors)
+{
+for (auto coreId = 0; coreId < numaNode.cores.size(); ++coreId, 
++procId)
+{
+auto  = numaNode.cores[coreId];
+
+core.procGroup = coreId;
+core.threadIds.push_back(procId);
+}
+}
+}
+
+out_numThreadsPerProcGroup = 0;
+
+for (auto  : out_nodes)
+{
+for (auto  : node.cores)
+{
+out_numThreadsPerProcGroup += core.threadIds.size();
+}
+}
+
 #else
 
 #error Unsupported platform
@@ -253,7 +308,6 @@ void CalculateProcessorTopology(CPUNumaNodes& out_nodes, 
uint32_t& out_numThread
 }
 }
 
-
 void bindThread(SWR_CONTEXT* pContext, uint32_t threadId, uint32_t procGroupId 
= 0, bool bindProcGroup=false)
 {
 // Only bind threads when MAX_WORKER_THREADS isn't set.
-- 
2.16.1 (Apple Git-102)

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: Deal with size differences between GLuint and GLhandleARB in GetAttachedObjectsARB

[Jeremy Huddleston Sequoia]

Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
CC: Nicolai Hähnle <nhaeh...@gmail.com>
CC: Matt Turner <matts...@gmail.com>
CC: Ian Romanick <i...@freedesktop.org>
CC: Brian Paul <bri...@vmware.com>
---
 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 6dd617be7e..7282435583 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -513,10 +513,12 @@ detach_shader_no_error(struct gl_context *ctx, GLuint 
program, GLuint shader)
 
 /**
  * Return list of shaders attached to shader program.
+ * \param objOut  returns GLuint ids
+ * \param handleOut  returns GLhandleARB handles
  */
 static void
 get_attached_shaders(struct gl_context *ctx, GLuint program, GLsizei maxCount,
- GLsizei *count, GLuint *obj)
+ GLsizei *countOut, GLuint *objOut, GLhandleARB *handleOut)
 {
struct gl_shader_program *shProg;
 
@@ -531,14 +533,20 @@ get_attached_shaders(struct gl_context *ctx, GLuint 
program, GLsizei maxCount,
if (shProg) {
   GLuint i;
   for (i = 0; i < (GLuint) maxCount && i < shProg->NumShaders; i++) {
- obj[i] = shProg->Shaders[i]->Name;
+ if (objOut) {
+objOut[i] = shProg->Shaders[i]->Name;
+ }
+
+ if (handleOut) {
+handleOut[i] = (GLhandleARB) shProg->Shaders[i]->Name;
+ }
+  }
+  if (countOut) {
+ *countOut = i;
   }
-  if (count)
- *count = i;
}
 }
 
-
 /**
  * glGetHandleARB() - return ID/name of currently bound shader program.
  */
@@ -1575,7 +1583,7 @@ _mesa_GetAttachedObjectsARB(GLhandleARB container, 
GLsizei maxCount,
 GLsizei * count, GLhandleARB * obj)
 {
GET_CURRENT_CONTEXT(ctx);
-   get_attached_shaders(ctx, container, maxCount, count, obj);
+   get_attached_shaders(ctx, (GLuint)container, maxCount, count, NULL, obj);
 }
 
 
@@ -1584,7 +1592,7 @@ _mesa_GetAttachedShaders(GLuint program, GLsizei maxCount,
  GLsizei *count, GLuint *obj)
 {
GET_CURRENT_CONTEXT(ctx);
-   get_attached_shaders(ctx, program, maxCount, count, obj);
+   get_attached_shaders(ctx, program, maxCount, count, obj, NULL);
 }
 
 
-- 
2.13.3

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] docs/releasing: added relevant people for build/check with MacOSX

[Jeremy Huddleston Sequoia]

That should be fine.  If nothing else, I can help route questions to 
appropriate folks. =)

Reviewed-by: Jeremy Sequoia <jerem...@apple.com>

> On Apr 18, 2017, at 02:34, Andres Gomez <ago...@igalia.com> wrote:
> 
> Jeremy, is it OK that I mention you as a reference for MacOSX in the
> releasing doc?
> 
> On Mon, 2017-03-27 at 21:48 +0300, Andres Gomez wrote:
>> Signed-off-by: Andres Gomez <ago...@igalia.com>
>> Cc: Emil Velikov <emil.veli...@collabora.com>
>> Cc: Jeremy Huddleston Sequoia <jerem...@apple.com>
>> ---
>> docs/releasing.html | 5 +
>> 1 file changed, 5 insertions(+)
>> 
>> diff --git a/docs/releasing.html b/docs/releasing.html
>> index 0c78b0500d9..e41605b2116 100644
>> --- a/docs/releasing.html
>> +++ b/docs/releasing.html
>> @@ -143,6 +143,11 @@ and Mauro Rossi, currently.
>> 
>> 
>> 
>> +For MacOSX related changes, Jeremy Huddleston Sequoia is currently a
>> +good contact point.
>> +
>> +
>> +
>> Note: If a patch in the current queue needs any additional
>> fix(es), then they should be squashed together.
>> 
> -- 
> Br,
> 
> Andres



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 11/19] glx/apple: automake: include builddir prior to srcdir

[Jeremy Huddleston Sequoia]

LGTM

Reviewed-by: Jeremy Sequoia <jerem...@apple.com>

> On Jan 16, 2017, at 07:45, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> 
> From: Emil Velikov <emil.veli...@collabora.com>
> 
> Analogous to previous commit.
> 
> Cc: "12.0 13.0" <mesa-dev@lists.freedesktop.org>
> Cc: Jeremy Huddleston Sequoia <jerem...@apple.com>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
> ---
> src/glx/apple/Makefile.am | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/glx/apple/Makefile.am b/src/glx/apple/Makefile.am
> index 2cbff9ea90..ca74aa7b99 100644
> --- a/src/glx/apple/Makefile.am
> +++ b/src/glx/apple/Makefile.am
> @@ -6,11 +6,11 @@ AM_CFLAGS = \
>   -I$(top_srcdir)/src \
>   -I$(top_srcdir)/include \
>   -I$(top_srcdir)/src/glx \
> - -I$(top_srcdir)/src/mesa \
>   -I$(top_builddir)/src/mesa \
> + -I$(top_srcdir)/src/mesa \
>   -I$(top_srcdir)/src/mapi \
> - -I$(top_srcdir)/src/mapi/glapi \
>   -I$(top_builddir)/src/mapi/glapi \
> + -I$(top_srcdir)/src/mapi/glapi \
>   $(VISIBILITY_CFLAGS) \
>   $(SHARED_GLAPI_CFLAGS) \
>   $(DEFINES) \
> -- 
> 2.11.0
> 



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] glx: unify GLX_SGIX_pbuffer aliased declarations

[Jeremy Huddleston Sequoia]

> On Dec 6, 2016, at 06:04, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> 
> On 5 December 2016 at 22:50, Jeremy Huddleston Sequoia
> <jerem...@apple.com> wrote:
>> 
>>> On Dec 5, 2016, at 11:52 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
>>> 
>>> From: Emil Velikov <emil.veli...@collabora.com>
>>> 
>>> No point in having an identical code in two places.
>>> 
>>> Not to mention that the Apple one incorrectly uses GLXDrawable as pbuf
>>> type. This change is both API and ABI safe since the header uses the
>>> correct GLXPbufferSGIX and both types are a typedef of the same
>>> primitive XID.
>>> 
>>> Cc: Jeremy Huddleston Sequoia <jerem...@apple.com>
>>> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>
>> 
>> Reviewed-by: Jeremy Sequoia <jerem...@apple.com>
>> (not tested yet, though)
>> 
> Thanks.
> 
>>> ---
>>> Jeremy, humble poke to send any/all Macports patches to the list ;-)
>> 
>> What patches are you referring to?  AFAIK, all the patches we have in 
>> MacPorts are hacks that have been rejected by mesa or are things I don't 
>> think should be in mesa due to lack of polish/hack status.  See:
>>https://github.com/macports/macports-ports/tree/master/x11/mesa/files
>> 
> Almost, but not quite ;-)
> 
> - 0001-mesa-Deal-with-size-differences-between-GLuint-and-G.patch
> Should not longer be needed with the BUILDING_MESA workaround.

Thanks, I'll give that a try.

> - 0002-applegl-Provide-requirements-of-_SET_DrawBuffers.patch
> Some serious work needed.

Yep.  That's why I haven't resent it.  Need time to make it better.

> - 0003-glext.h-Add-missing-include-of-stddef.h-for-ptrdiff_.patch
> Should not be needed since the header is included further up in the
> file. Alternatively poke Khronos and upstream it.

Yep, that was the result of the conversation on the list.  I filed a khronos 
bug and don't think they've acted on it.  I'll check the status when I get some 
time.

> - no-missing-prototypes-error.patch
> No traces of it on the list and no commit message describing why it's
> needed :'-(

https://trac.macports.org/ticket/46827

IMO, this is a hack and doesn't meet the bar of upstreaming at this quality 
level as it's not a real fix.

> - patch-include-GL-mesa_glinterop_h.diff
> No longer needed - fixed upstream

Thanks.  I'll test removing it when I get a chance.

> - static-strndup.patch
> We have WIN32(?) strndup in src/util/strndup.[ch]. Static inline into
> include/posix_string.h alongside strnlen. Or better yet add a patch
> for the build toolchain, thus one doesn't need to fix these in every
> project ;-)

Yeah, that's why I haven't upstreamed this.  It's not the correct fix.

The build toolchain can't be patched.  It is the gcc-4.2 that shipped with 
Xcode 3 about 10 years ago.  We try to support the Apple-provided toolchain for 
building ports for as long as possible.  When it becomes too unwieldy, we 
blacklist it in individual ports.  That causes a newer toolchain to be used (my 
preferred ones being clang-3.4 or clang-3.7; clang-3.8 has some bad codegen 
issues, so I don't trust it, and 3.9+ currently don't build on Snow Leopard).

> Thanks
> Emil



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 7/7] glx: unify GLX_SGIX_pbuffer aliased declarations

[Jeremy Huddleston Sequoia]

> On Dec 5, 2016, at 11:52 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> 
> From: Emil Velikov <emil.veli...@collabora.com>
> 
> No point in having an identical code in two places.
> 
> Not to mention that the Apple one incorrectly uses GLXDrawable as pbuf
> type. This change is both API and ABI safe since the header uses the
> correct GLXPbufferSGIX and both types are a typedef of the same
> primitive XID.
> 
> Cc: Jeremy Huddleston Sequoia <jerem...@apple.com>
> Signed-off-by: Emil Velikov <emil.veli...@collabora.com>

Reviewed-by: Jeremy Sequoia <jerem...@apple.com>
(not tested yet, though)

> ---
> Jeremy, humble poke to send any/all Macports patches to the list ;-)

What patches are you referring to?  AFAIK, all the patches we have in MacPorts 
are hacks that have been rejected by mesa or are things I don't think should be 
in mesa due to lack of polish/hack status.  See:
https://github.com/macports/macports-ports/tree/master/x11/mesa/files

> ---
> src/glx/apple/glx_empty.c | 16 
> src/glx/glx_pbuffer.c |  2 --
> 2 files changed, 18 deletions(-)
> 
> diff --git a/src/glx/apple/glx_empty.c b/src/glx/apple/glx_empty.c
> index 1e9593c..33fffb5 100644
> --- a/src/glx/apple/glx_empty.c
> +++ b/src/glx/apple/glx_empty.c
> @@ -263,19 +263,3 @@ glXGetFBConfigFromVisualSGIX(Display * dpy, XVisualInfo 
> * visinfo)
>return NULL;
> }
> #endif
> -
> -
> -_X_EXPORT
> -GLX_ALIAS_VOID(glXDestroyGLXPbufferSGIX,
> -   (Display * dpy, GLXDrawable pbuf),
> -   (dpy, pbuf), glXDestroyPbuffer)
> -
> - _X_EXPORT GLX_ALIAS_VOID(glXSelectEventSGIX,
> -   (Display * dpy, GLXDrawable drawable,
> -unsigned long mask), (dpy, drawable, mask),
> -   glXSelectEvent)
> -
> - _X_EXPORT GLX_ALIAS_VOID(glXGetSelectedEventSGIX,
> -   (Display * dpy, GLXDrawable drawable,
> -unsigned long *mask), (dpy, drawable, mask),
> -   glXGetSelectedEvent)
> diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
> index 24c073c..0c15d2a 100644
> --- a/src/glx/glx_pbuffer.c
> +++ b/src/glx/glx_pbuffer.c
> @@ -992,7 +992,6 @@ glXDestroyWindow(Display * dpy, GLXWindow win)
> #endif
> }
> 
> -#ifndef GLX_USE_APPLEGL
> _GLX_PUBLIC
> GLX_ALIAS_VOID(glXDestroyGLXPbufferSGIX,
>(Display * dpy, GLXPbufferSGIX pbuf),
> @@ -1008,4 +1007,3 @@ GLX_ALIAS_VOID(glXGetSelectedEventSGIX,
>(Display * dpy, GLXDrawable drawable,
> unsigned long *mask), (dpy, drawable, mask),
>glXGetSelectedEvent)
> -#endif
> -- 
> 2.10.2
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 2/2] glx: apple specific occurences of dummyContext check

[Jeremy Huddleston Sequoia]

> On Aug 12, 2016, at 05:11, Tapani Pälli <tapani.pa...@intel.com> wrote:
> 
> 
> 
> On 08/12/2016 01:31 PM, Jeremy Huddleston Sequoia wrote:
>> 
>>> On Aug 12, 2016, at 00:41, Tapani Pälli <tapani.pa...@intel.com> 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 days.
>>> 
>>> a couple days passed, ping! :)
>> 
>> Sorry.
>> 
>> Go ahead and land it, and if there's fallout, I'll deal with it later.
> 
> r-b?

Yep, thanks.

Reviewed-by: Jeremy Huddleston Sequoia <jerem...@apple.com>

> 
>> One suggestion that I have is to leave the check for gc != NULL in there to 
>> prevent a NULL deref if __glXGetCurrentContext() returns NULL (unless 
>> __glXGetCurrentContext() is also now annotated as __NonNull).
> 
> __glXGetCurrentContext() cannot return NULL, it'll always return dummyContext 
> or actual real context, this was the original purpose of the patchset, there 
> were cases where we checked for NULL but not dummyContext and never returned 
> error because of this.
> 
> 
> 
>> --Jeremy
>> 
>>> 
>>>> --Jeremy
>>>> 
>>>>> On Jul 18, 2016, at 01:12, Tapani Pälli <tapani.pa...@intel.com> wrote:
>>>>> 
>>>>> Jeremy, would you have time to test these changes? Patch 1 was already 
>>>>> reviewed by Emil.
>>>>> 
>>>>> // Tapani
>>>>> 
>>>>> 
>>>>> On 06/07/2016 01:33 PM, Tapani Pälli wrote:
>>>>>> Signed-off-by: Tapani Pälli <tapani.pa...@intel.com>
>>>>>> Cc: Jeremy Huddleston Sequoia <jerem...@apple.com>
>>>>>> ---
>>>>>> src/glx/apple/apple_xgl_api_stereo.c   | 4 ++--
>>>>>> src/glx/apple/apple_xgl_api_viewport.c | 2 +-
>>>>>> src/glx/glxcmds.c  | 2 +-
>>>>>> 3 files changed, 4 insertions(+), 4 deletions(-)
>>>>>> 
>>>>>> diff --git a/src/glx/apple/apple_xgl_api_stereo.c 
>>>>>> b/src/glx/apple/apple_xgl_api_stereo.c
>>>>>> index 4b21aaf..0d2f6fa 100644
>>>>>> --- a/src/glx/apple/apple_xgl_api_stereo.c
>>>>>> +++ b/src/glx/apple/apple_xgl_api_stereo.c
>>>>>> @@ -54,7 +54,7 @@ __applegl_glDrawBuffer(GLenum mode)
>>>>>> {
>>>>>>  struct glx_context * gc = __glXGetCurrentContext();
>>>>>> 
>>>>>> -   if (gc && apple_glx_context_uses_stereo(gc->driContext)) {
>>>>>> +   if (gc !=  && 
>>>>>> apple_glx_context_uses_stereo(gc->driContext)) {
>>>>>> GLenum buf[2];
>>>>>> GLsizei n = 0;
>>>>>> 
>>>>>> @@ -89,7 +89,7 @@ __applegl_glDrawBuffers(GLsizei n, const GLenum * bufs)
>>>>>> {
>>>>>>  struct glx_context * gc = __glXGetCurrentContext();
>>>>>> 
>>>>>> -   if (gc && apple_glx_context_uses_stereo(gc->driContext)) {
>>>>>> +   if (gc !=  && 
>>>>>> apple_glx_context_uses_stereo(gc->driContext)) {
>>>>>> GLenum newbuf[n + 2];
>>>>>> GLsizei i, outi = 0;
>>>>>> bool have_back = false;
>>>>>> diff --git a/src/glx/apple/apple_xgl_api_viewport.c 
>>>>>> b/src/glx/apple/apple_xgl_api_viewport.c
>>>>>> index 281c90c..c40061d 100644
>>>>>> --- a/src/glx/apple/apple_xgl_api_viewport.c
>>>>>> +++ b/src/glx/apple/apple_xgl_api_viewport.c
>>>>>> @@ -41,7 +41,7 @@ __applegl_glViewport(GLint x, GLint y, GLsizei width, 
>>>>>> GLsizei height)
>>>>>>  struct glx_context *gc = __glXGetCurrentContext();
>>>>>>  Display *dpy = glXGetCurrentDisplay();
>>>>>> 
>>>>>> -   if (gc && gc->driContext)
>>>>>> +   if (gc !=  && gc->driContext)
>>>>>> apple_glx_context_update(dpy, gc->driContext);
>>>>>> 
>>>>>>  __ogl_framework_api->Viewport(x, y, width, height);
>>>>>> diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
>>>>>> index 2420fef..5dce982 100644
>>>>>> --- a/src/glx/glxcmds.c
>>>>>> +++ b/src/glx/glxcmds.c
>>>>>> @@ -820,7 +820,7 @@ glXSwapBuffers(Display * dpy, GLXDrawable drawable)
>>>>>> {
>>>>>> #ifdef GLX_USE_APPLEGL
>>>>>>  struct glx_context * gc = __glXGetCurrentContext();
>>>>>> -   if(gc && apple_glx_is_current_drawable(dpy, gc->driContext, 
>>>>>> drawable)) {
>>>>>> +   if(gc !=  && apple_glx_is_current_drawable(dpy, 
>>>>>> gc->driContext, drawable)) {
>>>>>> apple_glx_swap_buffers(gc->driContext);
>>>>>>  } else {
>>>>>> __glXSendError(dpy, GLXBadCurrentWindow, 0, X_GLXSwapBuffers, false);
>>>>>> 
>>>> 
>> 



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 2/2] glx: apple specific occurences of dummyContext check

[Jeremy Huddleston Sequoia]

> On Aug 12, 2016, at 00:41, Tapani Pälli <tapani.pa...@intel.com> 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 days.
> 
> a couple days passed, ping! :)

Sorry.

Go ahead and land it, and if there's fallout, I'll deal with it later.

One suggestion that I have is to leave the check for gc != NULL in there to 
prevent a NULL deref if __glXGetCurrentContext() returns NULL (unless 
__glXGetCurrentContext() is also now annotated as __NonNull).

--Jeremy

> 
>> --Jeremy
>> 
>>> On Jul 18, 2016, at 01:12, Tapani Pälli <tapani.pa...@intel.com> wrote:
>>> 
>>> Jeremy, would you have time to test these changes? Patch 1 was already 
>>> reviewed by Emil.
>>> 
>>> // Tapani
>>> 
>>> 
>>> On 06/07/2016 01:33 PM, Tapani Pälli wrote:
>>>> Signed-off-by: Tapani Pälli <tapani.pa...@intel.com>
>>>> Cc: Jeremy Huddleston Sequoia <jerem...@apple.com>
>>>> ---
>>>> src/glx/apple/apple_xgl_api_stereo.c   | 4 ++--
>>>> src/glx/apple/apple_xgl_api_viewport.c | 2 +-
>>>> src/glx/glxcmds.c  | 2 +-
>>>> 3 files changed, 4 insertions(+), 4 deletions(-)
>>>> 
>>>> diff --git a/src/glx/apple/apple_xgl_api_stereo.c 
>>>> b/src/glx/apple/apple_xgl_api_stereo.c
>>>> index 4b21aaf..0d2f6fa 100644
>>>> --- a/src/glx/apple/apple_xgl_api_stereo.c
>>>> +++ b/src/glx/apple/apple_xgl_api_stereo.c
>>>> @@ -54,7 +54,7 @@ __applegl_glDrawBuffer(GLenum mode)
>>>> {
>>>>   struct glx_context * gc = __glXGetCurrentContext();
>>>> 
>>>> -   if (gc && apple_glx_context_uses_stereo(gc->driContext)) {
>>>> +   if (gc !=  && 
>>>> apple_glx_context_uses_stereo(gc->driContext)) {
>>>>  GLenum buf[2];
>>>>  GLsizei n = 0;
>>>> 
>>>> @@ -89,7 +89,7 @@ __applegl_glDrawBuffers(GLsizei n, const GLenum * bufs)
>>>> {
>>>>   struct glx_context * gc = __glXGetCurrentContext();
>>>> 
>>>> -   if (gc && apple_glx_context_uses_stereo(gc->driContext)) {
>>>> +   if (gc !=  && 
>>>> apple_glx_context_uses_stereo(gc->driContext)) {
>>>>  GLenum newbuf[n + 2];
>>>>  GLsizei i, outi = 0;
>>>>  bool have_back = false;
>>>> diff --git a/src/glx/apple/apple_xgl_api_viewport.c 
>>>> b/src/glx/apple/apple_xgl_api_viewport.c
>>>> index 281c90c..c40061d 100644
>>>> --- a/src/glx/apple/apple_xgl_api_viewport.c
>>>> +++ b/src/glx/apple/apple_xgl_api_viewport.c
>>>> @@ -41,7 +41,7 @@ __applegl_glViewport(GLint x, GLint y, GLsizei width, 
>>>> GLsizei height)
>>>>   struct glx_context *gc = __glXGetCurrentContext();
>>>>   Display *dpy = glXGetCurrentDisplay();
>>>> 
>>>> -   if (gc && gc->driContext)
>>>> +   if (gc !=  && gc->driContext)
>>>>  apple_glx_context_update(dpy, gc->driContext);
>>>> 
>>>>   __ogl_framework_api->Viewport(x, y, width, height);
>>>> diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
>>>> index 2420fef..5dce982 100644
>>>> --- a/src/glx/glxcmds.c
>>>> +++ b/src/glx/glxcmds.c
>>>> @@ -820,7 +820,7 @@ glXSwapBuffers(Display * dpy, GLXDrawable drawable)
>>>> {
>>>> #ifdef GLX_USE_APPLEGL
>>>>   struct glx_context * gc = __glXGetCurrentContext();
>>>> -   if(gc && apple_glx_is_current_drawable(dpy, gc->driContext, drawable)) 
>>>> {
>>>> +   if(gc !=  && apple_glx_is_current_drawable(dpy, 
>>>> gc->driContext, drawable)) {
>>>>  apple_glx_swap_buffers(gc->driContext);
>>>>   } else {
>>>>  __glXSendError(dpy, GLXBadCurrentWindow, 0, X_GLXSwapBuffers, false);
>>>> 
>> 



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v4 2/2] glx: apple specific occurences of dummyContext check

[Jeremy Huddleston Sequoia]

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 days.

--Jeremy

> On Jul 18, 2016, at 01:12, Tapani Pälli <tapani.pa...@intel.com> wrote:
> 
> Jeremy, would you have time to test these changes? Patch 1 was already 
> reviewed by Emil.
> 
> // Tapani
> 
> 
> On 06/07/2016 01:33 PM, Tapani Pälli wrote:
>> Signed-off-by: Tapani Pälli <tapani.pa...@intel.com>
>> Cc: Jeremy Huddleston Sequoia <jerem...@apple.com>
>> ---
>> src/glx/apple/apple_xgl_api_stereo.c   | 4 ++--
>> src/glx/apple/apple_xgl_api_viewport.c | 2 +-
>> src/glx/glxcmds.c  | 2 +-
>> 3 files changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/src/glx/apple/apple_xgl_api_stereo.c 
>> b/src/glx/apple/apple_xgl_api_stereo.c
>> index 4b21aaf..0d2f6fa 100644
>> --- a/src/glx/apple/apple_xgl_api_stereo.c
>> +++ b/src/glx/apple/apple_xgl_api_stereo.c
>> @@ -54,7 +54,7 @@ __applegl_glDrawBuffer(GLenum mode)
>> {
>>struct glx_context * gc = __glXGetCurrentContext();
>> 
>> -   if (gc && apple_glx_context_uses_stereo(gc->driContext)) {
>> +   if (gc !=  && 
>> apple_glx_context_uses_stereo(gc->driContext)) {
>>   GLenum buf[2];
>>   GLsizei n = 0;
>> 
>> @@ -89,7 +89,7 @@ __applegl_glDrawBuffers(GLsizei n, const GLenum * bufs)
>> {
>>struct glx_context * gc = __glXGetCurrentContext();
>> 
>> -   if (gc && apple_glx_context_uses_stereo(gc->driContext)) {
>> +   if (gc !=  && 
>> apple_glx_context_uses_stereo(gc->driContext)) {
>>   GLenum newbuf[n + 2];
>>   GLsizei i, outi = 0;
>>   bool have_back = false;
>> diff --git a/src/glx/apple/apple_xgl_api_viewport.c 
>> b/src/glx/apple/apple_xgl_api_viewport.c
>> index 281c90c..c40061d 100644
>> --- a/src/glx/apple/apple_xgl_api_viewport.c
>> +++ b/src/glx/apple/apple_xgl_api_viewport.c
>> @@ -41,7 +41,7 @@ __applegl_glViewport(GLint x, GLint y, GLsizei width, 
>> GLsizei height)
>>struct glx_context *gc = __glXGetCurrentContext();
>>Display *dpy = glXGetCurrentDisplay();
>> 
>> -   if (gc && gc->driContext)
>> +   if (gc !=  && gc->driContext)
>>   apple_glx_context_update(dpy, gc->driContext);
>> 
>>__ogl_framework_api->Viewport(x, y, width, height);
>> diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
>> index 2420fef..5dce982 100644
>> --- a/src/glx/glxcmds.c
>> +++ b/src/glx/glxcmds.c
>> @@ -820,7 +820,7 @@ glXSwapBuffers(Display * dpy, GLXDrawable drawable)
>> {
>> #ifdef GLX_USE_APPLEGL
>>struct glx_context * gc = __glXGetCurrentContext();
>> -   if(gc && apple_glx_is_current_drawable(dpy, gc->driContext, drawable)) {
>> +   if(gc !=  && apple_glx_is_current_drawable(dpy, 
>> gc->driContext, drawable)) {
>>   apple_glx_swap_buffers(gc->driContext);
>>} else {
>>   __glXSendError(dpy, GLXBadCurrentWindow, 0, X_GLXSwapBuffers, false);
>> 



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH v2] glx: fix crash with bad fbconfig

[Jeremy Huddleston Sequoia]

> 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
>> 
>> Function checks if the given config is a valid config and sets proper
>> error code.
>> 
>> Fixes currently crashing glx-fbconfig-bad Piglit test.
>> 
>> v2: coding style cleanups (Emil, Topi)
>>use DefaultScreen macro (Emil)
>> 
> Thanks for the update Topi. There is one question/suggestion for
> future work inline. But as is the patch is
> Reviewed-by: Emil Velikov 
> 
> 
>> +   config_list = (struct glx_config **)
>> +  glXGetFBConfigs(dpy, screen, _size);
>> +
> Not 100% sure if we could/should reference the external symbols from
> within our implementation. I cannot give you concrete reason, yet with
> GLVND around the corner my gut isn't giving me a good feeling about
> this.
> 
> We have a similar case in glXCreateWindow (using
> glXGetVisualFromFBConfig for the GLX_APPLEGL path) and
> __glXGLVNDGetProcAddress(glXGetProcAddressARB).
> 
> Perhaps it's worth renaming those symbols (prefix with __) and using
> GLX_ALIAS ? Speaking of which...
> 
> Jeremy is __attribute__  alias working with Darwin ?

No, __attribute__((alias)) is not supported:

~ $ cat testalias.c 
int one = 1;
extern int anotherone __attribute__((alias("one")));

~ $ clang -c testalias.c 
testalias.c:2:38: error: only weak aliases are supported on darwin
extern int anotherone __attribute__((alias("one")));
 ^
1 error generated.

But there are options.  The main way that we accomplish this on darwin is by 
passing the list of aliases to the linker:

 -alias symbol_name alternate_symbol_name
 Create an alias named alternate_symbol_name for the symbol 
symbol_name.  By
 default the alias symbol has global visibility.  This option 
was previous the
 -idef:indir option.

 -alias_list filename
 The specified filename contains a list of aliases. The symbol 
name and its
 alias are on one line, separated by whitespace.  Lines 
starting with # are
 ignored.

However, it would be best to not have to maintain these data in two separate 
places for different toolchains.  Having this at the source code level next to 
the prototype or implementation is the most ideal option.  There are two source 
level ways to go: asm assignment and resolvers.  Resolvers only work for 
functions, and the asm path seems to fit in most cleanly with GLX_ALIAS, but I 
list examples of both here for completeness:

#if defined __APPLE__
#define ALIAS_HAX(name, aliasname) \
  asm(".text\n\t.globl _" # aliasname "\n\t_" # aliasname " = _" # name);
#else
#define ALIAS_HAX(name, aliasname) \
  extern __typeof (name) aliasname __attribute__ ((alias (#name)));
#endif

int one = 1;
int two(void) {
return 2;
}

ALIAS_HAX(one, anotherone)
ALIAS_HAX(two, anothertwo)

---

GLAPI void GLAPIENTRY glBegin( GLenum mode );
GLAPI void GLAPIENTRY glBeginRenamed( GLenum mode );

void * glBegin_resolver(void) __asm__("_glBeginRenamed");
void * glBegin_resolver(void) {
__asm__(".symbol_resolver _glBeginRenamed");
return 
}

> If so can we drop
> the GLX_ALIAS_UNSUPPORTED define (automake and scons builds) and
> cleanup the ifdef spaghetti in src/glx/{glxcmds.c,glxextensions.h}.
> Just looking for an ack/nack on the idea :-)

I'm always in favor of cleaning up ifdef spaghetti, so you definitely have my 
ack!

> 
> Thanks
> Emil



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: Deal with size differences between GLuint and GLhandleARB in GetAttachedObjectsARB

[Jeremy Huddleston Sequoia]

Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
CC: Nicolai Hähnle <nhaeh...@gmail.com>
CC: Matt Turner <matts...@gmail.com>
CC: Ian Romanick <i...@freedesktop.org>
---
 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..0b630eb 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -476,6 +476,30 @@ get_attached_shaders(struct gl_context *ctx, GLuint 
program, GLsizei maxCount,
}
 }
 
+static void
+get_attached_shadersARB(struct gl_context *ctx, GLhandleARB container, GLsizei 
maxCount,
+GLsizei *count, GLhandleARB *obj)
+{
+   struct gl_shader_program *shProg;
+
+   if (maxCount < 0) {
+  _mesa_error(ctx, GL_INVALID_VALUE, "glGetAttachedShadersARB(maxCount < 
0)");
+  return;
+   }
+
+   shProg =
+  _mesa_lookup_shader_program_err(ctx, (GLuint)container, 
"glGetAttachedShaders");
+
+   if (shProg) {
+  GLuint i;
+  for (i = 0; i < (GLuint) maxCount && i < shProg->NumShaders; i++) {
+ obj[i] = (GLhandleARB)shProg->Shaders[i]->Name;
+  }
+  if (count)
+ *count = i;
+   }
+}
+
 
 /**
  * glGetHandleARB() - return ID/name of currently bound shader program.
@@ -1371,7 +1395,7 @@ _mesa_GetAttachedObjectsARB(GLhandleARB container, 
GLsizei maxCount,
 GLsizei * count, GLhandleARB * obj)
 {
GET_CURRENT_CONTEXT(ctx);
-   get_attached_shaders(ctx, container, maxCount, count, obj);
+   get_attached_shadersARB(ctx, container, maxCount, count, obj);
 }
 
 
-- 
2.8.2

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] mesa: Deal with size differences between GLuint and GLhandleARB in GetAttachedObjectsARB

[Jeremy Huddleston Sequoia]

> On Jan 21, 2016, at 07:51, Nicolai Hähnle <nhaeh...@gmail.com> 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 <jerem...@apple.com>
>> ---
>>  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/shaderapi.c
>> @@ -1374,10 +1374,20 @@ _mesa_DetachShader(GLuint program, GLuint shader)
>> 
>>  void GLAPIENTRY
>>  _mesa_GetAttachedObjectsARB(GLhandleARB container, GLsizei maxCount,
>> -GLsizei * count, GLhandleARB * obj)
>> +GLsizei * count, GLhandleARB * objARB)
>>  {
>> +   int i;
>> +   GLuint *obj = calloc(maxCount, sizeof(GLuint));
>> +   assert(obj);
>> +
> 
> Is there a precedent for using assert in this way? It feels wrong to me, 
> better set GL_OUT_OF_MEMORY.

Yes, I was just following behavior from elsewhere in the same source file.  In 
read_shader(), we have:
   buffer = malloc(shader_size);
   assert(buffer);

I'm happy to change that to the following if you think it more appropriate:

GLuint *obj;
GET_CURRENT_CONTEXT(ctx);

obj = calloc(maxCount, sizeof(GLuint));
if (!obj) {
_mesa_error(ctx, GL_OUT_OF_MEMORY, "glShaderSourceARB");
return;
}
...

> 
>> GET_CURRENT_CONTEXT(ctx);
>> get_attached_shaders(ctx, container, maxCount, count, obj);
>> +
>> +   for (i=0 ; i < *count; i++) {
>> +  objARB[i] = (GLhandleARB)obj[i];
> 
> Since this can only ever be a widening of the type, you don't really need the 
> cast here.

True.

> 
> Nicolai
> 
>> +   }
>> +
>> +   free(obj);
>>  }
>> 
>> 
>> 



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v2] mesa: Deal with size differences between GLuint and GLhandleARB in GetAttachedObjectsARB

[Jeremy Huddleston Sequoia]

Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
CC: Nicolai Hähnle <nhaeh...@gmail.com>
CC: Matt Turner <matts...@gmail.com>
---
 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/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1374,10 +1374,26 @@ _mesa_DetachShader(GLuint program, GLuint shader)
 
 void GLAPIENTRY
 _mesa_GetAttachedObjectsARB(GLhandleARB container, GLsizei maxCount,
-GLsizei * count, GLhandleARB * obj)
+GLsizei * count, GLhandleARB * objARB)
 {
+   int i;
+   GLuint *obj;
+
GET_CURRENT_CONTEXT(ctx);
+
+   obj = calloc(maxCount, sizeof(GLuint));
+   if (!obj) {
+  _mesa_error(ctx, GL_OUT_OF_MEMORY, "glShaderSourceARB");
+  return;
+   }
+
get_attached_shaders(ctx, container, maxCount, count, obj);
+
+   for (i = 0 ; i < *count; i++) {
+  objARB[i] = (GLhandleARB)obj[i];
+   }
+
+   free(obj);
 }
 
 
-- 
2.7.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/3] Misc GLhandleARB GLuint cleanup

[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.  The last adds 
a bit of overhead to mesa_GetAttachedObjectsARB because we need to walk the 
returned array of GLuint and copy into the array of GLhandleARB.  I expect this 
last one will be a bit unwelcome on platforms where these two types are the 
same.

Would it be best to have a configure check for this and use it here (and maybe 
elsewhere in the future), or would you prefer to just use a platform 
preprocessing check for this since I suspect darwin is (and will only ever be) 
the only impacted platform.

--Jeremy



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/3] mesa: Fix format warnings

[Jeremy Huddleston Sequoia]

main/shaderapi.c:1318:51: warning: format specifies type 'unsigned int' but the 
argument has type 'GLhandleARB' (aka 'unsigned long') [-Wformat]
  _mesa_debug(ctx, "glDeleteObjectARB(%u)\n", obj);
  ~~  ^~~
  %lu

Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
---
 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/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1315,7 +1315,7 @@ _mesa_DeleteObjectARB(GLhandleARB obj)
 {
if (MESA_VERBOSE & VERBOSE_API) {
   GET_CURRENT_CONTEXT(ctx);
-  _mesa_debug(ctx, "glDeleteObjectARB(%u)\n", obj);
+  _mesa_debug(ctx, "glDeleteObjectARB(%lu)\n", (unsigned long)obj);
}
 
if (obj) {
-- 
2.7.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] mesa: Deal with size differences between GLuint and GLhandleARB in GetAttachedObjectsARB

[Jeremy Huddleston Sequoia]

Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
---
 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/shaderapi.c
@@ -1374,10 +1374,20 @@ _mesa_DetachShader(GLuint program, GLuint shader)
 
 void GLAPIENTRY
 _mesa_GetAttachedObjectsARB(GLhandleARB container, GLsizei maxCount,
-GLsizei * count, GLhandleARB * obj)
+GLsizei * count, GLhandleARB * objARB)
 {
+   int i;
+   GLuint *obj = calloc(maxCount, sizeof(GLuint));
+   assert(obj);
+
GET_CURRENT_CONTEXT(ctx);
get_attached_shaders(ctx, container, maxCount, count, obj);
+
+   for (i=0 ; i < *count; i++) {
+  objARB[i] = (GLhandleARB)obj[i];
+   }
+
+   free(obj);
 }
 
 
-- 
2.7.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/3] mesa: Fix some function prototype mismatching

[Jeremy Huddleston Sequoia]

 *)) {

 ^
main/api_exec.c:653:28: warning: 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(exec, _mesa_UseProgram);
   ^~~~
./main/dispatch.h:8173:80: note: passing argument to parameter 'fn' here
static inline void SET_UseProgram(struct _glapi_table *disp, void (GLAPIENTRYP 
fn)(GLuint)) {
   ^
main/api_exec.c:655:33: warning: incompatible pointer types passing 'void 
(GLhandleARB)' (aka 'void (unsigned long)') to parameter of type 'void 
(*)(GLuint)' (aka 'void (*)(unsigned
int)')
  [-Wincompatible-pointer-types]
  SET_ValidateProgram(exec, _mesa_ValidateProgram);
^
./main/dispatch.h:8184:85: note: passing argument to parameter 'fn' here
static inline void SET_ValidateProgram(struct _glapi_table *disp, void 
(GLAPIENTRYP fn)(GLuint)) {

main/dlist.c:9457:26: warning: 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);
 ^~~~
./main/dispatch.h:8173:80: note: passing argument to parameter 'fn' here
static inline void SET_UseProgram(struct _glapi_table *disp, void (GLAPIENTRYP 
fn)(GLuint)) {
   ^
1 warning generated.

Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
---
 src/mesa/main/dlist.c  |  5 ++---
 src/mesa/main/shader_query.cpp | 12 ++--
 src/mesa/main/shaderapi.c  | 16 
 src/mesa/main/shaderapi.h  | 20 ++--
 4 files changed, 26 insertions(+), 27 deletions(-)

diff --git a/src/mesa/main/dlist.c b/src/mesa/main/dlist.c
index ba2e670..cd8e3b6 100644
--- a/src/mesa/main/dlist.c
+++ b/src/mesa/main/dlist.c
@@ -5982,9 +5982,8 @@ save_DrawTransformFeedbackStreamInstanced(GLenum mode, 
GLuint name,
}
 }
 
-/* aka UseProgram() */
 static void GLAPIENTRY
-save_UseProgramObjectARB(GLhandleARB program)
+save_UseProgram(GLuint program)
 {
GET_CURRENT_CONTEXT(ctx);
Node *n;
@@ -9454,7 +9453,7 @@ _mesa_initialize_save_table(const struct gl_context *ctx)
 
SET_BlitFramebuffer(table, save_BlitFramebufferEXT);
 
-   SET_UseProgram(table, save_UseProgramObjectARB);
+   SET_UseProgram(table, save_UseProgram);
SET_Uniform1f(table, save_Uniform1fARB);
SET_Uniform2f(table, save_Uniform2fARB);
SET_Uniform3f(table, save_Uniform3fARB);
diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
index 9192f3e..d2827f7 100644
--- a/src/mesa/main/shader_query.cpp
+++ b/src/mesa/main/shader_query.cpp
@@ -64,8 +64,8 @@ DECL_RESOURCE_FUNC(XFB, gl_transform_feedback_varying_info);
 DECL_RESOURCE_FUNC(SUB, gl_subroutine_function);
 
 void GLAPIENTRY
-_mesa_BindAttribLocation(GLhandleARB program, GLuint index,
-const GLcharARB *name)
+_mesa_BindAttribLocation(GLuint program, GLuint index,
+ const GLchar *name)
 {
GET_CURRENT_CONTEXT(ctx);
 
@@ -126,9 +126,9 @@ is_active_attrib(const gl_shader_variable *var)
 }
 
 void GLAPIENTRY
-_mesa_GetActiveAttrib(GLhandleARB program, GLuint desired_index,
- GLsizei maxLength, GLsizei * length, GLint * size,
- GLenum * type, GLcharARB * name)
+_mesa_GetActiveAttrib(GLuint program, GLuint desired_index,
+  GLsizei maxLength, GLsizei * length, GLint * size,
+  GLenum * type, GLchar * name)
 {
GET_CURRENT_CONTEXT(ctx);
struct gl_shader_program *shProg;
@@ -191,7 +191,7 @@ _mesa_GetActiveAttrib(GLhandleARB program, GLuint 
desired_index,
 }
 
 GLint GLAPIENTRY
-_mesa_GetAttribLocation(GLhandleARB program, const GLcharARB * name)
+_mesa_GetAttribLocation(GLuint program, const GLchar * name)
 {
GET_CURRENT_CONTEXT(ctx);
struct gl_shader_program *const shProg =
diff --git a/src/mesa/main/shaderapi.c b/src/mesa/main/shaderapi.c
index 126786c..9512e3b 100644
--- a/src/mesa/main/shaderapi.c
+++ b/src/mesa/main/shaderapi.c
@@ -1265,7 +1265,7 @@ _mesa_AttachShader(GLuint program, GLuint shader)
 
 
 void GLAPIENTRY
-_mesa_CompileShader(GLhandleARB shaderObj)
+_mesa_CompileShader(GLuint shaderObj)
 {
GET_CURRENT_CONTEXT(ctx);
if (MESA_VERBOSE & VERBOSE_API)
@@ -1479,8 +1479,8 @@ _mesa_GetShaderInfoLog(GLuint shader, GLsizei bufSize,
 
 
 void GLAPIENTRY
-_mesa_GetShaderSource(GLhandleARB shader, GLsizei maxLength,
- GLsizei *length, GLcharARB *sourceOut)
+_mesa_GetShaderSource(GLuint shader, GLsizei

Re: [Mesa-dev] mesa: Reduce libGL.so binary size by about 15%

[Jeremy Huddleston Sequoia]

Sorry, I thought I responded to this a while ago.

Reviewed-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
Tested-by: Jeremy Huddleston Sequoia <jerem...@apple.com>

--Jeremy

> On Jan 19, 2016, at 05:21, Andreas Boll <andreas.boll@gmail.com> wrote:
> 
> Jeremy, did you have a chance to test this patch?
> This patch would be still useful for OS X. For non-OS X this patch [1]
> reduces the size of libGL.so further more.
> 
> Thanks,
> Andreas
> 
> [1] https://patchwork.freedesktop.org/patch/70372/
> 
> 2015-09-28 19:46 GMT+02:00 Jeremy Huddleston Sequoia <jerem...@apple.com>:
>> I'll give it a go.
>> 
>> It is still needed on OS X (and I think Windows).  It's just not used by the 
>> X server any more.
>> 
>> --Jeremy
>> 
>>> On Sep 28, 2015, at 10:26, Arlie Davis <arl...@google.com> wrote:
>>> 
>>> I tried building Mesa on OS X, but I'm not nearly as familiar with 
>>> development on OS X, so I wasn't able to get it to build.  If someone could 
>>> build / test that on OS X, it would certainly give more confidence in its 
>>> correctness.  I *think* the generated code is correct, but you know how 
>>> that is.
>>> 
>>> If there is no need for this on OS X any longer, then the best thing might 
>>> be to remove it entirely.
>>> 
>>> On Sat, Sep 26, 2015 at 5:56 PM, Jeremy Huddleston Sequoia 
>>> <jerem...@apple.com> 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?  
>>> If not, let me know, and I'll give it a whirl when I have some cycles.
>>> 
>>> Reviewed-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
>>> 
>>> ---
>>> 
>>> You're right that this used to be use in xserver as well, but that was 
>>> removed in:
>>> 
>>> commit e61e19959d9138d5b81b1f25b7aa3e257918170d
>>> Author: Adam Jackson <a...@redhat.com>
>>> Date:   Tue Dec 3 13:45:43 2013 -0500
>>> 
>>>xquartz/glx: Convert to non-glapi dispatch
>>> 
>>>CGL doesn't have anything like glXGetProcAddress, and the old code just
>>>called down to dlsym in any case.  It's a little mind-warping since
>>>dlopening a framework actually loads multiple dylibs, but that's just
>>>how OSX rolls.
>>> 
>>>Signed-off-by: Adam Jackson <a...@redhat.com>
>>>Reviewed-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
>>> 
>>> 
>>>> On Sep 22, 2015, at 15:55, Ian Romanick <i...@freedesktop.org> wrote:
>>>> 
>>>> On 09/17/2015 03:19 PM, Arlie Davis wrote:
>>>>> Ok, here's v2 of the change, with the suggested edits.
>>>> 
>>>> So... I think this code is fine, and I admire the effort.  I have a
>>>> couple concerns.
>>>> 
>>>> 1. We have no way to test this, so it's quite possible something was 
>>>> broken.
>>>> 
>>>> 2. This function is only used in the OSX builds.  Jeremy is the
>>>> maintainer for those builds, so I've added him to the CC list.
>>>> 
>>>> For every non-OSX build, we should just stop linking
>>>> src/mapi/glapi/glapi_gentable.c.  I thought maybe the X sever used it,
>>>> but I couldn't find any evidence of that.
>>>> 
>>>> If this is still a viable route, I have a few suggestions of follow-on
>>>> patches...
>>>> 
>>>> I guess this patch is
>>>> 
>>>> Reviewed-by: Ian Romanick <ian.d.roman...@intel.com>
>>>> 
>>>> but I really think we need to get Jeremy's approval before pushing it.
>>>> 
>>>>> From 5f393faa058f453408dfc640eecae3fe6335dfed Mon Sep 17 00:00:00 2001
>>>>> From: Arlie Davis <arl...@google.com>
>>>>> Date: Tue, 15 Sep 2015 09:58:34 -0700
>>>>> Subject: [PATCH] This patch significantly reduces the size of the libGL.so
>>>>> binary. It does not change the (externally visible) behavior of libGL.so 
>>>>> at
>>>>> all.
>>>>> 
>>>>> gl_gentable.py generates a function, _glapi_create_table_from_handle.
>>>>> This function allocates a large dispatch table, consisting of 1300 or so
>>>>> function pointers, and fills this dispatch table by doing symbol lookups
>>>>> on a given shared library. 

Re: [Mesa-dev] [RFC] glapi: Build gl_gentable.c only on Darwin

[Jeremy Huddleston Sequoia]

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, Andreas Boll  wrote:
>> Removes the public symbol _glapi_create_table_from_handle from
>> libGL.so.1 on all plattforms except Darwin.
>> 
> typo -> platforms
> 
>> Since the symbol is not used on other plattforms it makes sense to
> ditto
> 
>> build gl_gentable.c only on Darwin.
>> 
> Ideally we'll keep the dispatch as close to identical across all
> platforms (i.e. we'll nuke this), although for now this will do.
> 
> Out of curiosity is there any noticeable difference in the build times?
> 
> ...
>> XXX If we still want to distribute gl_gentable.c in the release tarball
>> we could drop the changes in src/mapi/glapi/gen/Makefile.am
>> 
> Yes please. We want to ship all the generated sources, regardless of
> the platform they're used.
> 
> ...
>> index 2da8f7d..25ea44a 100644
>> --- a/src/mapi/glapi/gen/Makefile.am
>> +++ b/src/mapi/glapi/gen/Makefile.am
>> @@ -27,8 +27,11 @@ MESA_GLAPI_OUTPUTS = \
>>$(MESA_GLAPI_DIR)/glapi_mapi_tmp.h \
>>$(MESA_GLAPI_DIR)/glprocs.h \
>>$(MESA_GLAPI_DIR)/glapitemp.h \
>> -   $(MESA_GLAPI_DIR)/glapitable.h \
>> -   $(MESA_GLAPI_DIR)/glapi_gentable.c
>> +   $(MESA_GLAPI_DIR)/glapitable.h
>> +
>> +if HAVE_APPLEDRI
>> +MESA_GLAPI_OUTPUTS += $(MESA_GLAPI_DIR)/glapi_gentable.c
>> +endif
>> 
>> MESA_GLAPI_ASM_OUTPUTS =
>> if HAVE_X86_ASM
>> @@ -88,8 +91,11 @@ XORG_GLAPI_DIR = $(XORG_BASE)/glx
>> XORG_GLAPI_OUTPUTS = \
>>$(XORG_GLAPI_DIR)/glprocs.h \
>>$(XORG_GLAPI_DIR)/glapitable.h \
>> -   $(XORG_GLAPI_DIR)/dispatch.h \
>> +   $(XORG_GLAPI_DIR)/dispatch.h
>> +
>> +if HAVE_APPLEDRI
>>$(XORG_GLAPI_DIR)/glapi_gentable.c
> Erm missing XORG_GLAPI_OUTPUTS += ?
> 
> Afaict even with the above makefile changes the file should still be
> in the in the tarball. Am I missing something ?
> 
> Would be great if Jeremy (or someone else) has the chance to test
> this, in case we've missing something.
> 
> -Emil



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mesa: Reduce libGL.so binary size by about 15%

[Jeremy Huddleston Sequoia]

I'll give it a go.

It is still needed on OS X (and I think Windows).  It's just not used by the X 
server any more.

--Jeremy

> On Sep 28, 2015, at 10:26, Arlie Davis <arl...@google.com> wrote:
> 
> I tried building Mesa on OS X, but I'm not nearly as familiar with 
> development on OS X, so I wasn't able to get it to build.  If someone could 
> build / test that on OS X, it would certainly give more confidence in its 
> correctness.  I *think* the generated code is correct, but you know how that 
> is.
> 
> If there is no need for this on OS X any longer, then the best thing might be 
> to remove it entirely.
> 
> On Sat, Sep 26, 2015 at 5:56 PM, Jeremy Huddleston Sequoia 
> <jerem...@apple.com> 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?  
> If not, let me know, and I'll give it a whirl when I have some cycles.
> 
> Reviewed-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
> 
> ---
> 
> You're right that this used to be use in xserver as well, but that was 
> removed in:
> 
> commit e61e19959d9138d5b81b1f25b7aa3e257918170d
> Author: Adam Jackson <a...@redhat.com>
> Date:   Tue Dec 3 13:45:43 2013 -0500
> 
> xquartz/glx: Convert to non-glapi dispatch
> 
> CGL doesn't have anything like glXGetProcAddress, and the old code just
> called down to dlsym in any case.  It's a little mind-warping since
> dlopening a framework actually loads multiple dylibs, but that's just
> how OSX rolls.
> 
> Signed-off-by: Adam Jackson <a...@redhat.com>
> Reviewed-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
> 
> 
> > On Sep 22, 2015, at 15:55, Ian Romanick <i...@freedesktop.org> wrote:
> >
> > On 09/17/2015 03:19 PM, Arlie Davis wrote:
> >> Ok, here's v2 of the change, with the suggested edits.
> >
> > So... I think this code is fine, and I admire the effort.  I have a
> > couple concerns.
> >
> > 1. We have no way to test this, so it's quite possible something was broken.
> >
> > 2. This function is only used in the OSX builds.  Jeremy is the
> > maintainer for those builds, so I've added him to the CC list.
> >
> > For every non-OSX build, we should just stop linking
> > src/mapi/glapi/glapi_gentable.c.  I thought maybe the X sever used it,
> > but I couldn't find any evidence of that.
> >
> > If this is still a viable route, I have a few suggestions of follow-on
> > patches...
> >
> > I guess this patch is
> >
> > Reviewed-by: Ian Romanick <ian.d.roman...@intel.com>
> >
> > but I really think we need to get Jeremy's approval before pushing it.
> >
> >> From 5f393faa058f453408dfc640eecae3fe6335dfed Mon Sep 17 00:00:00 2001
> >> From: Arlie Davis <arl...@google.com>
> >> Date: Tue, 15 Sep 2015 09:58:34 -0700
> >> Subject: [PATCH] This patch significantly reduces the size of the libGL.so
> >> binary. It does not change the (externally visible) behavior of libGL.so at
> >> all.
> >>
> >> gl_gentable.py generates a function, _glapi_create_table_from_handle.
> >> This function allocates a large dispatch table, consisting of 1300 or so
> >> function pointers, and fills this dispatch table by doing symbol lookups
> >> on a given shared library.  Previously, gl_gentable.py would generate a
> >> single, very large _glapi_create_table_from_handle function, with a short
> >> cluster of lines for each entry point (function).  The idiom it generates
> >> was a NULL check, a call to snprintf, a call to dlsym / GetProcAddress,
> >> and then a store into the dispatch table.  Since this function processes
> >> a large number of entry points, this code is duplicated many times over.
> >>
> >> We can encode the same information much more compactly, by using a lookup
> >> table.  The previous total size of _glapi_create_table_from_handle on x64
> >> was 125848 bytes.  By using a lookup table, the size of
> >> _glapi_create_table_from_handle (and the related lookup tables) is reduced
> >> to 10840 bytes.  In other words, this enormous function is reduced by 91%.
> >> The size of the entire libGL.so binary (measured when stripped) itself 
> >> drops
> >> by 15%.
> >>
> >> So the purpose of this change is to reduce the binary size, which frees up
> >> disk space, memory, etc.
> >> ---
> >> src/mapi/glapi/gen/gl_gentable.py | 57 
> >> ---
> >> 1 file changed

Re: [Mesa-dev] mesa: Reduce libGL.so binary size by about 15%

[Jeremy Huddleston Sequoia]

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 <jerem...@apple.com>

---

You're right that this used to be use in xserver as well, but that was removed 
in:

commit e61e19959d9138d5b81b1f25b7aa3e257918170d
Author: Adam Jackson <a...@redhat.com>
Date:   Tue Dec 3 13:45:43 2013 -0500

xquartz/glx: Convert to non-glapi dispatch

CGL doesn't have anything like glXGetProcAddress, and the old code just
called down to dlsym in any case.  It's a little mind-warping since
dlopening a framework actually loads multiple dylibs, but that's just
how OSX rolls.

Signed-off-by: Adam Jackson <a...@redhat.com>
Reviewed-by: Jeremy Huddleston Sequoia <jerem...@apple.com>


> On Sep 22, 2015, at 15:55, Ian Romanick <i...@freedesktop.org> wrote:
> 
> On 09/17/2015 03:19 PM, Arlie Davis wrote:
>> Ok, here's v2 of the change, with the suggested edits.
> 
> So... I think this code is fine, and I admire the effort.  I have a
> couple concerns.
> 
> 1. We have no way to test this, so it's quite possible something was broken.
> 
> 2. This function is only used in the OSX builds.  Jeremy is the
> maintainer for those builds, so I've added him to the CC list.
> 
> For every non-OSX build, we should just stop linking
> src/mapi/glapi/glapi_gentable.c.  I thought maybe the X sever used it,
> but I couldn't find any evidence of that.
> 
> If this is still a viable route, I have a few suggestions of follow-on
> patches...
> 
> I guess this patch is
> 
> Reviewed-by: Ian Romanick <ian.d.roman...@intel.com>
> 
> but I really think we need to get Jeremy's approval before pushing it.
> 
>> From 5f393faa058f453408dfc640eecae3fe6335dfed Mon Sep 17 00:00:00 2001
>> From: Arlie Davis <arl...@google.com>
>> Date: Tue, 15 Sep 2015 09:58:34 -0700
>> Subject: [PATCH] This patch significantly reduces the size of the libGL.so
>> binary. It does not change the (externally visible) behavior of libGL.so at
>> all.
>> 
>> gl_gentable.py generates a function, _glapi_create_table_from_handle.
>> This function allocates a large dispatch table, consisting of 1300 or so
>> function pointers, and fills this dispatch table by doing symbol lookups
>> on a given shared library.  Previously, gl_gentable.py would generate a
>> single, very large _glapi_create_table_from_handle function, with a short
>> cluster of lines for each entry point (function).  The idiom it generates
>> was a NULL check, a call to snprintf, a call to dlsym / GetProcAddress,
>> and then a store into the dispatch table.  Since this function processes
>> a large number of entry points, this code is duplicated many times over.
>> 
>> We can encode the same information much more compactly, by using a lookup
>> table.  The previous total size of _glapi_create_table_from_handle on x64
>> was 125848 bytes.  By using a lookup table, the size of
>> _glapi_create_table_from_handle (and the related lookup tables) is reduced
>> to 10840 bytes.  In other words, this enormous function is reduced by 91%.
>> The size of the entire libGL.so binary (measured when stripped) itself drops
>> by 15%.
>> 
>> So the purpose of this change is to reduce the binary size, which frees up
>> disk space, memory, etc.
>> ---
>> src/mapi/glapi/gen/gl_gentable.py | 57 
>> ---
>> 1 file changed, 41 insertions(+), 16 deletions(-)
>> 
>> diff --git a/src/mapi/glapi/gen/gl_gentable.py 
>> b/src/mapi/glapi/gen/gl_gentable.py
>> index 1b3eb72..7cd475a 100644
>> --- a/src/mapi/glapi/gen/gl_gentable.py
>> +++ b/src/mapi/glapi/gen/gl_gentable.py
>> @@ -113,6 +113,9 @@ __glapi_gentable_set_remaining_noop(struct _glapi_table 
>> *disp) {
>> dispatch[i] = p.v;
>> }
>> 
>> +"""
>> +
>> +footer = """
>> struct _glapi_table *
>> _glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
>> struct _glapi_table *disp = calloc(_glapi_get_dispatch_table_size(), 
>> sizeof(_glapi_proc));
>> @@ -123,27 +126,28 @@ _glapi_create_table_from_handle(void *handle, const 
>> char *symbol_prefix) {
>> 
>> if(symbol_prefix == NULL)
>> symbol_prefix = "";
>> -"""
>> 
>> -footer = """
>> -__glapi_gentable_set_remaining_noop(disp);
>> -
>> -return disp;
>> -}
>> -"""

Re: [Mesa-dev] [PATCH 06/11] loader: use HAVE_LIBDRM instead of ! __NOT_HAVE_DRM_H

[Jeremy Huddleston Sequoia]

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 <jerem...@apple.com>


> On Jul 9, 2015, at 10:55, Ian Romanick <i...@freedesktop.org> wrote:
> 
> I can't really speak to the Android.mk or SConscript changes, but the
> rest of this patch is
> 
> Reviewed-by: Ian Romanick <ian.d.roman...@intel.com>
> 
> You might also see what Jeremy Huddleston Sequoia <jerem...@apple.com>
> thinks, since most of this exists to support his platform. :)
> 
> On 07/08/2015 10:07 AM, Emil Velikov wrote:
>> Double negatives in English language are normally avoided, plus the
>> former seems cleaner and more consistent.
>> 
>> Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com>
>> ---
>> src/loader/Android.mk  | 6 ++
>> src/loader/Makefile.am | 5 +
>> src/loader/SConscript  | 2 --
>> src/loader/loader.c| 8 
>> src/loader/pci_id_driver_map.c | 2 +-
>> 5 files changed, 8 insertions(+), 15 deletions(-)
>> 
>> diff --git a/src/loader/Android.mk b/src/loader/Android.mk
>> index 92d9fd2..8690565 100644
>> --- a/src/loader/Android.mk
>> +++ b/src/loader/Android.mk
>> @@ -33,10 +33,8 @@ include $(CLEAR_VARS)
>> LOCAL_SRC_FILES := \
>>  $(LOADER_C_FILES)
>> 
>> -# swrast only
>> -ifeq ($(MESA_GPU_DRIVERS),swrast)
>> -LOCAL_CFLAGS += -D__NOT_HAVE_DRM_H
>> -else
>> +ifneq ($(filter-out swrast,$(MESA_GPU_DRIVERS)),)
>> +LOCAL_CFLAGS += -DHAVE_LIBDRM
>> LOCAL_SHARED_LIBRARIES := libdrm
>> endif
>> 
>> diff --git a/src/loader/Makefile.am b/src/loader/Makefile.am
>> index aef1bd6..5190f7f 100644
>> --- a/src/loader/Makefile.am
>> +++ b/src/loader/Makefile.am
>> @@ -48,10 +48,7 @@ libloader_la_CPPFLAGS += \
>> 
>> endif
>> 
>> -if !HAVE_LIBDRM
>> -libloader_la_CPPFLAGS += \
>> --D__NOT_HAVE_DRM_H
>> -else
>> +if HAVE_LIBDRM
>> libloader_la_CPPFLAGS += \
>>  $(LIBDRM_CFLAGS)
>> 
>> diff --git a/src/loader/SConscript b/src/loader/SConscript
>> index 16d1053..d98f11e 100644
>> --- a/src/loader/SConscript
>> +++ b/src/loader/SConscript
>> @@ -8,8 +8,6 @@ env.Prepend(CPPPATH = [
>> '#include'
>> ])
>> 
>> -env.Append(CPPDEFINES = ['__NOT_HAVE_DRM_H'])
>> -
>> if env['udev']:
>> env.PkgUseModules('UDEV')
>> env.Append(CPPDEFINES = ['HAVE_LIBUDEV'])
>> diff --git a/src/loader/loader.c b/src/loader/loader.c
>> index 8780587..4ed0a1f 100644
>> --- a/src/loader/loader.c
>> +++ b/src/loader/loader.c
>> @@ -85,7 +85,7 @@
>> #endif
>> #include "loader.h"
>> 
>> -#ifndef __NOT_HAVE_DRM_H
>> +#ifdef HAVE_LIBDRM
>> #include 
>> #endif
>> 
>> @@ -501,7 +501,7 @@ sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int 
>> *chip_id)
>> }
>> #endif
>> 
>> -#if !defined(__NOT_HAVE_DRM_H)
>> +#if defined(HAVE_LIBDRM)
>> /* for i915 */
>> #include 
>> /* for radeon */
>> @@ -584,7 +584,7 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int 
>> *chip_id)
>>if (sysfs_get_pci_id_for_fd(fd, vendor_id, chip_id))
>>   return 1;
>> #endif
>> -#if !defined(__NOT_HAVE_DRM_H)
>> +#if HAVE_LIBDRM
>>if (drm_get_pci_id_for_fd(fd, vendor_id, chip_id))
>>   return 1;
>> #endif
>> @@ -695,7 +695,7 @@ loader_get_driver_for_fd(int fd, unsigned driver_types)
>> 
>>if (!loader_get_pci_id_for_fd(fd, _id, _id)) {
>> 
>> -#ifndef __NOT_HAVE_DRM_H
>> +#if HAVE_LIBDRM
>>   /* fallback to drmGetVersion(): */
>>   drmVersionPtr version = drmGetVersion(fd);
>> 
>> diff --git a/src/loader/pci_id_driver_map.c b/src/loader/pci_id_driver_map.c
>> index cb6f705..3c4657f 100644
>> --- a/src/loader/pci_id_driver_map.c
>> +++ b/src/loader/pci_id_driver_map.c
>> @@ -23,7 +23,7 @@
>> 
>> int is_nouveau_vieux(int fd);
>> 
>> -#ifndef __NOT_HAVE_DRM_H
>> +#ifdef HAVE_LIBDRM
>> 
>> #include 
>> #include 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure.ac: Add support to enable read-only text segment on x86.

[Jeremy Huddleston Sequoia]

Wow, that's a blast from the past ;)

> On Sep 3, 2015, at 21:36, Matt Turner <matts...@gmail.com> wrote:
> 
> From: Jeremy Huddleston <jerem...@freedesktop.org>
> 
> Cc: "10.6 11.0" <mesa-sta...@lists.freedesktop.org>
> Bugzilla: https://bugs.gentoo.org/240956
> ---
> After talking with Ian today, we determined that this disables an
> optimization.
> 
> And FWIW, NVIDIA's fork of glapi (libglvnd) contains this kind of
> writable-text optimization for x86-64.
> 
> configure.ac | 10 ++
> 1 file changed, 10 insertions(+)
> 
> diff --git a/configure.ac b/configure.ac
> index 90ba4fe..259f770 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1289,6 +1289,16 @@ AC_SUBST(GLX_TLS, ${GLX_USE_TLS})
> AS_IF([test "x$GLX_USE_TLS" = xyes -a "x$ax_pthread_ok" = xyes],
>   [DEFINES="${DEFINES} -DGLX_USE_TLS"])
> 
> +dnl Read-only text section on x86 hardened platforms
> +AC_ARG_ENABLE([glx-read-only-text],
> +[AS_HELP_STRING([--enable-glx-read-only-text],
> +[Disable writable .text section on x86 (decreases performance) 
> @<:@default=disabled@:>@])],
> +[enable_glx_read_only_text="$enableval"],
> +[enable_glx_read_only_text=no])
> +if test "x$enable_glx_read_only_text" = xyes; then
> +DEFINES="$DEFINES -DGLX_X86_READONLY_TEXT"
> +fi
> +
> dnl
> dnl More DRI setup
> dnl
> -- 
> 2.4.6
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glext.h: Add missing include of stddef.h for ptrdiff_t

[Jeremy Huddleston Sequoia]

 On May 20, 2015, at 13:59, Emil Velikov emil.l.veli...@gmail.com wrote:
 
 Hi Jeremy,
 
 On 11 February 2015 at 20:36, Jeremy Huddleston Sequoia
 jerem...@freedesktop.org wrote:
 
 Signed-off-by: Jeremy Huddleston Sequoia jerem...@apple.com
 ---
 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 (GLint count);
 
 #ifndef GL_ARB_vertex_buffer_object
 #define GL_ARB_vertex_buffer_object 1
 +#include stddef.h
 As Matt pointed out the headers are coming directly from Khronos and
 we should not modify them. Did you had the change to report this issue
 to them ?

I don't think I did.

I have now: https://www.khronos.org/bugzilla/show_bug.cgi?id=1345


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH:mesa] swrast: Build fix for Solaris

[Jeremy Huddleston Sequoia]

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 jerem...@apple.com

 On May 15, 2015, at 19:05, Alan Coopersmith alan.coopersm...@oracle.com 
 wrote:
 
 Fixes regression from commit 5b2d3480f57168d50ad24cf0b8c9244414bd3701
 
 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
 CC: Jeremy Huddleston Sequoia jerem...@apple.com
 ---
 configure.ac |1 +
 src/mesa/drivers/dri/swrast/swrast.c |4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/configure.ac b/configure.ac
 index cd3ba35..135dcb4 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -651,6 +651,7 @@ if test x$enable_asm = xyes; then
 fi
 
 AC_CHECK_HEADER([xlocale.h], [DEFINES=$DEFINES -DHAVE_XLOCALE_H])
 +AC_CHECK_HEADER([sys/sysctl.h], [DEFINES=$DEFINES -DHAVE_SYS_SYSCTL_H])
 AC_CHECK_FUNC([strtof], [DEFINES=$DEFINES -DHAVE_STRTOF])
 
 dnl Check to see if dlopen is in default libraries (like Solaris, which
 diff --git a/src/mesa/drivers/dri/swrast/swrast.c 
 b/src/mesa/drivers/dri/swrast/swrast.c
 index cbc946c..2d4bb70 100644
 --- a/src/mesa/drivers/dri/swrast/swrast.c
 +++ b/src/mesa/drivers/dri/swrast/swrast.c
 @@ -62,7 +62,9 @@
 #include swrast/s_context.h
 
 #include sys/types.h
 -#include sys/sysctl.h
 +#ifdef HAVE_SYS_SYSCTL_H
 +# include sys/sysctl.h
 +#endif
 
 const __DRIextension **__driDriverGetExtensions_swrast(void);
 
 -- 
 1.7.9.2
 



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] darwin: Fix install name of libOSMesa

[Jeremy Huddleston Sequoia]

 On Feb 11, 2015, at 05:02, Emil Velikov emil.l.veli...@gmail.com wrote:
 
 On 11 February 2015 at 10:32, Jeremy Huddleston Sequoia
 jerem...@apple.com 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 long time we should be safe.
 Just a couple small requests - can you clarify what you mean with Fix
 install name

Passing -module to glibtool causes the resulting library to be called 
libSomething.so rather than libSomething.dylib on darwin.

 and update the gallium one (src/gallium/targets/osmesa).

I can do that, but I can't test it since gallium doesn't build on darwin, so 
I'd prefer to leave that alone for now.

--Jeremy

 
 Thanks
 Emil
 
 * lib prefix, soname, living in lib, pkgconfig providing -lOSMesa) I
 see no problems wit



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glext.h: Add missing include of stddef.h for ptrdiff_t

[Jeremy Huddleston Sequoia]

Signed-off-by: Jeremy Huddleston Sequoia jerem...@apple.com
---
 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 (GLint count);
 
 #ifndef GL_ARB_vertex_buffer_object
 #define GL_ARB_vertex_buffer_object 1
+#include stddef.h
 typedef ptrdiff_t GLsizeiptrARB;
 typedef ptrdiff_t GLintptrARB;
 #define GL_BUFFER_SIZE_ARB0x8764
-- 
2.3.0




smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Removing the --allow-multiple-definition hack

[Jeremy Huddleston Sequoia]

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
Author: Emil Velikov emil.l.veli...@gmail.com
Date:   Wed Jul 2 12:06:41 2014 +0100

targets/dri: allow duplicated symbols

With the inclusion of xmlconfig in the loader we're providing dri* symbols
which are already available in libdricommon.la. This leads to a build
break due to the multiple definitions.

Temporary allow multiple definitions, until we come with a better solution.

Reported-by: Laurent Carlier lordhea...@gmail.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] darwin: Fix install name of libOSMesa

[Jeremy Huddleston Sequoia]

libOSMesa is a library, not a module

Signed-off-by: Jeremy Huddleston Sequoia jerem...@apple.com
---
 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/drivers/osmesa/Makefile.am
+++ b/src/mesa/drivers/osmesa/Makefile.am
@@ -39,7 +39,6 @@ nodist_EXTRA_lib@OSMESA_LIB@_la_SOURCES = dummy.cpp
 lib@OSMESA_LIB@_la_SOURCES = osmesa.c
 
 lib@OSMESA_LIB@_la_LDFLAGS = \
-   -module \
-no-undefined \
-version-number @OSMESA_VERSION@ \
$(GC_SECTIONS) \
-- 
2.3.0



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] swrast: Build fix for darwin

[Jeremy Huddleston Sequoia]

This is certainly not the best solution to the problem, so I'm just sending 
this patch to the list to get the discussion started on the best way to solve 
this problem.  Currently, any platform that does not support _SC_PHYS_PAGES and 
_SC_PAGESIZE will fail to build swrast.  _SC_PHYS_PAGES is not POSIX and thus 
there are many platforms out there that don't support it (such as OS X).

We may want to put os_get_total_physical_memory() from 
src/gallium/auxiliary/os/os_misc.c into a more common location, so it could be 
used here.

However, as the existing comment indicates, maybe 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 jerem...@apple.com 
 wrote:
 
 Fixes regression from commit 64b1dc44495890cbc2c7c5509cb830264020998c
 
 Signed-off-by: Jeremy Huddleston Sequoia jerem...@apple.com
 CC: Emil Velikov emil.l.veli...@gmail.com
 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/src/mesa/drivers/dri/swrast/swrast.c 
 b/src/mesa/drivers/dri/swrast/swrast.c
 index d62fed3..0b7329a 100644
 --- a/src/mesa/drivers/dri/swrast/swrast.c
 +++ b/src/mesa/drivers/dri/swrast/swrast.c
 @@ -59,6 +59,9 @@
 #include swrast_priv.h
 #include swrast/s_context.h
 
 +#include sys/types.h
 +#include sys/sysctl.h
 +
 const __DRIextension **__driDriverGetExtensions_swrast(void);
 
 const char * const swrast_vendor_string = Mesa Project;
 @@ -135,6 +138,16 @@ swrast_query_renderer_integer(__DRIscreen *psp, int 
 param,
   value[0] = 0;
   return 0;
case __DRI2_RENDERER_VIDEO_MEMORY: {
 +  /* This should probably share code with os_get_total_physical_memory()
 +   * from src/gallium/auxiliary/os/os_misc.c
 +   */
 +#if defined(CTL_HW)  defined(HW_MEMSIZE)
 +int mib[2] = { CTL_HW, HW_MEMSIZE };
 +unsigned long system_memory_bytes;
 +size_t len = sizeof(system_memory_bytes);
 +if (sysctl(mib, 2, system_memory_bytes, len, NULL, 0) != 0)
 +return -1;
 +#elif defined(_SC_PHYS_PAGES)  defined(_SC_PAGE_SIZE)
   /* XXX: Do we want to return the full amount of system memory ? */
   const long system_memory_pages = sysconf(_SC_PHYS_PAGES);
   const long system_page_size = sysconf(_SC_PAGE_SIZE);
 @@ -144,6 +157,9 @@ swrast_query_renderer_integer(__DRIscreen *psp, int param,
 
   const uint64_t system_memory_bytes = (uint64_t) system_memory_pages
  * (uint64_t) system_page_size;
 +#else
 +#error Unsupported platform
 +#endif
 
   const unsigned system_memory_megabytes =
  (unsigned) (system_memory_bytes / (1024 * 1024));
 -- 
 2.2.1
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] swrast: Build fix for darwin

[Jeremy Huddleston Sequoia]

Fixes regression from commit 64b1dc44495890cbc2c7c5509cb830264020998c

Signed-off-by: Jeremy Huddleston Sequoia jerem...@apple.com
CC: Emil Velikov emil.l.veli...@gmail.com
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/src/mesa/drivers/dri/swrast/swrast.c 
b/src/mesa/drivers/dri/swrast/swrast.c
index d62fed3..0b7329a 100644
--- a/src/mesa/drivers/dri/swrast/swrast.c
+++ b/src/mesa/drivers/dri/swrast/swrast.c
@@ -59,6 +59,9 @@
 #include swrast_priv.h
 #include swrast/s_context.h
 
+#include sys/types.h
+#include sys/sysctl.h
+
 const __DRIextension **__driDriverGetExtensions_swrast(void);
 
 const char * const swrast_vendor_string = Mesa Project;
@@ -135,6 +138,16 @@ swrast_query_renderer_integer(__DRIscreen *psp, int param,
   value[0] = 0;
   return 0;
case __DRI2_RENDERER_VIDEO_MEMORY: {
+  /* This should probably share code with os_get_total_physical_memory()
+   * from src/gallium/auxiliary/os/os_misc.c
+   */
+#if defined(CTL_HW)  defined(HW_MEMSIZE)
+int mib[2] = { CTL_HW, HW_MEMSIZE };
+unsigned long system_memory_bytes;
+size_t len = sizeof(system_memory_bytes);
+if (sysctl(mib, 2, system_memory_bytes, len, NULL, 0) != 0)
+return -1;
+#elif defined(_SC_PHYS_PAGES)  defined(_SC_PAGE_SIZE)
   /* XXX: Do we want to return the full amount of system memory ? */
   const long system_memory_pages = sysconf(_SC_PHYS_PAGES);
   const long system_page_size = sysconf(_SC_PAGE_SIZE);
@@ -144,6 +157,9 @@ swrast_query_renderer_integer(__DRIscreen *psp, int param,
 
   const uint64_t system_memory_bytes = (uint64_t) system_memory_pages
  * (uint64_t) system_page_size;
+#else
+#error Unsupported platform
+#endif
 
   const unsigned system_memory_megabytes =
  (unsigned) (system_memory_bytes / (1024 * 1024));
-- 
2.2.1

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] how client glx extensions and GLX extensions are determined (and how best to limit them)

[Jeremy Huddleston Sequoia]

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 when in a 
testing mode (so as to not enable breakage by default while working on these 
changes).  To this end, I'm the following to applegl_create_screen:

@@ -183,6 +191,12 @@ applegl_create_screen(int screen, struct glx_display * 
priv)
glx_screen_init(psc, screen, priv);
psc-vtable = applegl_screen_vtable;
 
+   /* Testing support for core profiles is guarded by an envvar for now */
+   if (getenv(LIBGL_PROFILE_CORE)) {
+   __glXEnableDirectExtension(psc, GLX_ARB_create_context);
+   __glXEnableDirectExtension(psc, GLX_ARB_create_context_profile);
+   }
+
return psc;
 }

The goal of this change is that these extensions would only be advertised as 
available to clients if they set the LIBGL_PROFILE_CORE environment variable.  
Unfortunately, it seems that GLX_ARB_create_context and 
GLX_ARB_create_context_profile are always advertised on current mesa.  
__glXExtensionsCtr sets them up as client supported (but not direct supported) 
by default, so I'm confused why they're being listed as available GLX 
extensions when using direct rendering.  Can someone fill me in on how to best 
prevent GLX_ARB_create_context and GLX_ARB_create_context_profile from being 
advertised (short of adding more #ifdef GLX_USE_APPLEGL)?

Thanks,
Jeremy

(lldb) print known_glx_extensions
(const extension_info [34]) $2 = {
  [0] = {
name = 0x0001004896b4 GLX_ARB_create_context
name_len = 22
bit = '\0'
version_major = '\0'
version_minor = '\0'
client_support = '\x01'
direct_support = '\0'
client_only = '\0'
direct_only = '\0'
  }
  [1] = {
name = 0x00010048aa82 GLX_ARB_create_context_profile
name_len = 30
bit = '\x01'
version_major = '\0'
version_minor = '\0'
client_support = '\x01'
direct_support = '\0'
client_only = '\0'
direct_only = '\0'
  }


display: /tmp/launch-l5xfi8/org.macosforge.xquartz:0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, 
GLX_SGIX_fbconfig
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_create_context_es2_profile, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, 
GLX_INTEL_swap_event, GLX_EXT_buffer_age
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_profile, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_MESA_multithread_makecurrent, GLX_OML_swap_method, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig
OpenGL vendor string: ATI Technologies Inc.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] build failure: _mesa_BindAttribLocation vs _mesa_lookup_shader_program_err , GLuint vs GLhandleARB

[Jeremy Huddleston Sequoia]

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: candidate function not viable: 
cannot convert argument of incomplete type 'GLhandleARB'
  (aka 'void *') to 'GLuint' (aka 'unsigned int')
_mesa_lookup_shader_program_err(struct gl_context *ctx, GLuint name,
^

_mesa_lookup_shader_program_err is defined as:

extern struct gl_shader_program *
_mesa_lookup_shader_program_err(struct gl_context *ctx, GLuint name,
const char *caller);


but it is being passed a GLhandleARB rather than an GLuint by 
_mesa_BindAttribLocation:

void GLAPIENTRY
_mesa_BindAttribLocation(GLhandleARB program, GLhandleARB index,
const GLcharARB *name)
{
   GET_CURRENT_CONTEXT(ctx);

   struct gl_shader_program *const shProg =
  _mesa_lookup_shader_program_err(ctx, program, glBindAttribLocation);
...

This seems like an old bug that is just now coming to light.  The main reason 
nobody else seems to have hit this in a while is that on most platforms, 
GLhandleARB and GLuint are both 'unsigned integer', so the compiler happily 
goes back and forth between the two, but on darwin, GLhandleARB is a void * and 
thus cannot be implicitly cast to an unsigned int:

#ifdef __APPLE__
typedef void *GLhandleARB;
#else
typedef unsigned int GLhandleARB;
#endif

How should we address this?  I'd really really really prefer to not have to put 
a bunch of casts everywhere, and I'm ok breaking binary compatibility on darwin 
in fixing this.

--Jeremy

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] build failure: _mesa_BindAttribLocation vs _mesa_lookup_shader_program_err , GLuint vs GLhandleARB

[Jeremy Huddleston Sequoia]

On May 24, 2014, at 19:55, Emil Velikov emil.l.veli...@gmail.com 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'
  _mesa_lookup_shader_program_err(ctx, program, glBindAttribLocation);
  ^~~
 ../../src/mesa/main/shaderobj.h:81:1: note: candidate function not viable: 
 cannot convert argument of incomplete type 'GLhandleARB'
  (aka 'void *') to 'GLuint' (aka 'unsigned int')
 _mesa_lookup_shader_program_err(struct gl_context *ctx, GLuint name,
 ^
 
 _mesa_lookup_shader_program_err is defined as:
 
 extern struct gl_shader_program *
 _mesa_lookup_shader_program_err(struct gl_context *ctx, GLuint name,
const char *caller);
 
 
 but it is being passed a GLhandleARB rather than an GLuint by 
 _mesa_BindAttribLocation:
 
 void GLAPIENTRY
 _mesa_BindAttribLocation(GLhandleARB program, GLhandleARB index,
const GLcharARB *name)
 {
   GET_CURRENT_CONTEXT(ctx);
 
   struct gl_shader_program *const shProg =
  _mesa_lookup_shader_program_err(ctx, program, glBindAttribLocation);
 ...
 
 This seems like an old bug that is just now coming to light.  The main 
 reason nobody else seems to have hit this in a while is that on most 
 platforms, GLhandleARB and GLuint are both 'unsigned integer', so the 
 compiler happily goes back and forth between the two, but on darwin, 
 GLhandleARB is a void * and thus cannot be implicitly cast to an unsigned 
 int:
 
 #ifdef __APPLE__
 typedef void *GLhandleARB;
 #else
 typedef unsigned int GLhandleARB;
 #endif
 
 How should we address this?  I'd really really really prefer to not have to 
 put a bunch of casts everywhere, and I'm ok breaking binary compatibility on 
 darwin in fixing this.
 
 Hi Jeremy,
 
 IIRC there was another location where the above typedef gave us the finger.
 Not entirety sure what the conclusion on the topic was and I believe that some
 of the patches did not get accepted as they would break our current libGL 
 DRI ABI. The discussion (starting with a few patches) is available in the ML
 archives [1].
 
 -Emil
 
 [1] http://lists.freedesktop.org/archives/mesa-dev/2014-March/055617.html

Thanks for the pointer.  +Brian and Ian from the March thread.

As I understand it, the only platforms where fixing this could break the DRI 
ABI are the ones where GLhandleARB and GLuint do not have the same underlying 
type.  The only platform where that is the case is darwin, which doesn't use 
that code (hence why I mentioned above that I wasn't concerned about fixing 
this breaking binary compatibility on darwin).  Can someone explain how chaning 
some GLuint types to GLhandleARB (or visa versa) could break ABI on other 
systems?  I just don't see why that would be the case.

Ian said:
 The problem is that drivers are built expecting that glCompileShader and
 glCompileShaerARB are the same function.  As a result, the driver only
 asks libGL the offset of one of those functions in the dispatch table,
 and it only sets one pointer in the dispatch table.  Then an application
 tries to call the other function, gets a NULL dispatch pointer, and
 explodes.

That doesn't seem right to me.  Why would the driver only set one entry?  As it 
knows (or at least assumes) that both are the same, it seems understandable 
that it would just ask libGL for one of the functions, but it should set both 
entries in its dispatch table to that value.  Having a NULL entry for one of 
those functions seems like an obvious bug at the driver level.  Is the 
application layer really responsible for knowing about what aliasing is being 
done at the driver level?  That's a rather big violation of the abstraction 
that I'd expect to be present.

Also, in the earlier thread, Ian said, I can't understand why we'd break our 
own ABI because of something silly that Apple did.  This feels like madness. 
... if I recall, the issue wasn't that Apple did something silly, the issue 
was that GLhandleARB was underspecified and different vendors implemented it 
differently.  Apple is no more at fault for making it sized to a pointer 
(which is actually much more safe given ambiguity) than Mesa is at fault 
for fixing it at a 32bit unsigned integer.  The real issue here is that mesa is 
mixing GLhandleARB and GLuint when it shouldn't be and has made other design 
decisions which make fixing bugs like this difficult.

--Jeremy

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] Fix build of appleglx

[Jeremy Huddleston Sequoia]

Reviewed-by: Jeremy Huddleston Sequoia jerem...@apple.com with one minor 
change (see below):

On May 13, 2014, at 05:15, Jon TURNEY jon.tur...@dronecode.org.uk 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
 @@ -24,7 +24,7 @@ SHARED_GLAPI_CFLAGS = -DGLX_SHARED_GLAPI
 SHARED_GLAPI_LIB = $(top_builddir)/src/mapi/shared-glapi/libglapi.la
 endif
 
 -SUBDIRS=. tests
 +SUBDIRS=
 
 if HAVE_XF86VIDMODE
 EXTRA_DEFINES_XF86VIDMODE = -DXF86VIDMODE
 @@ -88,6 +88,8 @@ libglx_la_SOURCES = \
 drisw_glx.c \
 glxhash.c
 
 +libglx_la_LIBADD = $(top_builddir)/src/loader/libloader.la
 +
 if HAVE_DRICOMMON
 libglx_la_SOURCES += \
 dri_common.c
 @@ -110,9 +112,10 @@ endif
 if HAVE_APPLEDRI
 libglx_la_SOURCES += \
 applegl_glx.c
 -endif
 
 -libglx_la_LIBADD = $(top_builddir)/src/loader/libloader.la
 +SUBDIRS += apple
 +libglx_la_LIBADD += $(builddir)/apple/libappleglx.la
 +endif
 
 GL_LIBS = \
   libglx.la \
 @@ -131,4 +134,6 @@ lib@GL_LIB@_la_SOURCES =
 lib@GL_LIB@_la_LIBADD = $(GL_LIBS)
 lib@GL_LIB@_la_LDFLAGS = $(GL_LDFLAGS)
 
 +SUBDIRS+=. tests
 +
 include $(top_srcdir)/install-lib-links.mk

Because SUBDIRS is set conditionally, you should add:

DIST_SUBDIRS = tests apple

to handle what I assume is an eventual goal of supporting 'make dist'


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] Make DRI dependencies and build depend on the target

[Jeremy Huddleston Sequoia]

Reviewed-by: Jeremy Huddleston Sequoia jerem...@apple.com

On May 13, 2014, at 05:15, Jon TURNEY jon.tur...@dronecode.org.uk 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 built, so that a 
 libGL
 using direct swrast can be built on targets which don't have DRM.
 
 The HAVE_DRI automake conditional is retired in favour of a number of other
 conditionals:
 
 HAVE_DRI2 enables building of code using the DRI2 interface (and possibly DRI3
 with HAVE_DRI3)
 
 HAVE_DRISW enables building of DRI swrast
 
 HAVE_DRICOMMON enables building of target-independent DRI code, and also 
 enables
 some makefile cases where a more detailled decision is made at a lower level.
 
 HAVE_APPLEDRI enables building of an Apple-specific direct rendering 
 interface,
 still which requires additional fixing up to build properly.
 
 Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
 ---
 configure.ac   | 55 +-
 src/gallium/state_trackers/Makefile.am |  2 +-
 src/gallium/state_trackers/dri/Makefile.am |  6 +++-
 src/gallium/targets/Makefile.am| 18 +-
 src/gallium/targets/gbm/Makefile.am|  2 +-
 src/gallium/targets/opencl/Makefile.am |  2 +-
 src/gallium/targets/xa/Makefile.am |  2 +-
 src/gallium/tests/trivial/Makefile.am  |  2 +-
 src/gallium/winsys/Makefile.am |  2 +-
 src/gbm/Makefile.am|  2 +-
 src/glx/Makefile.am| 20 ---
 src/mesa/Makefile.am   |  2 +-
 12 files changed, 77 insertions(+), 38 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index f571af1..6eeb2ea 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -765,8 +765,22 @@ fi
 
 AM_CONDITIONAL(HAVE_DRI_GLX, test x$enable_glx = xyes -a \
   x$enable_dri = xyes)
 -AM_CONDITIONAL(HAVE_DRI, test x$enable_dri = xyes)
 -AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes)
 +
 +# Select which platform-dependent DRI code gets built
 +case $host_os in
 +darwin*)
 +dri_platform='apple' ;;
 +gnu*|mingw*|cygwin*)
 +dri_platform='none' ;;
 +*)
 +dri_platform='drm' ;;
 +esac
 +
 +AM_CONDITIONAL(HAVE_DRICOMMON, test x$enable_dri = xyes )
 +AM_CONDITIONAL(HAVE_DRISW, test x$enable_dri = xyes )
 +AM_CONDITIONAL(HAVE_DRI2, test x$enable_dri = xyes  test 
 x$dri_platform = xdrm )
 +AM_CONDITIONAL(HAVE_DRI3, test x$enable_dri3 = xyes  test 
 x$dri_platform = xdrm )
 +AM_CONDITIONAL(HAVE_APPLEDRI, test x$enable_dri = xyes  test 
 x$dri_platform = xapple )
 
 AC_ARG_ENABLE([shared-glapi],
 [AS_HELP_STRING([--enable-shared-glapi],
 @@ -891,23 +905,30 @@ xyesyes)
 xyesno)
 # DRI-based GLX
 PKG_CHECK_MODULES([GLPROTO], [glproto = $GLPROTO_REQUIRED])
 -if test x$driglx_direct = xyes; then
 -if test x$have_libdrm != xyes; then
 -AC_MSG_ERROR([Direct rendering requires libdrm = 
 $LIBDRM_REQUIRED])
 -fi
 -PKG_CHECK_MODULES([DRI2PROTO], [dri2proto = $DRI2PROTO_REQUIRED])
 -GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV libdrm = $LIBDRM_REQUIRED
 -if test x$enable_dri3 = xyes; then
 -PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = 
 $DRI3PROTO_REQUIRED])
 -PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
 $PRESENTPROTO_REQUIRED])
 -fi
 -fi
 
 # find the DRI deps for libGL
 -dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = $XCBGLX_REQUIRED 
 xcb-dri2 = $XCBDRI2_REQUIRED
 +dri_modules=x11 xext xdamage xfixes x11-xcb xcb-glx = $XCBGLX_REQUIRED
 
 -if test x$enable_dri3 = xyes; then
 -dri_modules=$dri_modules xcb-dri3 xcb-present xcb-sync xshmfence = 
 $XSHMFENCE_REQUIRED
 +if test x$driglx_direct = xyes; then
 +if test x$dri_platform = xdrm ; then
 +if test x$have_libdrm != xyes; then
 +   AC_MSG_ERROR([Direct rendering requires libdrm = 
 $LIBDRM_REQUIRED])
 +fi
 +
 +PKG_CHECK_MODULES([DRI2PROTO], [dri2proto = 
 $DRI2PROTO_REQUIRED])
 +GL_PC_REQ_PRIV=$GL_PC_REQ_PRIV libdrm = $LIBDRM_REQUIRED
 +if test x$enable_dri3 = xyes; then
 +   PKG_CHECK_MODULES([DRI3PROTO], [dri3proto = 
 $DRI3PROTO_REQUIRED])
 +   PKG_CHECK_MODULES([PRESENTPROTO], [presentproto = 
 $PRESENTPROTO_REQUIRED])
 +fi
 +
 +if test x$enable_dri = xyes; then
 +   dri_modules=$dri_modules xcb-dri2 = $XCBDRI2_REQUIRED
 +fi
 +
 +if test x$enable_dri3 = xyes; then
 +   dri_modules=$dri_modules xcb-dri3 xcb-present xcb-sync 
 xshmfence = $XSHMFENCE_REQUIRED
 +fi
 fi
 
 # add xf86vidmode if available
 @@ -2253,7 +2274,9 @@ xnono)
 ;;
 esac
 
 +echo 
 if test x$enable_dri != xno; then
 +echo DRI platform:$dri_platform
 if test

Re: [Mesa-dev] [PATCH 3/3] Fix build of appleglx

[Jeremy Huddleston Sequoia]

On May 20, 2014, at 05:57, Jon TURNEY jon.tur...@dronecode.org.uk 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 them.


 On May 13, 2014, at 05:15, Jon TURNEY wrote:
 
 +SUBDIRS+=. tests
 +
 include $(top_srcdir)/install-lib-links.mk
 
 Because SUBDIRS is set conditionally, you should add:
 
 DIST_SUBDIRS = tests apple
 
 to handle what I assume is an eventual goal of supporting 'make dist'
 
 I don't think that is needed in this case, as automake should be smart enough 
 to work it out correctly.

My experience is that automake isn't quite that smart (cf: DIST_SUBDIRS usage 
through xserver).  I'd prefer to be on the safe side, but either way is fine 
with me (we can always just add it later if automake misbehaves).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx/dri2: Respect --enable/disable-driglx-direct

[Jeremy Huddleston Sequoia]

On Feb 17, 2014, at 13:29, Emil Velikov emil.l.veli...@gmail.com wrote:

 On 17/02/14 06:49, Jeremy Huddleston Sequoia wrote:
 
 On Feb 16, 2014, at 17:15, Emil Velikov emil.l.veli...@gmail.com 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 
 someone will have the time and patience to get it working again in the 
 near future.
 
 Hi Jeremy
 
 A while back, I was pondering on converting the apple glx to automake,
 but the biggest obstacle was the complete lack of testing (compile or
 runtime). iirc you have a tinderbox at x.org but it does not build mesa.
 Do you mind updating it ?
 
 It does build mesa (and has for quite some time now), but it builds it for 
 DRI (not Apple-DRI).  If you want me to add another target (mesa-apple or 
 similar), let me know what configure options you want me to pass it to 
 trigger your new way.
 
 Hmm perhaps I'm looking at the wrong location. This [1] is what I had in
 mind, but afaics it never even goes through the configure stage, let
 alone build it. Am I missing something ?

No, I was.  I saw 'Mesa 3D Graphics' but that is just the meta-module.

mesa-mesa was in skip.  I've removed it and kicked of a build 
(http://tinderbox.x.org/builds/2014-02-18-).

 Whereas for build options - those depend on your requirements. I would
 start with what should should work atm, and then work on the merge
 codebases part.

There are no configure flags to enable Apple-DRI right now, so it's just using 
the default configure flags.  Let me know what you want me to change it to.  I 
can also update it to checkout a different branch or repo if you prefer to work 
somewhere other than master.

 FWIW, the end goal was to eventually merge the codebases together so we 
 could support both indirect GLX and Apple-DRI in the same libGL, but that 
 never happened.
 
 Interesting, is this Apple-DRI backed by actual hw (classic/gallium)
 drivers or are we talking about swrast only ? AFAICS all hw dri drivers
 are quite linux specific.

Apple-DRI is something completely different.  It uses OpenGL.framework and is 
not backed by gallium or swrast.  It was done over a decade ago as a branch of 
XFree86 that was never accepted and merged back in.  Code diverged and about 7 
years ago, we started trying to get XQuartz' merged into freedesktop.org.  That 
process was pretty much fully completed by about 4 years ago except for mesa.  
Mesa only supports AppleDRI in a separate build configuration which makes it 
impossible to have a libGL that supports indirect GLX when the server is remote 
and Apple-DRI when it is local.

--Jeremy



smime.p7s
Description: S/MIME cryptographic signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx/dri2: Respect --enable/disable-driglx-direct

[Jeremy Huddleston Sequoia]

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 Romanick i...@freedesktop.org wrote:
 
 On 02/13/2014 02:11 AM, Daniel Martin wrote:
 Encapsulate the code in src/glx/dri2_query_renderer.c within a
 
#ifdef GLX_DIRECT_RENDERING
 
 as done in src/glx/dri2*.c.
 
 I noticed a couple things, and I'm not sure what the right answer is.
 
 First, dri2_glx.c and dri3_glx.c use:
 
 #if defined(GLX_DIRECT_RENDERING)  !defined(GLX_USE_APPLEGL)
 
 but dri2.c uses
 
 #ifdef GLX_DIRECT_RENDERING
 
 I'm not sure why they're different or which is actually correct.
 
 Second, couldn't we just not build the file at all when
 GLX_DIRECT_RENDERING isn't selected?  Do something like the following in
 src/glx/Makefile.am:
 
 if HAVE_DRI2 || HAVE_DRI3
 libglx_la_SOURCES += \
  dri2_glx.c
  dri2.c
  dri2_query_renderer.c
 endif
 
 (and remove those files from the default libglx_la_SOURCES list, of course).
 
 Signed-off-by: Daniel Martin consume.no...@gmail.com
 ---
 ... compile it, when enabled only.
 
 Cheers,
Daniel
 
 src/glx/dri2_query_renderer.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/src/glx/dri2_query_renderer.c b/src/glx/dri2_query_renderer.c
 index b50a202..3bc90c7 100644
 --- a/src/glx/dri2_query_renderer.c
 +++ b/src/glx/dri2_query_renderer.c
 @@ -20,6 +20,9 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
  * DEALINGS IN THE SOFTWARE.
  */
 +
 +#ifdef GLX_DIRECT_RENDERING
 +
 #include glxclient.h
 #include glx_error.h
 #include xf86drm.h
 @@ -95,3 +98,5 @@ dri2_query_renderer_string(struct glx_screen *base, int 
 attribute,
 
return psc-rendererQuery-queryString(psc-driScreen, dri_attribute, 
 value);
 }
 +
 +#endif /* GLX_DIRECT_RENDERING */
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx/dri2: Respect --enable/disable-driglx-direct

[Jeremy Huddleston Sequoia]

On Feb 16, 2014, at 17:15, Emil Velikov emil.l.veli...@gmail.com 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 
 someone will have the time and patience to get it working again in the 
 near future.
 
 Hi Jeremy
 
 A while back, I was pondering on converting the apple glx to automake,
 but the biggest obstacle was the complete lack of testing (compile or
 runtime). iirc you have a tinderbox at x.org but it does not build mesa.
 Do you mind updating it ?

It does build mesa (and has for quite some time now), but it builds it for DRI 
(not Apple-DRI).  If you want me to add another target (mesa-apple or similar), 
let me know what configure options you want me to pass it to trigger your new 
way.

FWIW, the end goal was to eventually merge the codebases together so we could 
support both indirect GLX and Apple-DRI in the same libGL, but that never 
happened.

 I might get back to that over the next few weeks, so keep an eye open.

Awesome.  Thanks.

--Jeremy

 
 -Emil
 
 --Jeremy
 
 Sent from my iPad
 
 On Feb 13, 2014, at 8:29, Ian Romanick i...@freedesktop.org wrote:
 
 On 02/13/2014 02:11 AM, Daniel Martin wrote:
 Encapsulate the code in src/glx/dri2_query_renderer.c within a
 
   #ifdef GLX_DIRECT_RENDERING
 
 as done in src/glx/dri2*.c.
 
 I noticed a couple things, and I'm not sure what the right answer is.
 
 First, dri2_glx.c and dri3_glx.c use:
 
 #if defined(GLX_DIRECT_RENDERING)  !defined(GLX_USE_APPLEGL)
 
 but dri2.c uses
 
 #ifdef GLX_DIRECT_RENDERING
 
 I'm not sure why they're different or which is actually correct.
 
 Second, couldn't we just not build the file at all when
 GLX_DIRECT_RENDERING isn't selected?  Do something like the following in
 src/glx/Makefile.am:
 
 if HAVE_DRI2 || HAVE_DRI3
 libglx_la_SOURCES += \
 dri2_glx.c
 dri2.c
 dri2_query_renderer.c
 endif
 
 (and remove those files from the default libglx_la_SOURCES list, of course).
 
 Signed-off-by: Daniel Martin consume.no...@gmail.com
 ---
 ... compile it, when enabled only.
 
 Cheers,
   Daniel
 
 src/glx/dri2_query_renderer.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/src/glx/dri2_query_renderer.c b/src/glx/dri2_query_renderer.c
 index b50a202..3bc90c7 100644
 --- a/src/glx/dri2_query_renderer.c
 +++ b/src/glx/dri2_query_renderer.c
 @@ -20,6 +20,9 @@
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 * DEALINGS IN THE SOFTWARE.
 */
 +
 +#ifdef GLX_DIRECT_RENDERING
 +
 #include glxclient.h
 #include glx_error.h
 #include xf86drm.h
 @@ -95,3 +98,5 @@ dri2_query_renderer_string(struct glx_screen *base, int 
 attribute,
 
   return psc-rendererQuery-queryString(psc-driScreen, dri_attribute, 
 value);
 }
 +
 +#endif /* GLX_DIRECT_RENDERING */
 
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/3] glx/apple: Fixed glx context memory leak in case of failure.

[Jeremy Huddleston Sequoia]

Yep, looks right to me.

Reviewed-by: Jeremy Huddleston Sequoia: jerem...@apple.com

On Feb 10, 2014, at 07:57, Ian Romanick i...@freedesktop.org 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 +
 1 file changed, 1 insertion(+)
 
 diff --git a/src/glx/apple/apple_glx_context.c 
 b/src/glx/apple/apple_glx_context.c
 index 0bb25b4..8a6ded2 100644
 --- a/src/glx/apple/apple_glx_context.c
 +++ b/src/glx/apple/apple_glx_context.c
 @@ -142,6 +142,7 @@ apple_glx_create_context(void **ptr, Display * dpy, int 
 screen,
if (sharedac  !is_context_valid(sharedac)) {
   *errorptr = GLXBadContext;
   *x11errorptr = false;
 +  free(ac);
   return true;
}
 
 
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Recent master build failure (upgrade gl2ext.h / glDrawBuffersNV fallout)

[Jeremy Huddleston Sequoia]

Tested-by: Jeremy Huddleston Sequoia jerem...@apple.com

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.  On the failed attempt, only 
the following were regenerated:

python2  ../../../../src/mapi/mapi/mapi_abi.py \
--printer glapi --mode lib gl_and_es_API.xml  
../../../../src/mapi/glapi/glapi_mapi_tmp.h
python2  gl_enums.py -f ./gl_and_es_API.xml  ../../../../src/mesa/main/enums.c

After forcing everything to be regenerated via make clean, the build has 
progressed past the problem point.

--Jeremy


On Jul 10, 2012, at 8:19 PM, Kristian Høgsberg k...@bitplanet.net wrote:

 Hi Jeremy,
 
 I wasn't able to reproduce this problem when I committed the patch to
 update gl2ext.h, but I now figured out what triggers it.  It only
 happens when the asm stubs are disabled (either pass --disable-asm to
 configure or buid on an arch where we fallback to c stubs) and when
 shared glapi is disabled.
 
 Anyway, having reproduced it, I see that it's just glDrawBuffersNV
 that's the problem.  I assumed that this was just the first missing
 prototype and you didn't list the rest.  Digging further, it turns out
 that we don't generate entry points for GLES extension functions in
 general, which is why only glDrawBuffersNV is a problem.  The
 GL_NV_draw_buffers extension defines the entry point is in
 ARB_draw_buffers.xml which holds GL extensions too.  All other GLES
 extensions are listed in es_EXT.xml, which isn't used to generate the
 public entry points.
 
 So it looks like the real fix is the attached patch - move the
 GL_NV_draw_buffer definition to es_EXT.xml.  It does fix the error
 here and doesn't affect the other configuration combinations.
 
 Kristian
 
 On Tue, Jul 10, 2012 at 9:00 PM, Ian Romanick i...@freedesktop.org wrote:
 On 07/10/2012 02:39 PM, Jeremy Huddleston Sequoia wrote:
 
 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
 for 'glDrawBuffersNV' [-Werror=missing-prototypes]
 
 The commit mentions that this new failure is expected, so it would be nice
 if the fix for the original issue could now be included as well.
 
 
 This commit fixed another, even more catastrophic, problem.  The fix is to
 get a new gl2ext.h, when it's available, that fixes the original problem.
 In the mean time, I think tinderbox will remain broken. :(
 
 See http://lists.freedesktop.org/archives/mesa-dev/2012-July/023670.html
 
 --Jeremy
 
 3ed8d4285360047d78cfd3218ac4f8f325ae5d6e is the first bad commit
 commit 3ed8d4285360047d78cfd3218ac4f8f325ae5d6e
 Author: Kristian Høgsberg k...@bitplanet.net
 Date:   Tue Jul 3 20:47:04 2012 -0400
 
 GLES2: upgrade gl2ext.h to version 18099
 
 Redo this commit, and remove the inclusion of gl2ext.h
 from src/mapi/glapi/glapi_priv.h.  The include was added in
 8f3be339850ead96f9c6200db4e0db1f74e39d13 to fix a missing prototype
 for
 glDrawBuffersNV and others, but it's not possible to include both
 glext.h and gl2ext.h from the same file.
 
 I don't see the missing prototype here (with or without shared glapi)
 so I'm just removing the offending #include.
 
 Also, since we're redoing this, update to the most recent gl2ext.2.
 
 Signed-off-by: Kristian Høgsberg k...@bitplanet.net
 
 :04 04 3076bd4623a3727eb3690e39801c459ea2c08706
 7754f21c4cee87eb86ccb5ac8b9cbf810d0835ff M  include
 :04 04 0e602fff716a390251eacb932e7f406eb399e2e0
 ed4ecdd9127f4541ed0f148f3b97e6eefb6572df M  src
 
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 
 
 
 0001-mapi-Move-GL_NV_draw_buffers-extension-to-es_EXT.xml.patch

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Recent master build failure (upgrade gl2ext.h / glDrawBuffersNV fallout)

[Jeremy Huddleston Sequoia]

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 for 
'glDrawBuffersNV' [-Werror=missing-prototypes]

The commit mentions that this new failure is expected, so it would be nice if 
the fix for the original issue could now be included as well.

--Jeremy

3ed8d4285360047d78cfd3218ac4f8f325ae5d6e is the first bad commit
commit 3ed8d4285360047d78cfd3218ac4f8f325ae5d6e
Author: Kristian Høgsberg k...@bitplanet.net
Date:   Tue Jul 3 20:47:04 2012 -0400

GLES2: upgrade gl2ext.h to version 18099

Redo this commit, and remove the inclusion of gl2ext.h
from src/mapi/glapi/glapi_priv.h.  The include was added in
8f3be339850ead96f9c6200db4e0db1f74e39d13 to fix a missing prototype for
glDrawBuffersNV and others, but it's not possible to include both
glext.h and gl2ext.h from the same file.

I don't see the missing prototype here (with or without shared glapi)
so I'm just removing the offending #include.

Also, since we're redoing this, update to the most recent gl2ext.2.

Signed-off-by: Kristian Høgsberg k...@bitplanet.net

:04 04 3076bd4623a3727eb3690e39801c459ea2c08706 
7754f21c4cee87eb86ccb5ac8b9cbf810d0835ff M  include
:04 04 0e602fff716a390251eacb932e7f406eb399e2e0 
ed4ecdd9127f4541ed0f148f3b97e6eefb6572df M  src

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Doing 8.0.1 release?

[Jeremy Huddleston]

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.py -f 
../../src/mapi/glapi/gen/gl_and_es_API.xml -m remap_table -c es2  
main/api_exec_es2_dispatch.h
python -t -O -O ../../src/mapi/glapi/gen/remap_helper.py -f 
../../src/mapi/glapi/gen/gl_and_es_API.xml -c es1  
main/api_exec_es1_remap_helper.h
Traceback (most recent call last):
  File ../../src/mapi/glapi/gen/gl_table.py, line 28, in module
import gl_XML
  File 
/private/tmp/X11libs_trunk.roots/X11libs_trunk~obj/MesaLib/Mesa-8.0.3/src/mapi/glapi/gen/gl_XML.py,
 line 28, in module
import libxml2
ImportError: No module named libxml2
...

On Mar 19, 2012, at 13:03, Jakob Bornecrantz ja...@vmware.com wrote:

 - Original Message -
 
 On Mar 19, 2012, at 5:18 AM, Jakob Bornecrantz ja...@vmware.com
 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.c
 Traceback (most recent call last):
 File main/es_generator.py, line 26, in module
   import APIspecutil as apiutil
 File
 /private/tmp/X11libs_trunk.roots/X11libs_trunk~obj/mesa/Mesa-8.0.1/src/mesa/main/APIspecutil.py,
 line 28, in module
   import libxml2
 ImportError: No module named libxml2
 
 Isn't this similar to requiring flex/bison or do we
 ship those generated c files with the tarballs?
 
 Anybody feels like doing a patch, I'll do it later if not.
 
 The flex/bison generated source files are included in the tarball.
 Also, the python-generated files were included in 7.11.2, so it
 seems like something accidentally changed with 8.0.  Perhaps they're
 just being included if they were present in the git checkout when
 making the tarball.
 
 Fair enough, I'll make sure they are included. I got a bit
 sidetracked today, you should have the release in the morning.
 
 Cheers, Jakob.
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Doing 8.0.1 release?

[Jeremy Huddleston]

On May 24, 2012, at 11:36, Matt Turner matts...@gmail.com wrote:

 On Thu, May 24, 2012 at 2:20 PM, Jeremy Huddleston jerem...@apple.com 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 -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.py -f 
 ../../src/mapi/glapi/gen/gl_and_es_API.xml -m remap_table -c es2  
 main/api_exec_es2_dispatch.h
 python -t -O -O ../../src/mapi/glapi/gen/remap_helper.py -f 
 ../../src/mapi/glapi/gen/gl_and_es_API.xml -c es1  
 main/api_exec_es1_remap_helper.h
 Traceback (most recent call last):
  File ../../src/mapi/glapi/gen/gl_table.py, line 28, in module
import gl_XML
  File 
 /private/tmp/X11libs_trunk.roots/X11libs_trunk~obj/MesaLib/Mesa-8.0.3/src/mapi/glapi/gen/gl_XML.py,
  line 28, in module
import libxml2
 ImportError: No module named libxml2
 ...
 
 Odd. Is this actually a Mesa bug, or is the libxml2 python dependency
 not available on your system? Mesa depends on libxml2 with USE=python
 in Gentoo.

It's a packaging bug.  The generated source should be packaged with the tarball 
like other generated source (flex, bison, etc).  MesaLib tarballs have 
sometimes contained and sometimes missed these files, and I'd like it to be 
consistent.  Yes, I can use a python with that module, but the build system I 
use for XQuartz (namely a vanilla OS X) does not come with that python module, 
and I frequently forget to install it or change to a different python when I 
roll a build.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Use the proper feature test macros for strtod_l and strtof[_l].

[Jeremy Huddleston]

On May 11, 2012, at 08:58, Bryan Henderson bry...@giraffe-data.com 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 the config files.  It was added to darwin's config file, 
presumably because we supported the functionality it enabled.

mesa/configs $ grep _GNU_SOURCE *
darwin:DEFINES =  -D_DARWIN_C_SOURCE -DPTHREADS -D_GNU_SOURCE \
darwin:# -D_GNU_SOURCE  - for src/mesa/main ...
linux:  -D_BSD_SOURCE -D_GNU_SOURCE \
linux-dri:  -D_BSD_SOURCE -D_GNU_SOURCE \
linux-dri-xcb:  -D_BSD_SOURCE -D_GNU_SOURCE \
linux-egl:  -D_BSD_SOURCE -D_GNU_SOURCE \
linux-indirect: -D_BSD_SOURCE -D_GNU_SOURCE \
linux-osmesa:CFLAGS = -g -ansi -pedantic -fPIC -ffast-math -D_POSIX_SOURCE 
-D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS

 Used correctly, _GNU_SOURCE is something that gets
 defined by a #define in the source file which wants to declare itself as
 coded for nonstandard GNU features of libc.
 
 And so I have to ask about xlocale.h.  The original code says to include
 that if both _GNU_SOURCE and __APPLE__ are defined, which I presume is never.

Nope.  It's that way in configs/darwin.

 The current patch says to include it if both __GLIBC__ and __APPLE__ are
 defined, which again appears to be never.  I don't know what xlocale.h is;
 who needs it?


xlocale.h defines the extended locale support, like strtod_l and strtof_l.  The 
fact that it's done just for __APPLE__ is wrong because this is how the 
functionality is provided on recent FreeBSD 
(http://svnweb.freebsd.org/base/head/include/xlocale.h?revision=232498view=markup).

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Use the proper feature test macros for strtod_l and strtof[_l].

[Jeremy Huddleston]

No, that's not right.  We don't use glibc, and we support strtod_l, strtof_l, 
and strtof.  This change would do the wrong thing for __APPLE__.  Perhaps 
something more like this:


#if defined(__APPLE__) || (defined(__GLIBC__)  __GLIBC__ = 2  
__GLIBC_MINOR__  2  !defined(__CYGWIN__)  !defined(__FreeBSD__)  
!defined(__HAIKU__))
  #define HAVE_STRTOD_L 1
#else
  #define HAVE_STRTOD_L 0
#endif
...
#if HAVE_STRTOD_L
#include locale.h
#ifdef __APPLE__
#include xlocale.h
#endif
#endif

etc...

On May 9, 2012, at 12:52 PM, Kenneth Graunke kenn...@whitecape.org wrote:

 From: Bryan Henderson bry...@giraffe-data.com
 
 [v2/Kayden: rebased version of Bryan's original patch from:
 https://bugs.freedesktop.org/show_bug.cgi?id=33447]
 
 Cc: Jeremy Huddleston jerem...@apple.com
 Cc: Chad Versace chad.vers...@linux.intel.com
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33447
 Signed-off-by: Kenneth Graunke kenn...@whitecape.org
 ---
 src/glsl/strtod.c   |   11 +++
 src/mesa/main/imports.c |   22 +-
 2 files changed, 24 insertions(+), 9 deletions(-)
 
 Hey guys,
 
 I just got pinged on IRC by someone trying to build Mesa with ucLibc,
 which doesn't support strtod_l or strtof_l.  I found this 1+ year old
 patch from Bryan on Bugzilla which fixed up the feature macros to only
 use locale_t on glibc, and figured it would help
 
 I rebased it against master (adding the Haiku and Android changes), and
 figured I'd send it out to the list for review.
 
 Jeremy: Does this look right?  I wasn't sure if Apple used glibc or not,
and was afraid this might break stuff there.
 
 Chad: Why do we have !ANDROID for strtof_l but not strtod_l?  Oversight?
  Or does it actually support strtod_l?
 
 Thanks!
 --Ken
 
 diff --git a/src/glsl/strtod.c b/src/glsl/strtod.c
 index a876e13..876ed21 100644
 --- a/src/glsl/strtod.c
 +++ b/src/glsl/strtod.c
 @@ -26,7 +26,7 @@
 
 #include stdlib.h
 
 -#ifdef _GNU_SOURCE
 +#ifdef __GLIBC__
 #include locale.h
 #ifdef __APPLE__
 #include xlocale.h
 @@ -35,7 +35,11 @@
 
 #include strtod.h
 
 -
 +#if defined(__GLIBC__)  __GLIBC__ = 2  __GLIBC_MINOR__  2  
 !defined(__CYGWIN__)  !defined(__FreeBSD__)  !defined(__HAIKU__)
 +  #define HAVE_STRTOD_L 1
 +#else
 +  #define HAVE_STRTOD_L 0
 +#endif
 
 /**
  * Wrapper around strtod which uses the C locale so the decimal
 @@ -44,8 +48,7 @@
 double
 glsl_strtod(const char *s, char **end)
 {
 -#if defined(_GNU_SOURCE)  !defined(__CYGWIN__)  !defined(__FreeBSD__)  
 \
 -   !defined(__HAIKU__)
 +#if HAVE_STRTOD_L
static locale_t loc = NULL;
if (!loc) {
   loc = newlocale(LC_CTYPE_MASK, C, NULL);
 diff --git a/src/mesa/main/imports.c b/src/mesa/main/imports.c
 index 2d592a6..c145101 100644
 --- a/src/mesa/main/imports.c
 +++ b/src/mesa/main/imports.c
 @@ -42,20 +42,33 @@
  * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  */
 
 -
 +#define _XOPEN_SOURCE 600   /* We use strtof/strtof_l */
 
 #include imports.h
 #include context.h
 #include mtypes.h
 #include version.h
 
 -#ifdef _GNU_SOURCE
 +#ifdef __GLIBC__
 #include locale.h
 #ifdef __APPLE__
 #include xlocale.h
 #endif
 #endif
 
 +#if defined(__GLIBC__)  __GLIBC__ = 2  __GLIBC_MINOR__  2  
 !defined(__CYGWIN__)  !defined(__FreeBSD__)  !defined(ANDROID)  
 !defined(__HAIKU__)
 +  #define HAVE_STRTOF_L 1
 +#else
 +  #define HAVE_STRTOF_L 0
 +#endif
 +
 +#if defined(__GLIBC__)
 +  #define HAVE_STRTOF 1
 +  /* True at least as long as we declare _XOPEN_SOURCE = 600 */
 +#else
 +  #define HAVE_STRTOF 0
 +#endif
 +
 
 #ifdef WIN32
 #define vsnprintf _vsnprintf
 @@ -761,14 +774,13 @@ _mesa_strdup( const char *s )
 float
 _mesa_strtof( const char *s, char **end )
 {
 -#if defined(_GNU_SOURCE)  !defined(__CYGWIN__)  !defined(__FreeBSD__)  
 \
 -   !defined(ANDROID)  !defined(__HAIKU__)
 +#if HAVE_STRTOF_L
static locale_t loc = NULL;
if (!loc) {
   loc = newlocale(LC_CTYPE_MASK, C, NULL);
}
return strtof_l(s, end, loc);
 -#elif defined(_ISOC99_SOURCE) || (defined(_XOPEN_SOURCE)  _XOPEN_SOURCE = 
 600)
 +#elif HAVE_STRTOF
return strtof(s, end);
 #else
return (float)strtod(s, end);
 -- 
 1.7.10.1
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Doing 8.0.1 release?

[Jeremy Huddleston]

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 module
import APIspecutil as apiutil
  File 
/private/tmp/X11libs_trunk.roots/X11libs_trunk~obj/mesa/Mesa-8.0.1/src/mesa/main/APIspecutil.py,
 line 28, in module
import libxml2
ImportError: No module named libxml2



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Recent mesa changes are causing tinderbox to fail

[Jeremy Huddleston]

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 one of:
 
 glx: Add __glX_send_client_info super function
 glx: Initial implementation of glXCreateContextAttribsARB
 
 Here's the tinderbox failure:
 http://tinderbox.x.org/builds/2012-01-02-0028/logs/xdriinfo/#configure
 
 Here's the relevant section from config.log:
 configure:9243: gcc -std=gnu99 -o conftest -O0 -pipe -Wall -Wextra 
 -Wno-sign-compare -Wno-unused-parameter -Wno-missing-field-initializers 
 -Wformat=2  -D_XOPEN_SOURCE=700 -D_BSD_SOURCE -D_GNU_SOURCE 
 -I/var/tmp/jhbuild/include 
 -I/home/jeremy/src/freedesktop/jhbuild/external/build/include 
 -L/var/tmp/jhbuild/lib  conftest.c -lGL -L/var/tmp/jhbuild/lib -lX115
 /var/tmp/jhbuild/lib/libGL.so: undefined reference to 
 `xcb_glx_create_context_attribs_arb_checked'
 /var/tmp/jhbuild/lib/libGL.so: undefined reference to 
 `xcb_glx_set_client_info_2arb'
 /var/tmp/jhbuild/lib/libGL.so: undefined reference to `XGetXCBConnection'
 /var/tmp/jhbuild/lib/libGL.so: undefined reference to 
 `xcb_glx_set_client_info_arb'
 /var/tmp/jhbuild/lib/libGL.so: undefined reference to `xcb_glx_client_info'
 collect2: ld returned 1 exit status
 
 So it looks like libGL.so isn't linked against libxcb-glx.so and 
 libX11-xcb.so:
 
 I think this is because Mesa wasn't built with --enable-xcb.  This used to be 
 optional, but it is not now.  There's a patch on the mesa-dev list that 
 should fix.

Can we get this patchset merged soon?  I don't like seeing failing tinderboxen 
=(

http://tinderbox.x.org/builds/2012-01-08-0023/logs/libdrm/#build




___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Recent mesa changes are causing tinderbox to fail

[Jeremy Huddleston]

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 tinderbox failure:
http://tinderbox.x.org/builds/2012-01-02-0028/logs/xdriinfo/#configure

Here's the relevant section from config.log:
configure:9243: gcc -std=gnu99 -o conftest -O0 -pipe -Wall -Wextra 
-Wno-sign-compare -Wno-unused-parameter -Wno-missing-field-initializers 
-Wformat=2  -D_XOPEN_SOURCE=700 -D_BSD_SOURCE -D_GNU_SOURCE 
-I/var/tmp/jhbuild/include 
-I/home/jeremy/src/freedesktop/jhbuild/external/build/include 
-L/var/tmp/jhbuild/lib  conftest.c -lGL -L/var/tmp/jhbuild/lib -lX115
/var/tmp/jhbuild/lib/libGL.so: undefined reference to 
`xcb_glx_create_context_attribs_arb_checked'
/var/tmp/jhbuild/lib/libGL.so: undefined reference to 
`xcb_glx_set_client_info_2arb'
/var/tmp/jhbuild/lib/libGL.so: undefined reference to `XGetXCBConnection'
/var/tmp/jhbuild/lib/libGL.so: undefined reference to 
`xcb_glx_set_client_info_arb'
/var/tmp/jhbuild/lib/libGL.so: undefined reference to `xcb_glx_client_info'
collect2: ld returned 1 exit status

So it looks like libGL.so isn't linked against libxcb-glx.so and libX11-xcb.so:

$ ldd /var/tmp/jhbuild/lib/libGL.so
linux-vdso32.so.1 =  (0x0010)
libX11.so.6 = /usr/lib/powerpc-linux-gnu/libX11.so.6 (0x6fdc5000)
libXext.so.6 = /usr/lib/powerpc-linux-gnu/libXext.so.6 (0x6fd91000)
libXdamage.so.1 = /usr/lib/powerpc-linux-gnu/libXdamage.so.1 
(0x6fd6e000)
libXfixes.so.3 = /usr/lib/powerpc-linux-gnu/libXfixes.so.3 (0x6fd48000)
libXxf86vm.so.1 = /usr/lib/powerpc-linux-gnu/libXxf86vm.so.1 
(0x6fd22000)
libdrm.so.2 = /usr/lib/powerpc-linux-gnu/libdrm.so.2 (0x6fcf7000)
libpthread.so.0 = /lib/powerpc-linux-gnu/libpthread.so.0 (0x6fcbd000)
libdl.so.2 = /lib/powerpc-linux-gnu/libdl.so.2 (0x6fc99000)
libc.so.6 = /lib/powerpc-linux-gnu/libc.so.6 (0x6fb14000)
libxcb.so.1 = /usr/lib/powerpc-linux-gnu/libxcb.so.1 (0x6fada000)
librt.so.1 = /lib/powerpc-linux-gnu/librt.so.1 (0x6fab1000)
/lib/ld.so.1 (0x2020f000)
libXau.so.6 = /usr/lib/powerpc-linux-gnu/libXau.so.6 (0x6fa8e000)
libXdmcp.so.6 = /usr/lib/powerpc-linux-gnu/libXdmcp.so.6 (0x6fa68000)


It looks like you need to add x11-xcb and xcb-glx to libGL's pkg-config 
dependencies.



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 06/13] glx: Make __glXSendError available in non-Apple builds

[Jeremy Huddleston]

6, 7, and 13 look good to me, but I haven't tested them yet.

Reviewed-by: Jeremy Huddleston jerem...@apple.com

On Dec 16, 2011, at 11:55 AM, Ian Romanick wrote:

 From: Ian Romanick ian.d.roman...@intel.com
 
 Signed-off-by: Ian Romanick ian.d.roman...@intel.com
 Cc: Jeremy Huddleston jerem...@apple.com
 ---
 src/glx/Makefile  |1 +
 src/glx/apple/Makefile|2 +-
 src/glx/apple/glx_error.c |   67 -
 src/glx/apple/glx_error.h |   33 --
 src/glx/glx_error.c   |   67 +
 src/glx/glx_error.h   |   33 ++
 6 files changed, 102 insertions(+), 101 deletions(-)
 delete mode 100644 src/glx/apple/glx_error.c
 delete mode 100644 src/glx/apple/glx_error.h
 create mode 100644 src/glx/glx_error.c
 create mode 100644 src/glx/glx_error.h
 
 diff --git a/src/glx/Makefile b/src/glx/Makefile
 index dd96973..183ffb1 100644
 --- a/src/glx/Makefile
 +++ b/src/glx/Makefile
 @@ -15,6 +15,7 @@ SOURCES = \
 glxconfig.c \
 glxcmds.c \
 glxcurrent.c \
 +   glx_error.c \
 glxext.c \
 glxextensions.c \
 indirect_glx.c \
 diff --git a/src/glx/apple/Makefile b/src/glx/apple/Makefile
 index 6868d28..66e6658 100644
 --- a/src/glx/apple/Makefile
 +++ b/src/glx/apple/Makefile
 @@ -39,7 +39,7 @@ SOURCES = \
   ../compsize.c \
   ../glxconfig.c \
   glx_empty.c \
 - glx_error.c \
 + ../glx_error.c \
   ../glx_pbuffer.c \
   ../glx_query.c \
   ../glxcmds.c \
 diff --git a/src/glx/apple/glx_error.c b/src/glx/apple/glx_error.c
 deleted file mode 100644
 index d44a80c..000
 --- a/src/glx/apple/glx_error.c
 +++ /dev/null
 @@ -1,67 +0,0 @@
 -/*
 - Copyright (c) 2009 Apple Inc.
 - 
 - Permission is hereby granted, free of charge, to any person
 - obtaining a copy of this software and associated documentation files
 - (the Software), to deal in the Software without restriction,
 - including without limitation the rights to use, copy, modify, merge,
 - publish, distribute, sublicense, and/or sell copies of the Software,
 - and to permit persons to whom the Software is furnished to do so,
 - subject to the following conditions:
 - 
 - The above copyright notice and this permission notice shall be
 - included in all copies or substantial portions of the Software.
 - 
 - THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
 - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 - MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 - NONINFRINGEMENT.  IN NO EVENT SHALL THE ABOVE LISTED COPYRIGHT
 - HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 - WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 - OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 - DEALINGS IN THE SOFTWARE.
 - 
 - Except as contained in this notice, the name(s) of the above
 - copyright holders shall not be used in advertising or otherwise to
 - promote the sale, use or other dealings in this Software without
 - prior written authorization.
 -*/
 -#include stdbool.h
 -#include assert.h
 -#include X11/Xlibint.h
 -#include X11/extensions/extutil.h
 -#include X11/extensions/Xext.h
 -#include glxclient.h
 -#include glx_error.h
 -
 -void
 -__glXSendError(Display * dpy, int errorCode, unsigned long resourceID,
 -   unsigned long minorCode, bool coreX11error)
 -{
 -   struct glx_display *glx_dpy = __glXInitialize(dpy);
 -   struct glx_context *gc = __glXGetCurrentContext();
 -   xError error;
 -
 -   assert(glx_dpy);
 -   assert(gc);
 -
 -   LockDisplay(dpy);
 -
 -   error.type = X_Error;
 -
 -   if (coreX11error) {
 -  error.errorCode = errorCode;
 -   }
 -   else {
 -  error.errorCode = glx_dpy-codes-first_error + errorCode;
 -   }
 -
 -   error.sequenceNumber = dpy-request;
 -   error.resourceID = resourceID;
 -   error.minorCode = minorCode;
 -   error.majorCode = gc ? gc-majorOpcode : 0;
 -
 -   _XError(dpy, error);
 -
 -   UnlockDisplay(dpy);
 -}
 diff --git a/src/glx/apple/glx_error.h b/src/glx/apple/glx_error.h
 deleted file mode 100644
 index 6ba2f85..000
 --- a/src/glx/apple/glx_error.h
 +++ /dev/null
 @@ -1,33 +0,0 @@
 -/*
 - Copyright (c) 2009 Apple Inc.
 - 
 - Permission is hereby granted, free of charge, to any person
 - obtaining a copy of this software and associated documentation files
 - (the Software), to deal in the Software without restriction,
 - including without limitation the rights to use, copy, modify, merge,
 - publish, distribute, sublicense, and/or sell copies of the Software,
 - and to permit persons to whom the Software is furnished to do so,
 - subject to the following conditions:
 - 
 - The above copyright notice and this permission notice shall be
 - included in all copies or substantial portions of the Software.
 - 
 - THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
 - EXPRESS OR IMPLIED, INCLUDING

Re: [Mesa-dev] XCB-only GLX protocol?

[Jeremy Huddleston]

On Nov 28, 2011, at 6:56 PM, Jakob Bornecrantz wrote:

 On Mon, Nov 28, 2011 at 3:13 AM, Ian Romanick i...@freedesktop.org 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 to keep supporting non-XCB protocol?  Are there any
 platforms that can't / don't use XCB for X protocol?
 
 I'm not planning to gut any non-XCB code yet, but that would happen
 eventually.  I just don't want to implement all of the protocol twice. That
 seems like an unnecessary hassle.
 
 Opinions?
 
 No problems with me but I think you should get sign-off from various
 platform stakeholders before doing it (BSD, Mac, Cygwin). Jeremy and
 who does cygwin?

XQuartz transitioned to XCB a few releases ago, and we're fully committed to 
it.  I bless any Xlib code that you want to nuke in the transition to XCB!!

We may have some difficulty in the src/glx/apple code since AppleDRI and 
AppleWM are Xlib-only.  I'm hoping to eventually move away from these 
protocols, and I'll just deal with the fallout as it happens.  Please CC me on 
reviews with a branch I can merge to test the changes before they are merged 
into master.

Thanks


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

[Jeremy Huddleston]

 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 project are under
 GPLv3+, as described in COPYINGv3; these files are used for building
 and installing Autoconf, but are not present in the installed
 programs.  The entire Autoconf project will move to GPLv3+ when the
 exception statements have been reformulated in terms of the Additional
 Permissions as described in section 7 of GPLv3.
 
 
 That alone means no 2.62 for me while I'm doing Apple-fu.
 
 The GPL only applies to redistribution, not use.
 
 _Users_ of autoconf (like you, as a Mesa dev), _projects_ that use
 autoconf (like Mesa), _restributors_ of autoconf-using projects, and
 _end-users_ of such projects do not need to accept the GPL at all,
 v3 or otherwise, and are not affected by its terms.

In order for me to *use* autoconf in our build system, I need to *use* the 
version that we build/ship.

 So unless you're sending copies of autoconf _itself_ (not Mesa) to
 other people,

We are distributing autoconf.  Apple's autoconf is stuck at 2.61 and not able 
to go up.  When building mesa in our build system, we use our autoconf.  
Furthermore, as stated before by Alan, I'm restricted from *using* GPLv3 
software.  I direct you to public statements from Apple by people who are paid 
to make public statements.  I just do what the lawyers say and no amount of 
arguing about the license will change it.

With my personal hat on, I use GPLv3 software, I contribute patches to GPLv3 
projects, but I will never release software as GPLv3 because of the headaches 
it causes.

 the version of GPL used in autoconf simply does not
 apply to you.  [Again, see below for more detail]

It applies to us in what version of autoconf we can redistribute and thus which 
version we can use.

 As the GPLv3 is widely used, I think this is an issue that will
 come up again, so it's worth some discussion.
 
 It's not that simple.  We should not thrust acceptance of a new
 license down our users throats.  The existence of GPLv3 is what
 prompted Gentoo to add support to portage to allow users to block
 installing packages based on license.  Clearly it's not just one or
 two companies that are afraid of it.
 
 Again, using autoconf _does not require users to accept the GPLv3,
 nor does it place them under any restrictions due to the GPL[v3]_.
 
 ...

 Maybe I'm wrong somewhere, but _please_ point out _where_, rather than
 using vague handwaving.


I'm not trying to handwave.  I'm just repeating to you what I've been told 
and the reasons for it.  I understand that you disagree with those reasons, but 
IANAL and am not qualified to respond to these points in detail on behalf of 
Apple.  I wish I could give you the answers you seek, but that kind of 
statement is well above my pay grade.

--Jeremy

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/

[Jeremy Huddleston]

On Sep 28, 2011, at 23:28, Miles Bader wrote:

 2011/9/29 Alan Coopersmith alan.coopersm...@oracle.com:
 _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 patent license grant not fitting well with the current mobile phone
 environment in which every manufacturer is involved in more patent
 infringement lawsuits  countersuits than anyone wants to consider.
 
 Er, sure, but that brings up my second point:  the GPL restricts
 redistribution, not use, so you are not required to accept it to use
 GPL tools.

Again, mirroring Alan's comment.  IANAL.  I just do what the Lawyers say.  I am 
told not to touch GLPv3 with a 10 foot poll while I have my Apple hat on, so I 
go beyond that and stay 10 miles away from GPLv3 while I have my Apple hat on.

 So the original complaint, that he is forced to accept the GPLv3 to
 use autoconf seems a little confused.  [of course certainly it's
 possible that _I'm_ confused, or there's a subtlety I'm missing.]

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 project are under
GPLv3+, as described in COPYINGv3; these files are used for building
and installing Autoconf, but are not present in the installed
programs.  The entire Autoconf project will move to GPLv3+ when the
exception statements have been reformulated in terms of the Additional
Permissions as described in section 7 of GPLv3.


That alone means no 2.62 for me while I'm doing Apple-fu.

 Since most developers on the X  Mesa projects are doing it as part of
 our paid employment, we are subject to the constraints of the licenses
 our employers are willing to accept, and no amount of logic or arguments
 from outsiders can trump company policy.
 
 As the GPLv3 is widely used, I think this is an issue that will come
 up again, so it's worth some discussion.

It's not that simple.  We should not thrust acceptance of a new license down 
our users throats.  The existence of GPLv3 is what prompted Gentoo to add 
support to portage to allow users to block installing packages based on 
license.  Clearly it's not just one or two companies that are afraid of it.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: Ensure that r300 compiler files only appear once in the tarballs

[Jeremy Huddleston]

That looks like it:

Reviewed-by: Jeremy Huddleston jerem...@apple.com
Tested-by: Jeremy Huddleston jerem...@apple.com

You can probably revert the --dereference one as well.

On Jul 26, 2011, at 12:09 PM, Ian Romanick wrote:

 From: Ian Romanick ian.d.roman...@intel.com
 
 Cc: Jeremy Huddleston jerem...@freedesktop.org
 Cc: Andreas Radke a.ra...@arcor.de
 ---
 Please let me know if this patch fixes the issue once and for all.
 
 Makefile |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)
 
 diff --git a/Makefile b/Makefile
 index c142a93..48e779c 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -285,9 +285,6 @@ MAIN_FILES = \
   $(DIRECTORY)/src/mesa/drivers/osmesa/descrip.mms\
   $(DIRECTORY)/src/mesa/drivers/osmesa/osmesa.def \
   $(DIRECTORY)/src/mesa/drivers/osmesa/*.[ch] \
 - $(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/*.[ch]  \
 - $(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/Makefile\
 - $(DIRECTORY)/src/mesa/drivers/dri/r300/compiler/SConscript  \
   $(DIRECTORY)/src/mesa/drivers/windows/*/*.[ch]  \
   $(DIRECTORY)/src/mesa/drivers/windows/*/*.def   \
   $(DIRECTORY)/src/mesa/drivers/x11/Makefile  \
 @@ -393,6 +390,7 @@ DRI_FILES = \
   $(DIRECTORY)/src/mesa/drivers/dri/*/*/*.[chS]   \
   $(DIRECTORY)/src/mesa/drivers/dri/*/Makefile\
   $(DIRECTORY)/src/mesa/drivers/dri/*/*/Makefile  \
 + $(DIRECTORY)/src/mesa/drivers/dri/*/*/SConscript\
   $(DIRECTORY)/src/mesa/drivers/dri/*/Doxyfile
 
 SGI_GLU_FILES = \
 -- 
 1.7.4.4
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] r300 problems in the 7.10.3 and 7.11 tarballs

[Jeremy Huddleston]

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://trac.macports.org/ticket/30058

There doesn't seem to be a good solution (I don't count zip) other than rolling 
a new tarball (which will be nice to collect the rest of the 7.10 branch 
patches anyway):

$ tar -tvjf MesaLib-7.10.3.tar.bz2 | grep r300/compiler/memory_pool.c
-rw-rw-r--  0 idridr  2671 May 20 01:31 
Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c
hrw-rw-r--  0 idridr 0 May 20 01:31 
Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c link to 
Mesa-7.10.3/src/mesa/drivers/dri/r300/compiler/memory_pool.c

The issue partly exists in 7.11-rc2, but we don't see it because it's just 
including the file twice rather than including a symlink to itself:

$ tar -tjvf MesaLib-7.11-rc2.tar.bz2 | grep memory_pool.c
-rw-rw-r--  0 idridr  2671 Jul  8 18:37 
Mesa-7.11-rc2/src/mesa/drivers/dri/r300/compiler/memory_pool.c
-rw-rw-r--  0 idridr  2671 Jul  8 18:37 
Mesa-7.11-rc2/src/mesa/drivers/dri/r300/compiler/memory_pool.c


On Jun 17, 2011, at 9:41 AM, Andreas Radke wrote:

 If you'd check the output of the tar check you'd see files linked to
 itself that seems to break it. That wasn't the case in the releases
 before. It's all related to r300.
 
 There's probably something wrong with links pointing to the source file.
 
 BTW: I've used the 'zip' source to build our package. gz+bz2 are broken for 
 me.
 
 -Andy
 
 [andyrtr@workstation64 ~]$ LANG=C tar -tvf  
 ~/arch64/sources/MesaLib-7.10.3.tar.bz2 | grep ^h | sed -e s: 
 Mesa-7.10.3/src/mesa/drivers/dri/: :g
 hrw-rw-r-- idr/idr   0 2011-05-20 10:31 r300/compiler/memory_pool.c 
 link to r300/compiler/memory_pool.c
 hrw-r--r-- idr/idr   0 2010-10-05 18:56 r300/compiler/memory_pool.h 
 link to r300/compiler/memory_pool.h
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 r300/compiler/r300_fragprog.c 
 link to r300/compiler/r300_fragprog.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/r300_fragprog_emit.c link to r300/compiler/r300_fragprog_emit.c
 hrw-r--r-- idr/idr   0 2010-10-19 19:58 r300/compiler/r300_fragprog.h 
 link to r300/compiler/r300_fragprog.h
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/r300_fragprog_swizzle.c link to 
 r300/compiler/r300_fragprog_swizzle.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/r300_fragprog_swizzle.h link to 
 r300/compiler/r300_fragprog_swizzle.h
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 r300/compiler/r3xx_fragprog.c 
 link to r300/compiler/r3xx_fragprog.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 r300/compiler/r3xx_vertprog.c 
 link to r300/compiler/r3xx_vertprog.c
 hrw-r--r-- idr/idr   0 2010-10-19 19:58 
 r300/compiler/r3xx_vertprog_dump.c link to r300/compiler/r3xx_vertprog_dump.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 r300/compiler/r500_fragprog.c 
 link to r300/compiler/r500_fragprog.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/r500_fragprog_emit.c link to r300/compiler/r500_fragprog_emit.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 r300/compiler/r500_fragprog.h 
 link to r300/compiler/r500_fragprog.h
 hrw-r--r-- idr/idr   0 2010-12-14 22:43 r300/compiler/radeon_code.c 
 link to r300/compiler/radeon_code.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 r300/compiler/radeon_code.h 
 link to r300/compiler/radeon_code.h
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/radeon_compiler.c link to r300/compiler/radeon_compiler.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/radeon_compiler.h link to r300/compiler/radeon_compiler.h
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/radeon_compiler_util.c link to 
 r300/compiler/radeon_compiler_util.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/radeon_compiler_util.h link to 
 r300/compiler/radeon_compiler_util.h
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/radeon_dataflow.c link to r300/compiler/radeon_dataflow.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/radeon_dataflow_deadcode.c link to 
 r300/compiler/radeon_dataflow_deadcode.c
 hrw-rw-r-- idr/idr   0 2011-05-20 10:33 
 r300/compiler/radeon_dataflow.h link to r300/compiler/radeon_dataflow.h
 hrw-r--r-- idr/idr   0 2011-01-02 23:58 
 r300/compiler/radeon_dataflow_swizzles.c link to 
 r300/compiler/radeon_dataflow_swizzles.c
 hrw-r--r-- idr/idr   0 2010-12-14 22:43 
 r300/compiler/radeon_emulate_branches.c link to 
 r300/compiler/radeon_emulate_branches.c
 hrw-r--r-- idr/idr   0 2010-10-19 19:58 
 r300/compiler/radeon_emulate_branches.h link to 
 

Re: [Mesa-dev] r300 problems in the 7.10.3 and 7.11 tarballs

[Jeremy Huddleston]

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 as the 7.11-rc2 tarballs.  The files are included twice:

$ tar -tjvf mesa/MesaLib-7.11-rc3.tar.bz2 | grep memory_pool.c
-rw-rw-r--  0 idridr  2671 Jul  8 18:37 
Mesa-7.11-rc3/src/mesa/drivers/dri/r300/compiler/memory_pool.c
-rw-rw-r--  0 idridr  2671 Jul  8 18:37 
Mesa-7.11-rc3/src/mesa/drivers/dri/r300/compiler/memory_pool.c

  I added the
 - --dereference option to tar to make it not include the symlinks.  If
 that works, I'll cherry-pick the change to 7.10.  If that doesn't work,
 can you suggest a better fix?

That works to not include them as bogus symlinks, but why not just only include 
the files once?  Why are they being listed twice?

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 2/4 resend] glx: Allow a context-specific fallback for glXGetProcAddress

[Jeremy Huddleston]

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 jerem...@apple.com
---
 src/glx/applegl_glx.c  |9 +
 src/glx/dri2_glx.c |1 +
 src/glx/dri_glx.c  |1 +
 src/glx/drisw_glx.c|1 +
 src/glx/glxclient.h|2 +-
 src/glx/glxcmds.c  |6 ++
 src/glx/indirect_glx.c |1 +
 7 files changed, 20 insertions(+), 1 deletions(-)

diff --git origin/master/src/glx/applegl_glx.c 
origin/master/src/glx/applegl_glx.c
index 4bf4672..8766c88 100644
--- origin/master/src/glx/applegl_glx.c
+++ origin/master/src/glx/applegl_glx.c
@@ -34,10 +34,12 @@
 #if defined(GLX_USE_APPLEGL)
 
 #include stdbool.h
+#include dlfcn.h
 
 #include glxclient.h
 #include apple_glx_context.h
 #include apple_glx.h
+#include apple_cgl.h
 #include glx_error.h
 
 static void
@@ -82,6 +84,12 @@ applegl_wait_x(struct glx_context *gc)
apple_glx_waitx(dpy, gc-driContext);
 }
 
+static void *
+applegl_get_proc_address(const char *symbol)
+{
+   return dlsym(apple_cgl_get_dl_handle(), symbol);
+}
+
 static const struct glx_context_vtable applegl_context_vtable = {
applegl_destroy_context,
applegl_bind_context,
@@ -91,6 +99,7 @@ static const struct glx_context_vtable applegl_context_vtable 
= {
DRI_glXUseXFont,
NULL, /* bind_tex_image, */
NULL, /* release_tex_image, */
+   applegl_get_proc_address,
 };
 
 struct glx_context *
diff --git origin/master/src/glx/dri2_glx.c origin/master/src/glx/dri2_glx.c
index e7c18ff..80e4da3 100644
--- origin/master/src/glx/dri2_glx.c
+++ origin/master/src/glx/dri2_glx.c
@@ -767,6 +767,7 @@ static const struct glx_context_vtable dri2_context_vtable 
= {
DRI_glXUseXFont,
dri2_bind_tex_image,
dri2_release_tex_image,
+   NULL, /* get_proc_address */
 };
 
 static void
diff --git origin/master/src/glx/dri_glx.c origin/master/src/glx/dri_glx.c
index d59784c..6f3b2b8 100644
--- origin/master/src/glx/dri_glx.c
+++ origin/master/src/glx/dri_glx.c
@@ -558,6 +558,7 @@ static const struct glx_context_vtable dri_context_vtable = 
{
DRI_glXUseXFont,
NULL,
NULL,
+   NULL, /* get_proc_address */
 };
 
 static struct glx_context *
diff --git origin/master/src/glx/drisw_glx.c origin/master/src/glx/drisw_glx.c
index 0075695..07d4955 100644
--- origin/master/src/glx/drisw_glx.c
+++ origin/master/src/glx/drisw_glx.c
@@ -296,6 +296,7 @@ static const struct glx_context_vtable drisw_context_vtable 
= {
DRI_glXUseXFont,
NULL,
NULL,
+   NULL, /* get_proc_address */
 };
 
 static struct glx_context *
diff --git origin/master/src/glx/glxclient.h origin/master/src/glx/glxclient.h
index 88a6edd..0641528 100644
--- origin/master/src/glx/glxclient.h
+++ origin/master/src/glx/glxclient.h
@@ -224,7 +224,7 @@ struct glx_context_vtable {
  GLXDrawable drawable,
  int buffer, const int *attrib_list);
void (*release_tex_image)(Display * dpy, GLXDrawable drawable, int buffer);
-   
+   void * (*get_proc_address)(const char *symbol);
 };
 
 extern void
diff --git origin/master/src/glx/glxcmds.c origin/master/src/glx/glxcmds.c
index cd8bc97..e6816ea 100644
--- origin/master/src/glx/glxcmds.c
+++ origin/master/src/glx/glxcmds.c
@@ -2521,6 +2521,12 @@ _X_EXPORT void (*glXGetProcAddressARB(const GLubyte * 
procName)) (void)
 #endif
   if (!f)
  f = (gl_function) _glapi_get_proc_address((const char *) procName);
+  if (!f) {
+ struct glx_context *gc = __glXGetCurrentContext();
+  
+ if (gc != NULL  gc-vtable-get_proc_address != NULL)
+f = gc-vtable-get_proc_address((const char *) procName);
+  }
}
return f;
 }
diff --git origin/master/src/glx/indirect_glx.c 
origin/master/src/glx/indirect_glx.c
index b4f16c7..7b542dd 100644
--- origin/master/src/glx/indirect_glx.c
+++ origin/master/src/glx/indirect_glx.c
@@ -335,6 +335,7 @@ static const struct glx_context_vtable 
indirect_context_vtable = {
indirect_use_x_font,
indirect_bind_tex_image,
indirect_release_tex_image,
+   NULL, /* get_proc_address */
 };
 
 /**
-- 
1.7.5.4


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/4 resend] glx: Destroy the old context only after the new one has been bound

[Jeremy Huddleston]

This fixes a regression introduced by 49d7e48b33264d94e30af6129c281b6acafa9427

Signed-off-by: Jeremy Huddleston jerem...@apple.com
---
 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
index 9eb7d5a..0f39ee5 100644
--- origin/master/src/glx/glxcurrent.c
+++ origin/master/src/glx/glxcurrent.c
@@ -255,13 +255,6 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
   if (--oldGC-thread_refcount == 0) {
 oldGC-vtable-unbind(oldGC, gc);
 oldGC-currentDpy = 0;
-
-if (oldGC-xid == None  oldGC != gc) {
-   /* We are switching away from a context that was
-* previously destroyed, so we need to free the memory
-* for the old handle. */
-   oldGC-vtable-destroy(oldGC);
-}
   }
}
 
@@ -279,6 +272,13 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
   __glXSetCurrentContextNull();
}
 
+   if (oldGC-thread_refcount == 0  oldGC != dummyContext  oldGC-xid == 
None) {
+  /* We are switching away from a context that was
+   * previously destroyed, so we need to free the memory
+   * for the old handle. */
+  oldGC-vtable-destroy(oldGC);
+   }
+
__glXUnlock();
 
if (ret) {
-- 
1.7.5.4


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] PATCH 1/4 resend] glapi: Update specs to correctly list FramebufferTextureLayerARB as an alias of FramebufferTextureLayerEXT

[Jeremy Huddleston]

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 jerem...@apple.com
---
 src/mapi/glapi/gen/ARB_geometry_shader4.xml |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git origin/master/src/mapi/glapi/gen/ARB_geometry_shader4.xml 
origin/master/src/mapi/glapi/gen/ARB_geometry_shader4.xml
index ca9a101..d9e540f 100644
--- origin/master/src/mapi/glapi/gen/ARB_geometry_shader4.xml
+++ origin/master/src/mapi/glapi/gen/ARB_geometry_shader4.xml
@@ -38,7 +38,7 @@
 param name=texture type=GLuint/
 param name=level type=GLint/
 /function
-function name=FramebufferTextureLayerARB 
alias=FramebufferTextureLayer
+function name=FramebufferTextureLayerARB 
alias=FramebufferTextureLayerEXT
 param name=target type=GLenum/
 param name=attachment type=GLenum/
 param name=texture type=GLuint/
-- 
1.7.5.4


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4 resend] glx: Bind to our context before __glXSetCurrentContext

[Jeremy Huddleston]

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 jerem...@apple.com
---
 src/glx/glxcurrent.c |   25 -
 1 files changed, 16 insertions(+), 9 deletions(-)

diff --git origin/master/src/glx/glxcurrent.c origin/master/src/glx/glxcurrent.c
index 0f39ee5..6f048ae 100644
--- origin/master/src/glx/glxcurrent.c
+++ origin/master/src/glx/glxcurrent.c
@@ -212,7 +212,6 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
 {
struct glx_context *gc = (struct glx_context *) gc_user;
struct glx_context *oldGC = __glXGetCurrentContext();
-   int ret = Success;
 
/* XXX: If this is left out, then libGL ends up not having this
 * symbol, and drivers using it fail to load.  Compare the
@@ -259,15 +258,28 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
}
 
if (gc) {
+  /* Attempt to bind the context.  We do this before mucking with
+   * gc and __glXSetCurrentContext to properly handle our state in
+   * case of an error.
+   *
+   * If an error occurs, set the Null context since we've already
+   * blown away our old context.  The caller is responsible for
+   * figuring out how to handle setting a valid context.
+   */
+  if (gc-vtable-bind(gc, oldGC, draw, read) != Success) {
+ __glXSetCurrentContextNull();
+ __glXUnlock();
+ __glXGenerateError(dpy, None, GLXBadContext, X_GLXMakeContextCurrent);
+ return GL_FALSE;
+  }
+
   if (gc-thread_refcount == 0)
  gc-currentDpy = dpy;
-  __glXSetCurrentContext(gc);
-  ret = gc-vtable-bind(gc, oldGC, draw, read);
-  if (gc-thread_refcount == 0) {
  gc-currentDrawable = draw;
  gc-currentReadable = read;
   }
   gc-thread_refcount++;
+  __glXSetCurrentContext(gc);
} else {
   __glXSetCurrentContextNull();
}
@@ -281,11 +293,6 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
 
__glXUnlock();
 
-   if (ret) {
-  __glXGenerateError(dpy, None, ret, X_GLXMakeContextCurrent);
-  return GL_FALSE;
-   }
-
return GL_TRUE;
 }
 
-- 
1.7.5.4


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle

[Jeremy Huddleston]

Ok, 1e16c34c5c86690b26739fbad82617768b1bd837 should fix the warnings for those 
still using compilers based in the 1980's ;p

--Jeremy

On Jun 14, 2011, at 5:19 PM, Brian Paul wrote:

 Still no go.  You need to move the snprintf() calls after the variable 
 declarations.
 
 -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 well (eg: indirect_init.c).
 
 Thanks,
 Jeremy
 
 diff --git a/src/mapi/glapi/gen/gl_gentable.py 
 b/src/mapi/glapi/gen/gl_gentable.py
 index 73986f2..4420e3a 100644
 --- a/src/mapi/glapi/gen/gl_gentable.py
 +++ b/src/mapi/glapi/gen/gl_gentable.py
 @@ -34,6 +34,10 @@ import gl_XML, glX_XML
  import sys, getopt
 
  header = 
 +#if defined(DEBUG)  !defined(_WIN32_WCE)
 +#includeexecinfo.h
 +#endif
 +
  #includedlfcn.h
  #includestdlib.h
  #includestdio.h
 @@ -43,6 +47,40 @@ header = 
  #include glapi.h
  #include glapitable.h
 
 +static void
 +__glapi_gentable_NoOp(void) {
 +#if defined(DEBUG)  !defined(_WIN32_WCE)
 +if (getenv(MESA_DEBUG) || getenv(LIBGL_DEBUG)) {
 +const char *fstr = Unknown;
 +void *frames[2];
 +
 +if(backtrace(frames, 2) == 2) {
 +Dl_info info;
 +dladdr(frames[1],info);
 +if(info.dli_sname)
 +fstr = info.dli_sname;
 +}
 +
 +fprintf(stderr, Call to unimplemented API: %s\\n, fstr);
 +}
 +#endif
 +}
 +
 +static void
 +__glapi_gentable_set_remaining_noop(struct _glapi_table *disp) {
 +GLuint entries = _glapi_get_dispatch_table_size();
 +void **dispatch = (void **) disp;
 +int i;
 +
 +/* ISO C is annoying sometimes */
 +union {_glapi_proc p; void *v;} p;
 +p.p = __glapi_gentable_NoOp;
 +
 +for(i=0; i  entries; i++)
 +if(dispatch[i] == NULL)
 +dispatch[i] = p.v;
 +}
 +
  struct _glapi_table *
  _glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
  struct _glapi_table *disp = calloc(1, sizeof(struct _glapi_table));
 @@ -56,6 +94,8 @@ _glapi_create_table_from_handle(void *handle, const char 
 *symbol_prefix) {
  
 
  footer = 
 +__glapi_gentable_set_remaining_noop(disp);
 +
  return disp;
  }
  
 @@ -63,8 +103,8 @@ footer = 
  body_template = 
  if(!disp-%(name)s) {
  snprintf(symboln, sizeof(symboln), %%s%(entry_point)s, 
 symbol_prefix);
 -_glapi_proc *procp = (_glapi_proc *)disp-%(name)s;
 -*procp = (_glapi_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:
 b44d13e67bfe81b2d7af4aeda2c3caf7f252bd0f should work for you.  Thanks for 
 letting me know.
 
 Another warning:
 
 
 glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
 glapi_gentable.c:54:9: warning: ISO C90 forbids mixed declarations and code
 glapi_gentable.c:55:18: warning: ISO C forbids conversion of object pointer 
 to f
 unction pointer type
 glapi_gentable.c:61:9: warning: ISO C90 forbids mixed declarations and code
 glapi_gentable.c:62:18: warning: ISO C forbids conversion of object pointer 
 to f
 unction pointer type
 glapi_gentable.c:68:9: warning: ISO C90 forbids mixed declarations and code
 glapi_gentable.c:69:18: warning: ISO C forbids conversion of object pointer 
 to f
 unction pointer type
 
 
 Need to put the _glapi_proc declaration first.
 
 -Brian
 
 
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle

[Jeremy Huddleston]

Hi Brian,

Does this get rid of your warnings? (you'll need to regenerate the 
glapi_gentable.c)

diff --git a/src/mapi/glapi/gen/gl_gentable.py 
b/src/mapi/glapi/gen/gl_gentable.py
index 0dfebf8..1681a80 100644
--- a/src/mapi/glapi/gen/gl_gentable.py
+++ b/src/mapi/glapi/gen/gl_gentable.py
@@ -42,7 +42,6 @@ header = 
 
 #include glapi.h
 #include glapitable.h
-#include main/dispatch.h
 
 struct _glapi_table *
 _glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
@@ -50,7 +49,10 @@ _glapi_create_table_from_handle(void *handle, const char 
*symbol_prefix) {
 char symboln[512];
 
 if(!disp)
- return NULL;
+return NULL;
+
+if(symbol_prefix == NULL)
+symbol_prefix = ;
 
 
 footer = 
@@ -61,7 +63,7 @@ footer = 
 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);
 }
 
 


On Jun 13, 2011, at 7:22 AM, Brian Paul wrote:

 On 06/11/2011 11:18 PM, Jeremy Huddleston wrote:
 Module: Mesa
 Branch: master
 Commit: 85937f4c0d4a78d3a11e3c1fa6148640f2a9ad7b
 URL:
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=85937f4c0d4a78d3a11e3c1fa6148640f2a9ad7b
 
 Author: Jeremy Huddlestonjerem...@apple.com
 Date:   Thu Jun  9 16:59:49 2011 -0700
 
 glapi: Add API that can create a _glapi_table from a dlfcn handle
 
 Example usage:
 
 void *handle = dlopen(opengl_library_path, RTLD_LOCAL);
 struct _glapi_table *disp = _glapi_create_table_from_handle(handle, gl);
 
 Signed-off-by: Jeremy Huddlestonjerem...@apple.com
 
 ---
 
  src/mapi/glapi/gen/Makefile   |9 +-
  src/mapi/glapi/gen/gl_gentable.py |  131 +
  src/mapi/glapi/glapi.h|4 +
  src/mapi/glapi/glapi_gentable.c   | 7804 
 +
  src/mapi/glapi/sources.mak|1 +
  5 files changed, 7947 insertions(+), 2 deletions(-)
 
 Diff:   
 http://cgit.freedesktop.org/mesa/mesa/diff/?id=85937f4c0d4a78d3a11e3c1fa6148640f2a9ad7b
 ___
 mesa-commit mailing list
 mesa-com...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-commit
 
 
 Jeremy,
 
 I'm getting a ton of warnings when glapi_gentable.c is compiled:
 
 glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
 glapi_gentable.c:52:10: warning: ISO C forbids passing argument 2 of 
 ‘SET_NewLis
 t’ between function pointer and ‘void *’
 ../../../src/mesa/main/dispatch.h:2055:20: note: expected ‘void (*)(GLuint, 
 GLe
 num)’ but argument is of type ‘void *’
 glapi_gentable.c:58:10: warning: ISO C forbids passing argument 2 of 
 ‘SET_EndLis
 t’ between function pointer and ‘void *’
 ../../../src/mesa/main/dispatch.h:2066:20: note: expected ‘void (*)(void)’ 
 but a
 rgument is of type ‘void *’
 glapi_gentable.c:64:10: warning: ISO C forbids passing argument 2 of 
 ‘SET_CallLi
 st’ between function pointer and ‘void *’
 ../../../src/mesa/main/dispatch.h:2077:20: note: expected ‘void (*)(GLuint)’ 
 but
 argument is of type ‘void *’
 glapi_gentable.c:70:10: warning: ISO C forbids passing argument 2 of 
 ‘SET_CallLi
 sts’ between function pointer and ‘void *’
 ../../../src/mesa/main/dispatch.h:2088:20: note: expected ‘void (*)(GLsizei, 
 GL
 enum, const GLvoid *)’ but argument is of type ‘void *’
 glapi_gentable.c:76:10: warning: ISO C forbids passing argument 2 of 
 ‘SET_Delete
 Lists’ between function pointer and ‘void *’
 ../../../src/mesa/main/dispatch.h:2099:20: note: expected ‘void (*)(GLuint, 
 GLs
 izei)’ but argument is of type ‘void *’
 
 
 I think the generator needs to insert some casts to pass the right function 
 pointer type rather than void *.
 
 -Brian
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle

[Jeremy Huddleston]

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)
 
 
 Getting a different warning now:
 
 glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
 glapi_gentable.c:54:24: warning: ISO C forbids assignment between function 
 point
 er and ‘void *’
 glapi_gentable.c:60:24: warning: ISO C forbids assignment between function 
 point
 er and ‘void *’
 glapi_gentable.c:66:25: warning: ISO C forbids assignment between function 
 point
 er and ‘void *’
 glapi_gentable.c:72:26: warning: ISO C forbids assignment between function 
 point
 er and ‘void *’
 glapi_gentable.c:78:28: warning: ISO C forbids assignment between function 
 point
 
 
 I think you'll need to use a casting function along the lines of this from 
 gallium's u_pointer.h:
 
 typedef void (*func_pointer)(void);
 
 static INLINE func_pointer
 pointer_to_func( void *p )
 {
   union {
  void *p;
  func_pointer f;
   } pf;
   pf.p = p;
   return pf.f;
 }
 
 
 -Brian
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle

[Jeremy Huddleston]

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'll need to regenerate the 
 glapi_gentable.c)
 
 
 Getting a different warning now:
 
 glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
 glapi_gentable.c:54:24: warning: ISO C forbids assignment between function 
 point
 er and ‘void *’
 glapi_gentable.c:60:24: warning: ISO C forbids assignment between function 
 point
 er and ‘void *’
 glapi_gentable.c:66:25: warning: ISO C forbids assignment between function 
 point
 er and ‘void *’
 glapi_gentable.c:72:26: warning: ISO C forbids assignment between function 
 point
 er and ‘void *’
 glapi_gentable.c:78:28: warning: ISO C forbids assignment between function 
 point
 
 
 I think you'll need to use a casting function along the lines of this from 
 gallium's u_pointer.h:
 
 typedef void (*func_pointer)(void);
 
 static INLINE func_pointer
 pointer_to_func( void *p )
 {
   union {
  void *p;
  func_pointer f;
   } pf;
   pf.p = p;
   return pf.f;
 }
 
 
 -Brian
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] glapi: Add API that can create a _glapi_table from a dlfcn handle

[Jeremy Huddleston]

I have a patch that gets most of the way there, but it still has some quirks 
that I'd like to figure out and address.  

The generated code doesn't check for FramebufferTextureLayerARB as an alias for 
FramebufferTextureLayerEXT.  Could someone please explain what is going on 
there and why FramebufferTextureLayerARB isn't listed in the entry_points, but 
FramebufferTextureLayerEXT and FramebufferTextureLayer are?  I'm basically just 
iterating like this:

def printBody(self, api):
for f in api.functionIterateByOffset():
for entry_point in f.entry_points:
vars = { 'entry_point' : entry_point,
 'name' : f.name }

print body_template % vars
return

Also, should I leave the entry NULL when there is no implementation, or should 
I set it to a noop implementation that will catch the problem and log/abort?

I included the generated code in the commit since that is what seems consistent 
with the rest of glapi, even though other generated code (eg: 
src/mesa/main/main/api_exec_*.c) 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:35 PM, Jeremy Huddleston wrote:

 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.  
 Currently, the table is created by calling SET_* for every possibly entry and 
 uses dlsym() with an appropriate handle to get the function pointer:
 
 SET_Accum(__ogl_framework_api, dlsym(handle, glAccum));
 SET_AlphaFunc(__ogl_framework_api, dlsym(handle, glAlphaFunc));
 ...
 
 This works well enough, but it is not very robust, especially in cases where 
 there are multiple aliases for a particular function.  If OpenGL.framework 
 provides an implementation as one of the other aliases, we don't end up 
 picking it up.  I've special cased some, but this is just something that 
 should be easily generated rather than hand edited.
 
 It would be nice to have an api in glapi to handle this.  Someone familiar 
 with the specs parsing / code generation bits should be able to do it fairly 
 easily.  I'm envisioning something like this:
 
 struct _glapi_table *
 _glapi_create_table_from_handle(void *handle, const char *symbol_prefix);
 
 Which I would call like:
 void *handle = dlopen(opengl_framework_path, RTLD_LOCAL);
 __ogl_framework_api = _glapi_create_table_from_handle(handle, gl);
 
 The implementation would be something like:
 
 struct _glapi_table *
 _glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
   struct _glapi_table *disp = calloc(1, sizeof(struct _glapi_table));
   char symboln[512];
 
   if(!disp)
   return NULL;
 
   // Simple cases
   snprintf(symboln, sizeof(symboln), %sAccum, symbol_prefix);
   SET_Accum(disp, dlsym(handle, symboln));
 
   snprintf(symboln, sizeof(symboln), %sAlphaFunc, symbol_prefix);
   SET_AlphaFunc(disp, dlsym(handle, symboln));
 
   ...
 
   // More complex aliasing example
   snprintf(symboln, sizeof(symboln), %sFramebufferTextureLayerEXT, 
 symbol_prefix);
   SET_FramebufferTextureLayerEXT(disp, dlsym(handle, symboln));
   if(!disp-FramebufferTextureLayerEXT) {
   snprintf(symboln, sizeof(symboln), %sFramebufferTextureLayerARB, 
 symbol_prefix);
   SET_FramebufferTextureLayerEXT(disp, dlsym(handle, symboln));
   }
   if(!disp-FramebufferTextureLayerEXT) {
   snprintf(symboln, sizeof(symboln), %sFramebufferTextureLayer, 
 symbol_prefix);
   SET_FramebufferTextureLayerEXT(disp, dlsym(handle, symboln));
   }
 
   ...
 
   return disp;
 }
 
 This seems like something that would be useful outside of just the darwin 
 case.  Hopefully someone with more experience in the specs code generation 
 code would be able to do this (or at least point me in the right direction if 
 nobody is willing to tackle it themselves ... I'm guessing gen/gl_table.py is 
 a good place to start ...).  
 
 And before I go down this road, is this the right approach for implementing 
 this API, or is there another way that you'd recommend?
 
 Thanks,
 Jeremy
 
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] generating _glapi_table from a dlfcn handle

[Jeremy Huddleston]

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.  
Currently, the table is created by calling SET_* for every possibly entry and 
uses dlsym() with an appropriate handle to get the function pointer:

SET_Accum(__ogl_framework_api, dlsym(handle, glAccum));
SET_AlphaFunc(__ogl_framework_api, dlsym(handle, glAlphaFunc));
...

This works well enough, but it is not very robust, especially in cases where 
there are multiple aliases for a particular function.  If OpenGL.framework 
provides an implementation as one of the other aliases, we don't end up picking 
it up.  I've special cased some, but this is just something that should be 
easily generated rather than hand edited.

It would be nice to have an api in glapi to handle this.  Someone familiar with 
the specs parsing / code generation bits should be able to do it fairly easily. 
 I'm envisioning something like this:

struct _glapi_table *
_glapi_create_table_from_handle(void *handle, const char *symbol_prefix);

Which I would call like:
void *handle = dlopen(opengl_framework_path, RTLD_LOCAL);
__ogl_framework_api = _glapi_create_table_from_handle(handle, gl);

The implementation would be something like:

struct _glapi_table *
_glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
struct _glapi_table *disp = calloc(1, sizeof(struct _glapi_table));
char symboln[512];

if(!disp)
return NULL;

// Simple cases
snprintf(symboln, sizeof(symboln), %sAccum, symbol_prefix);
SET_Accum(disp, dlsym(handle, symboln));

snprintf(symboln, sizeof(symboln), %sAlphaFunc, symbol_prefix);
SET_AlphaFunc(disp, dlsym(handle, symboln));

...

// More complex aliasing example
snprintf(symboln, sizeof(symboln), %sFramebufferTextureLayerEXT, 
symbol_prefix);
SET_FramebufferTextureLayerEXT(disp, dlsym(handle, symboln));
if(!disp-FramebufferTextureLayerEXT) {
snprintf(symboln, sizeof(symboln), %sFramebufferTextureLayerARB, 
symbol_prefix);
SET_FramebufferTextureLayerEXT(disp, dlsym(handle, symboln));
}
if(!disp-FramebufferTextureLayerEXT) {
snprintf(symboln, sizeof(symboln), %sFramebufferTextureLayer, 
symbol_prefix);
SET_FramebufferTextureLayerEXT(disp, dlsym(handle, symboln));
}

...

return disp;
}

This seems like something that would be useful outside of just the darwin case. 
 Hopefully someone with more experience in the specs code generation code would 
be able to do this (or at least point me in the right direction if nobody is 
willing to tackle it themselves ... I'm guessing gen/gl_table.py is a good 
place to start ...).  

And before I go down this road, is this the right approach for implementing 
this API, or is there another way that you'd recommend?

Thanks,
Jeremy

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Understanding GLX_INDIRECT_RENDERING (libOSMesa fails to link due to gl_dispatch_stub*)

[Jeremy Huddleston]

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 put 
 them in mesa/osmesa)?  Should the stubs be getting exported by libGL?  
 Should GetHistogramEXT be exported by libGL?
 
 Based on my understanding, it seems like we should bring these stubs into 
 libmesa.a (and remove them from mesa/xlib).  Does that sound right?
 
 Actually... I'm perplexed about another issue here... why is libOSMesa 
 linking against both libglapi and libGL?
 
 It seems like the only things resolving into libGL are the stub symbols 
 missing in libglapi.  If we provide them in osmesa, why does libOSMesa need 
 to link against libGL at all?
 
 Similarly, libOSMesa seems to build fine if I just don't include libglapi.a 
 and let it resolve those calls into libGL (which it can re-export to provide 
 the gl* entry points).  This of course requires libGL to be glapi-aware 
 (which glx/apple isn't yet).
 
 As is, including libglapi.a in libOSMesa and in libGL will result in two 
 copies of libglapi existing in memory which seems like a recipe for disaster 
 since there will be two different dispatch tables, etc.  Perhaps this isn't a 
 problem on systems with flat namespaces, but on darwin, it is.

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 
sent for osmesa.c

It looks like -lGL is still done in default, beos, and aix ... so someone might 
want to update those as well...


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Understanding GLX_INDIRECT_RENDERING (libOSMesa fails to link due to gl_dispatch_stub*)

[Jeremy Huddleston]

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 sent for osmesa.c
 
 It looks like -lGL is still done in default, beos, and aix ... so someone 
 might want to update those as well...
 
 At one time, I had things set up so that one libGL.so contained both the GLX 
 and OSMesa interfaces.  An app could create a context of each time and freely 
 switch between them with glX/OSMesa-MakeCurrent().  A while back this got 
 changed so the OSMesa stuff lives in its own libOSMesa.so library.
 
 At first glance, I'd suggest just omitting all the OSMesa stuff on Darwin for 
 now.

Ok, well after omitting -lGL from OSMESA_LIB_DEPS and including the stubs in 
osmesa.c (patch on mesa-dev for review), things seem to be working well.

Is that patch the correct fix?  Has libOSMesa been failing to build correctly 
on other architectures as well?  If not, how is it resolving those symbols (or 
do architectures usually build libOSMesa without GLX_INDIRECT_RENDERING)?

I'm confused about how to interpret the matrix of GLX_INDIRECT_RENDERING and 
GLX_DIRECT_RENDERING:

-DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING

^^ libGL supports both direct and indirect rendering

-DGLX_INDIRECT_RENDERING -UGLX_DIRECT_RENDERING

^^ libGL supports only indirect rendering (?)

-UGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING

^^ libGL supports only direct rendering (?)  ... This doesn't seem to be the 
case since the indirect-foo is always included in src/glx/*.[hc]

-UGLX_INDIRECT_RENDERING -UGLX_DIRECT_RENDERING

^^ not supported?


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] packaging src/glx/apple

[Jeremy Huddleston]

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 all the build regressions on master and 7.10, so 
I'd like to now make sure that it gets properly packaged at release time.

Thanks,
Jeremy
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] mesa regressions on darwin

[Jeremy Huddleston]

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 introduced by 
(http://cgit.freedesktop.org/mesa/mesa/commit/?id=6849916170c0275c13510251a7b217c20f2b993e

This commit added a new reference to appleglDisplay, but it was never defined.  
What is supposed to be happening here?

../glxext.c: In function ‘AllocAndFetchScreenConfigs’:
../glxext.c:782: error: ‘struct glx_display’ has no member named 
‘appleglDisplay’
../glxext.c:783: error: ‘struct glx_display’ has no member named 
‘appleglDisplay’
../glxext.c: In function ‘__glXInitialize’:
../glxext.c:869: warning: implicit declaration of function 
‘applegl_create_display’

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mesa regressions on darwin

[Jeremy Huddleston]

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 ... 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 introduced by 
 (http://cgit.freedesktop.org/mesa/mesa/commit/?id=6849916170c0275c13510251a7b217c20f2b993e
 
 This commit added a new reference to appleglDisplay, but it was never 
 defined.  What is supposed to be happening here?
 
 ../glxext.c: In function ‘AllocAndFetchScreenConfigs’:
 ../glxext.c:782: error: ‘struct glx_display’ has no member named 
 ‘appleglDisplay’
 ../glxext.c:783: error: ‘struct glx_display’ has no member named 
 ‘appleglDisplay’
 ../glxext.c: In function ‘__glXInitialize’:
 ../glxext.c:869: warning: implicit declaration of function 
 ‘applegl_create_display’
 
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

[Jeremy Huddleston]

On May 5, 2011, at 1:09 PM, Jesse Barnes wrote:

 On Thu, 05 May 2011 12:59:50 -0700
 Jeremy Huddleston jerem...@apple.com wrote:
 
 For *proto/mesa:
 Reviewed-by: Jeremy Huddleston jerem...@apple.com
 
 Thanks.
 
 For xserver:
 This looks incomplete.  You also need to update swap_count in 
 DRI2DrawableRec to be CARD32.
 
 That value is used in other places that actually preserve the full 64
 bits.  I could add an explicit cast in the few places where we pass it
 to the swap completion though if you think that's better...

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 will cause problems if we really do 
need those extra bits:

if (swap_complete)
swap_complete(client, swap_data, type, ust, frame, pPriv-swap_count);

It looks to me like much more of DRI2 should be rewritten to use 32bit swap 
counts, or there should be some other mechanism in place to communicate the 
full 64bit value.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

[Jeremy Huddleston]

 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 will cause 
 problems if we really do need those extra bits:
 
if (swap_complete)
swap_complete(client, swap_data, type, ust, frame, pPriv-swap_count);
 
 It looks to me like much more of DRI2 should be rewritten to use 32bit swap 
 counts, or there should be some other mechanism in place to communicate the 
 full 64bit value.
 
 Yeah there are other mechanisms (the OML sync extension) for
 communicating the whole 64 bits.  Both the swap reply and msc reply
 deal in the full 64 bits, just the swap event (an unrelated extension)
 truncates to 32 bits.  (Also I think the 64 bit size for swap count in
 the OML extension is just inertia; getting to a count that high even at
 120Hz is going to take awhile.)

Ok, well this all really doesn't sit well with me, but it would put my mind 
slightly at ease if you would do some logging of the problem if we encounter it 
in DRI2SwapComplete.  That might give your future self some clue as to what is 
going wrong when you see issues down the road:

   if (swap_complete) {
   if (pPriv-swap_count  0x)
   ErrorF(something appropriate);
   swap_complete(client, swap_data, type, ust, frame, 
(CARD32)pPriv-swap_count);
   }

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

[Jeremy Huddleston]

For *proto/mesa:
Reviewed-by: Jeremy Huddleston jerem...@apple.com

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 up the completion calls to use CARD32 instead of CARD64 to match
 the new field size.
 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 
 diff --git a/configure.ac b/configure.ac
 index 6eb780c..3e0ed5d 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -771,11 +771,11 @@ RECORDPROTO=recordproto = 1.13.99.1
 SCRNSAVERPROTO=scrnsaverproto = 1.1
 RESOURCEPROTO=resourceproto
 DRIPROTO=xf86driproto = 2.1.0
 -DRI2PROTO=dri2proto = 2.3
 +DRI2PROTO=dri2proto = 2.5
 XINERAMAPROTO=xineramaproto
 BIGFONTPROTO=xf86bigfontproto = 1.2.0
 DGAPROTO=xf86dgaproto = 2.0.99.1
 -GLPROTO=glproto = 1.4.10
 +GLPROTO=glproto = 1.4.14
 DMXPROTO=dmxproto = 2.2.99.1
 VIDMODEPROTO=xf86vidmodeproto = 2.2.99.1
 WINDOWSWMPROTO=windowswmproto
 diff --git a/glx/glxdri2.c b/glx/glxdri2.c
 index 93c5e5b..e872258 100644
 --- a/glx/glxdri2.c
 +++ b/glx/glxdri2.c
 @@ -163,10 +163,10 @@ __glXDRIdrawableWaitGL(__GLXdrawable *drawable)
 
 static void
 __glXdriSwapEvent(ClientPtr client, void *data, int type, CARD64 ust,
 -   CARD64 msc, CARD64 sbc)
 +   CARD64 msc, CARD32 sbc)
 {
 __GLXdrawable *drawable = data;
 -xGLXBufferSwapComplete wire;
 +xGLXBufferSwapComplete2 wire;
 
 if (!(drawable-eventMask  GLX_BUFFER_SWAP_COMPLETE_INTEL_MASK))
   return;
 @@ -192,8 +192,7 @@ __glXdriSwapEvent(ClientPtr client, void *data, int type, 
 CARD64 ust,
 wire.ust_lo = ust  0x;
 wire.msc_hi = msc  32;
 wire.msc_lo = msc  0x;
 -wire.sbc_hi = sbc  32;
 -wire.sbc_lo = sbc  0x;
 +wire.sbc = sbc;
 
 WriteEventsToClient(client, 1, (xEvent *) wire);
 }
 diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
 index fe0bf6c..2a41ead 100644
 --- a/hw/xfree86/dri2/dri2.h
 +++ b/hw/xfree86/dri2/dri2.h
 @@ -51,7 +51,7 @@ extern CARD8 dri2_minor;
 
 typedef DRI2BufferRec DRI2Buffer2Rec, *DRI2Buffer2Ptr;
 typedef void (*DRI2SwapEventPtr)(ClientPtr client, void *data, int type,
 -  CARD64 ust, CARD64 msc, CARD64 sbc);
 +  CARD64 ust, CARD64 msc, CARD32 sbc);
 
 
 typedef DRI2BufferPtr (*DRI2CreateBuffersProcPtr)(DrawablePtr pDraw,
 diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
 index 4e48e65..552b26b 100644
 --- a/hw/xfree86/dri2/dri2ext.c
 +++ b/hw/xfree86/dri2/dri2ext.c
 @@ -357,9 +357,9 @@ vals_to_card64(CARD32 lo, CARD32 hi)
 
 static void
 DRI2SwapEvent(ClientPtr client, void *data, int type, CARD64 ust, CARD64 msc,
 -   CARD64 sbc)
 +   CARD32 sbc)
 {
 -xDRI2BufferSwapComplete event;
 +xDRI2BufferSwapComplete2 event;
 DrawablePtr pDrawable = data;
 
 event.type = DRI2EventBase + DRI2_BufferSwapComplete;
 @@ -369,8 +369,7 @@ DRI2SwapEvent(ClientPtr client, void *data, int type, 
 CARD64 ust, CARD64 msc,
 event.ust_lo = ust  0x;
 event.msc_hi = (CARD64)msc  32;
 event.msc_lo = msc  0x;
 -event.sbc_hi = (CARD64)sbc  32;
 -event.sbc_lo = sbc  0x;
 +event.sbc = sbc;
 
 WriteEventsToClient(client, 1, (xEvent *)event);
 }
 ___
 xorg-de...@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] xserver/glx/dri2: use new GLX/DRI2 swap event types

[Jeremy Huddleston]

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 jerem...@apple.com

On May 6, 2011, at 10:39, Jesse Barnes wrote:

 On Fri, 06 May 2011 09:25:35 +0200
 Michel Dänzer mic...@daenzer.net wrote:
 
 On Don, 2011-05-05 at 14:02 -0700, Jesse Barnes wrote: 
   if (swap_complete) {
   if (pPriv-swap_count  0x)
   ErrorF(something appropriate);
   swap_complete(client, swap_data, type, ust, frame, 
 (CARD32)pPriv-swap_count);
   }
 
 Yeah, it's annoying.  How about I leave out the error message and handle
 wrapping on the client side instead?  That way at least the client code
 won't notice that the server is only transmitting 32 bits...
 
 Nevermind, that can't work generally since clients are free to
 mask/unmask the events, so we could miss a 0 count and thus a wrap.
 
 Missing 0 isn't a problem, you can assume there's been a wraparound
 whenever the current value is smaller than the previous one. This would
 only fail if the client misses several wraparounds, in which case
 apparently it doesn't care all that much in the first place. :)
 
 Please do this.
 
 How does this look for the direct case?  The indirect case is a little
 more complicated since I need to add a new glx_drawable type and track
 it (Kristian says this should help clean up some of the Apple mess as
 well).  This patch handles at least one wrap correctly (I set the
 server's starting swap_count at 0xfff0 and then ran the
 glx-swap-event test in piglit; wrapping worked ok).
 
 -- 
 Jesse Barnes, Intel Open Source Technology Center
 
 From f1e288f61e10b71018600a24ca0bdda93f8481db Mon Sep 17 00:00:00 2001
 From: Jesse Barnes jbar...@virtuousgeek.org
 Date: Fri, 6 May 2011 10:31:24 -0700
 Subject: [PATCH] DRI2: handle swap event swap count wrapping
 
 Add a wrap counter to the DRI drawable and track it as we receive events.
 This allows us to support the full 64 bits of the event structure we
 pass to the client even though the server only gives us a 32 bit count.
 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
 src/glx/dri2.c  |   12 +++-
 src/glx/dri2_glx.c  |2 ++
 src/glx/glxclient.h |2 ++
 3 files changed, 15 insertions(+), 1 deletions(-)
 
 diff --git a/src/glx/dri2.c b/src/glx/dri2.c
 index 8654a37..08ceec0 100644
 --- a/src/glx/dri2.c
 +++ b/src/glx/dri2.c
 @@ -88,6 +88,7 @@ static Bool
 DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
 {
XExtDisplayInfo *info = DRI2FindDisplay(dpy);
 +   __GLXDRIdrawable *pdraw;
 
XextCheckExtension(dpy, info, dri2ExtensionName, False);
 
 @@ -124,7 +125,16 @@ DRI2WireToEvent(Display *dpy, XEvent *event, xEvent 
 *wire)
   }
   aevent-ust = ((CARD64)awire-ust_hi  32) | awire-ust_lo;
   aevent-msc = ((CARD64)awire-msc_hi  32) | awire-msc_lo;
 -  aevent-sbc = awire-sbc;
 +
 +  pdraw = dri2GetGlxDrawableFromXDrawableId(dpy, awire-drawable);
 +  if (!pdraw)
 +  return False;
 +
 +  if (awire-sbc  pdraw-lastEventSbc)
 +  pdraw-eventSbcWrap += 0x1;
 +  pdraw-lastEventSbc = awire-sbc;
 +  aevent-sbc = awire-sbc + pdraw-eventSbcWrap;
 +
   return True;
}
 #endif
 diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
 index fc0237a..421f543 100644
 --- a/src/glx/dri2_glx.c
 +++ b/src/glx/dri2_glx.c
 @@ -258,6 +258,8 @@ dri2CreateDrawable(struct glx_screen *base, XID xDrawable,
pdraw-base.xDrawable = xDrawable;
pdraw-base.drawable = drawable;
pdraw-base.psc = psc-base;
 +   pdraw-base.lastEventSbc = 0;
 +   pdraw-base.eventSbcWrap = 0;
pdraw-bufferCount = 0;
pdraw-swap_interval = 1; /* default may be overridden below */
pdraw-have_back = 0;
 diff --git a/src/glx/glxclient.h b/src/glx/glxclient.h
 index 2b6966f..1eb2483 100644
 --- a/src/glx/glxclient.h
 +++ b/src/glx/glxclient.h
 @@ -138,6 +138,8 @@ struct __GLXDRIdrawableRec
GLenum textureTarget;
GLenum textureFormat;/* EXT_texture_from_pixmap support */
unsigned long eventMask;
 +   uint32_t lastEventSbc;
 +   int64_t eventSbcWrap;
 };
 
 /*
 -- 
 1.7.4.1
 
 ___
 xorg-de...@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] mesa-from-git: build with clang(++) and --enable-glx-tls

[Jeremy Huddleston]

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] 
 http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/rules;hb=refs/tags/mesa-7.10.1-1#l107
 [2] 
 http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=blob;f=debian/rules;hb=refs/tags/xorg-server-2_1.10.0.901-1#l124
 
 On Sat, Apr 9, 2011 at 12:52 PM, Sedat Dilek sedat.di...@googlemail.com 
 wrote:
 Hi,
 
 I am currently playing with clang-3.0svn (and llvm) and mesa-from-git
 builds just fine.
 ( I tried also -O3 as {C,CXX}FLAGS and so on. )
 
 Unfortunately, when turning on --enable-glx-tls, I see warnings like this:
 ...
 In file included from glapi_dispatch.c:40:
 In file included from ../../../src/mapi/glapi/glapi_priv.h:52:
 ../../../src/mapi/glapi/glapi.h:84:20: warning: unknown attribute
 'tls_model' ignored [-Wunknown-attributes]
__attribute__((tls_model(initial-exec)));
   ^
 ../../../src/mapi/glapi/glapi.h:87:20: warning: unknown attribute
 'tls_model' ignored [-Wunknown-attributes]
__attribute__((tls_model(initial-exec)));
   ^
 2 warnings generated.
 ...
 
 Just FYI:
 Debian builds its xserver with --enable-glx-tls, too (and IIRC this
 is a pre-condition for mesa).
 
 If this info matters: I am here on Debian's xorg-server-1.10.0.901 (1.10.1 
 RC1).
 ( BTW, -O2 or -O3 does not matter. )
 
 I have attached my full build.log.
 
 Regards,
 - Sedat -
 
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] glproto changes

[Jeremy Huddleston]

Why is sbc a 32bit field in xGLXBufferSwapComplete2 and 
xDRI2BufferSwapComplete2 when it is a 64bit field in GLXBufferSwapComplete?

The hunk at the bottom will result in casting a 64bit int to a 32bit int.  If 
you're going to change this, shouldn't you also change GLXBufferSwapComplete, 
DRI2SwapEvent() and everything else that has a 64bit swap count?

Isn't it easier to correct the spec to match reality?

--- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -359,7 +359,7 @@ static void
 DRI2SwapEvent(ClientPtr client, void *data, int type, CARD64 ust, CARD64 msc,
  CARD64 sbc)
 {
-xDRI2BufferSwapComplete event;
+xDRI2BufferSwapComplete2 event;
 DrawablePtr pDrawable = data;
 
 event.type = DRI2EventBase + DRI2_BufferSwapComplete;
@@ -369,8 +369,7 @@ DRI2SwapEvent(ClientPtr client, void *data, int type, 
CARD64 ust, CARD64 msc,
 event.ust_lo = ust  0x;
 event.msc_hi = (CARD64)msc  32;
 event.msc_lo = msc  0x;
-event.sbc_hi = (CARD64)sbc  32;
-event.sbc_lo = sbc  0x;
+event.sbc = sbc;
 
 WriteEventsToClient(client, 1, (xEvent *)event);
 }



On May 5, 2011, at 08:28, Jesse Barnes wrote:

 On Wed, 4 May 2011 21:29:23 -0700
 Jeremy Huddleston jerem...@freedesktop.org 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 think we 
 need to brownbag retract and rethink this.
 
 Damnit; right when Dave mentioned this last night I knew I had gone too
 far in trying to make sure the fix was propagated.  I hate it when he's
 right!
 
 Yeah, having a rule that we can't touch existing proto structs makes
 sense unless we want to do a major break.  It certainly makes pushing
 out updates eaiser and preserves bisection...
 
 These changes break API.  I'm all for fixing the structs, but anything that 
 breaks API (or worse, protocol) certainly warrants much more than the +0.0.1 
 version bump.  This also makes it impossible to build the current dev and 
 current stable with the same protos installed.  I haven't looked at the 
 details specifically, but I suspect that it also changes what is on the 
 wire, meaning clients and the server may disagree depending on which glproto 
 version they were using.  Is that the case?  If not, can't we solve this 
 with some creative union{}ing?
 
 In this case, what's on the wire is pretty much the same; if the client
 and server don't match, you may get a different kind of corruption in
 the affected field (0 vs some other value), but things are no worse.
 
 Either way, I think we should retract the glproto 1.4.13 release until we 
 can get this straightened out.
 
 Ok; fwiw my rationale was twofold:
  1) make sure master requires the new proto headers to avoid some of
 the trouble we've had in the past with ifdefs and untested paths
 (though again, the failure mode is benign in this case)
  2) make the proto breakage obvious even for older code; the fix is
 trivial
 
 But I guess (2) is a bit much... after pushing I started having
 nightmares about the input proto changes from awhile back.
 
 Here are what the backwards compatible changes look like...  Look
 better?
 
 Thanks,
 -- 
 Jesse Breaker of Builds Barnes
 dri2proto-compat-fix.patchglproto-compat-fix.patchmesa-glx-compat-fix.patchxserver-glproto-compat-fix.patch

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] configure: Don't use $CLANG since it will collide with the static analyzer.

[Jeremy Huddleston]

We just prefix the $CLANG environment variable in configure.ac with acv_mesa_

Found by: tinderbox
Signed-off-by: Jeremy Huddleston jerem...@apple.com

---
 configure.ac |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 54d9c29..f3f0fda 100644
--- a/configure.ac
+++ b/configure.ac
@@ -64,13 +64,13 @@ AC_COMPILE_IFELSE(
not clang
 #endif
 ]])],
-[CLANG=yes], [CLANG=no])
+[acv_mesa_CLANG=yes], [acv_mesa_CLANG=no])
 
-AC_MSG_RESULT([$CLANG])
+AC_MSG_RESULT([$acv_mesa_CLANG])
 
 dnl If we're using GCC, make sure that it is at least version 3.3.0.  Older
 dnl versions are explictly not supported.
-if test x$GCC = xyes -a x$CLANG = xno; then
+if test x$GCC = xyes -a x$acv_mesa_CLANG = xno; then
 AC_MSG_CHECKING([whether gcc version is sufficient])
 major=0
 minor=0
@@ -144,7 +144,7 @@ esac
 dnl Add flags for gcc and g++
 if test x$GCC = xyes; then
 CFLAGS=$CFLAGS -Wall -Wmissing-prototypes -std=c99
-if test x$CLANG = xno; then
+if test x$acv_mesa_CLANG = xno; then
CFLAGS=$CFLAGS -ffast-math
 fi
 
-- 
1.7.3.4


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Error building glxext.c

[Jeremy Huddleston]

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 ppc64 and ubuntu ppc):

http://tinderbox.x.org/builds/2011-05-04-/logs/libGL/#build
http://tinderbox.x.org/builds/2011-05-04-0001/logs/libGL/#build

On May 4, 2011, at 10:37, Jesse Barnes wrote:

 On Wed, 04 May 2011 10:01:28 -0700
 Ian Romanick i...@freedesktop.org wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 05/04/2011 09:40 AM, Dan McCabe wrote:
 Hi all,
 
 Apologies if this is a stupid n00b question, but I'm getting errors
 building glxext.c in mesa/mesa/src/glx.
 
 Specific error msg is:
glxext.c: In function ‘__glXWireToEvent’:
glxext.c:141:35: error: ‘xGLXBufferSwapComplete’ has no member
named ‘sbc_hi’
glxext.c:141:58: error: ‘xGLXBufferSwapComplete’ has no member
named ‘sbc_lo’
 
 I followed the installation/build directions described here:
 http://wiki.x.org/wiki/ModularDevelopersGuide
 and I grabbed the src from git last night (early evening).
 
 Any suggestions/recommendations?
 
 My guess is that you need newer glproto bits.  The protocol related to
 the GLX buffer swap complete event was broken, and Jesse has been
 working on fixing.  I'd guess that you Mesa bits have the fixes applied,
 but they need newer glproto bits to build.
 
 I think it's the reverse, I got review on the glproto bits so they're
 pushed.  Still waiting on review for the Mesa, dri2proto, and X parts
 though to push the rest.
 
 So revert the top commit of glproto to get the old structure def back
 (in fact, Mesa autoconf should have complained about the glproto, but
 only if you re-run autogen.sh).
 
 -- 
 Jesse Barnes, Intel Open Source Technology Center
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Error building glxext.c

[Jeremy Huddleston]

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 push the other bits right away too,
 but I'm still waiting for review.
 
 I'll revert the glproto commit today if it looks like I won't be able
 to do the release.

Nah.  No need for reversion, un-reversion noise if it'll be fixed in the next 
few days.  A few more red boxes in the tinderbox won't hurt so long as we know 
it's coming soon.  We should just try better next time to coordinate pushes 
that are interdependent.

Thanks,
Jeremy

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] glproto changes

[Jeremy Huddleston]

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, protocol) certainly warrants much more than the +0.0.1 
version bump.  This also makes it impossible to build the current dev and 
current stable with the same protos installed.  I haven't looked at the details 
specifically, but I suspect that it also changes what is on the wire, meaning 
clients and the server may disagree depending on which glproto version they 
were using.  Is that the case?  If not, can't we solve this with some creative 
union{}ing?

Either way, I think we should retract the glproto 1.4.13 release until we can 
get this straightened out.

On May 4, 2011, at 18:17, Dave Airlie wrote:

 So I wasn't watching and glproto broke its interface, and I think its bad.
 
 Why?
 
 You can no longer bisect things across this point without now moving glproto.
 glxproto.h:xGLXBufferSwapComplete was a released header file
 definition, you cannot go back and change history.
 
 This should have been handled with xGLXBufferSwapComplete2 struct that
 newer mesa and X server could would use
 instead of the older code. Old code would build against the old broken
 defintion but since its broken it wouldn't matter,
 and new code would build against the new fixed definition.
 
 This doesn't address the I need the latest glproto to build mesa and
 my distro doesn't have which concerns me less
 than the I can't bisect anymore and I fully agree with Jesse that the
 last time we tried using #ifdef for this sort of thing it led
 to a number of untested combos resulting in impossible to debug issues.
 
 Dave.
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev
 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 7.8.2 release

[Jeremy Huddleston]

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 this doesn't get dropped in the next release?

On Jun 17, 2010, at 11:24, Ian Romanick wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Mesa 7.8.2 has been released.  Links on the Mesa website will be as soon
 as Brian returns from vacation.
 
 The tag in the GIT repository for Mesa 7.8.2 is 'mesa-7.8.2'.
 
 Mesa 7.8.2 is available for download at
 ftp://freedesktop.org/pub/mesa/7.8.2/
 
 md5sums:
 
 c89b63d253605ed40e8ac370d25a833c  MesaLib-7.8.2.tar.gz
 6be2d343a0089bfd395ce02aaf8adb57  MesaLib-7.8.2.tar.bz2
 a04ad3b06ac5ff3969a003fa7bbf7d5b  MesaLib-7.8.2.zip
 7c213f92efeb471f0331670d5079d4c0  MesaDemos-7.8.2.tar.gz
 757d9e2e06f48b1a52848be9b0307ced  MesaDemos-7.8.2.tar.bz2
 8d0e5cfe68b8ebf90265d350ae2c48b1  MesaDemos-7.8.2.zip
 b74482e3f44f35ed395c4aada4fd8240  MesaGLUT-7.8.2.tar.gz
 a471807b65e49c325808ba4551be93ed  MesaGLUT-7.8.2.tar.bz2
 9f190268c42be582ef66e47365ee61e3  MesaGLUT-7.8.2.zip
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAkwaaEIACgkQX1gOwKyEAw98zwCfR4pLp5URIoC61PPbameh+Fzz
 q34An3TfzQSwUNnMajZRRr87avGZ+fsb
 =N7nx
 -END PGP SIGNATURE-
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa 7.8.2 release?

[Jeremy Huddleston]

On Jun 16, 2010, at 16:25, Dan Nicholson wrote:

 On Wed, Jun 16, 2010 at 4:20 PM, Jeremy Huddleston
 jerem...@freedesktop.org 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) 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 try for a while.
 
 I just merged origin/7.8 into my tree, and I just saw it successfully link
 libOSMesa:
 
 /bin/sh ../../../../bin/mklib -o OSMesa -linker 'gcc' -ldflags '' \
-major 7 -minor 8 -patch 1 \
-install ../../../../lib  \
-id /usr/X11/lib/libOSMesa.7.dylib \
-L../../../../lib -lGL osmesa.o
 ../../../../src/mesa/libmesa.a ../../../../src/mesa/libglapi.a
 ../../../../src/glsl/cl/libglslcl.a ../../../../src/glsl/pp/libglslpp.a
 mklib: Making Darwin shared library:  libOSMesa.7.8.dylib
 mklib: Installing libOSMesa.7.8.dylib libOSMesa.7.dylib libOSMesa.dylib in
 ../../../../lib
 
 Your LDFLAGS have:
 -lMesaGL   osmesa.o
 
 whereas mine have:
 -lGL osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mesa/libglapi.a
 ../../../../src/glsl/cl/libglslcl.a
 
 which probably results from your use of the autoconf build system.  A quick
 check shows the symbol you are looking for is in libmesa.a:
 
 ~/src/freedesktop/src/mesa (7.8) $ nm src/mesa/libmesa.a | grep
 mesa_make_current
 05ce T __mesa_make_current
 0004eca0 S __mesa_make_current.eh
 
 Right. In this case, the -lGL should be redundant since the reason
 OSMesa was linking to GL was just to not duplicate the internal libs
 (which you have here). Maybe you guys are using OSMesa differently
 than I think, though.

So you expect that __mesa_make_current would be defined in libMesaGL?  Tom, 
check out how libMesaGL is getting built to make sure it's getting built right.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] GLX_USE_APPLEGL

[Jeremy Huddleston]

Hi Kristian,

Thanks for your comments.  I sent out a few requests to the mailing list a 
while back.  I just took the silence as whatever.  it doesn't really affect 
us.  ... that being said, I actually share your concern about this 
#ifdef-crud.  My main reason for integrating it as-is was to avoid spending 
days rebasing it the next time something big happens (like the directory 
change).  Unfortunately, my focus has been diverted elsewhere over the past few 
months, so I wasn't able to clean this all up as I had hoped by now.

The main problem was that George forked from Mesa-7.2 and didn't preserve any 
non-Apple code.  It took me quite a while to re-integrate these changes to this 
point, and hopefully things will get a bit smoother as I refactor it.

George decided to use a separate dispatch table for the gl functions, which has 
served us in the short term, but now that I'm re-integrating these changes, I 
want to rewrite our dispatch code to use the existing dispatch.  This should 
then let us eliminate more of these ifdefs and also start including support for 
indirect.

I like the idea of using a similar approach for the glX functions, but for now, 
I'm going to try making the GLX_USE_APPLEGL way more similar to the 
!GLX_USE_APPLEGL way.

I'm sorry for any difficulty this has caused.  Feel free to break Apple and 
ping me to fix our case.

Thanks,
Jeremy

On May 20, 2010, at 06:24, Kristian Høgsberg wrote:

 Hi Jeremy,
 
 First of all, let me say that I'm sorry I didn't review your work
 before it was committed, that would have been the right time to
 address this.  Anyway, my problem is that the addition of even more
 #ifdef's to the glx client code makes an already tangled code base
 harder to read and work with.  Even worse, a lot of the new #ifndef
 GLX_USE_APPLEGL is of the form
 
 PUBLIC void
 glXCopyContext(Display * dpy, GLXContext source,
   GLXContext dest, unsigned long mask)
 {
 #ifdef GLX_USE_APPLEGL
  /* Apple GL code */
 #else
  /* What was there before */
 #endif
 }
 
 which is just screaming out for a vtable implementation.  There are
 places where code is shared, but it's often just a small snippet like
 if (!dpy) return NULL; or it's a bigger piece of code that can be put
 in a common function and called from the different implementations.
 
 Of course, the existing code already did this to some extent with the
 direct/indirect code paths.  Most of these cases look like
 
 #if defined(GLX_DIRECT_RENDERING)
   if (gc-driContext) {
  /* direct rendering case */
   }
   /* fall through to indirect case */
 #endif
 
   /* indirect case */
 
 which would be handled just fine by the vtable approach as well: at
 context creation time, we set the context vtable pointer to the
 direct, indirect or applegl functions and this will just work.  I
 wanted to do some of this in the past, but I didn't feel like sinking
 too much work into the glx code before the license change.
 
 Now, I'm not saying that we need to do this refactoring now - it's
 certainly not a priority for me right now.  But as a minimum, I'd like
 us to be on the same page with where this code should be, and
 hopefully we can work towards a cleaner code base.  FIguring out
 what's going on in any of the glx entrypoints is just too hard right
 now with all the #ifdef spaghetti.
 
 Kristian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Fwd: Mesa (7.8): f]

[Jeremy Huddleston]

rrr... my 'git rebase -i' barfed on me because I had an old version installed 
without fixup.

I thought it completed, and I pushed... but it didn't.  I've cleaned it up.  
Sorry for the sludge.

--Jeremy

On Apr 27, 2010, at 12:42, Keith Whitwell wrote:

 What the f ?  :)
 
 Keith
 
 From: Jeremy Huddleston jerem...@kemper.freedesktop.org
 Date: April 27, 2010 12:23:48 PDT
 To: mesa-com...@lists.freedesktop.org mesa-com...@lists.freedesktop.org
 Subject: Mesa (7.8): f
 
 
 Module: Mesa
 Branch: 7.8
 Commit: 39bd4602c0c31d4984293fd6e419405aca32d940
 URL:
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=39bd4602c0c31d4984293fd6e419405aca32d940
 
 Author: Jeremy Huddleston jerem...@apple.com
 Date:   Tue Apr 27 12:22:50 2010 -0700
 
 f
 
 Signed-off-by: Jeremy Huddleston jerem...@apple.com
 
 ---
 
 src/glx/apple/apple_glx_pbuffer.c |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)
 
 diff --git a/src/glx/apple/apple_glx_pbuffer.c 
 b/src/glx/apple/apple_glx_pbuffer.c
 index b754ab5..1466fea 100644
 --- a/src/glx/apple/apple_glx_pbuffer.c
 +++ b/src/glx/apple/apple_glx_pbuffer.c
 @@ -27,6 +27,13 @@
  prior written authorization.
 */
 
 +/* Must be before OpenGL.framework is included.  Remove once fixed:
 + * rdar://problem/7872773
 + */
 +#include GL/gl.h
 +#include GL/glext.h
 +#define __gltypes_h_ 1
 +
 /* Must be first for:
  * rdar://problem/6953344
  */
 @@ -40,7 +47,9 @@
 #include glcontextmodes.h
 #include apple_cgl.h
 
 -/* mesa defines in glew.h, should be in glext.h */
 +/* mesa defines in glew.h, Apple in glext.h.
 + * Due to namespace nightmares, just do it here.
 + */
 #ifndef GL_TEXTURE_RECTANGLE_EXT
 #define GL_TEXTURE_RECTANGLE_EXT 0x84F5
 #endif
 
 ___
 mesa-commit mailing list
 mesa-com...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-commit
 
 
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev