Ian Romanick wrote:
Ian Romanick wrote:
Ian Romanick wrote:
Alan Hourihane wrote:
Is there someone looking to integrate the TLS patches for libGL ??
We should certainly take a look soon and comment upon the patches used.
Here is a patch that covers part of what's in the Redhat patch. This
convert
Keith Whitwell wrote:
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATCH(FUNC, ARGS, MESSAG
Mike Mestnik wrote:
Currently every inst that referances a register(this is most of them)
needs a global .register setting?? As far as making the build system use
the C vs the asm I could also not find where this is soposed to happen. I
got as far as stoping the asm from being built, but then I c
I know I posted the exact errmsg but esecaly it's missing a global
.register deffinition and it's just the sam code (.S).
I build it in 64bit (not using sparc32 to fake a 32bit system). I needed
this cause DRI is knowen to not work with mixed user/kernel bitdepths and
I have a 64bit kernel. glib
Currently every inst that referances a register(this is most of them)
needs a global .register setting?? As far as making the build system use
the C vs the asm I could also not find where this is soposed to happen. I
got as far as stoping the asm from being built, but then I coulden't find
what C
Ian Romanick wrote:
Here's an updated version of that patch. There are some significant
differences.
I hate it when I do that
Index: src/mesa/glapi/gl_procs.py
===
RCS file: /cvs/mesa/Mesa/src/mesa/glapi/gl_procs.py,v
retrieving
Ian Romanick wrote:
Alan Hourihane wrote:
Is there someone looking to integrate the TLS patches for libGL ??
We should certainly take a look soon and comment upon the patches used.
Here is a patch that covers part of what's in the Redhat patch. This
convert the static_functions table to a list of
Ian Romanick wrote:
Mike Mestnik wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
Assembly dispatch stubs are only generated for x86 and SPARC. It
looks like the #if test in dispatch.c is wrong, so that stubs don't
even get used on SPARC. In any case, Jakub's patch did modify the
x86 assembl
Mike Mestnik wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
Assembly dispatch stubs are only generated for x86 and SPARC. It looks
like the #if test in dispatch.c is wrong, so that stubs don't even get
used on SPARC. In any case, Jakub's patch did modify the x86 assembly,
not the C version
Mike Mestnik wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
Assembly dispatch stubs are only generated for x86 and SPARC. It looks
like the #if test in dispatch.c is wrong, so that stubs don't even get
used on SPARC. In any case, Jakub's patch did modify the x86 assembly,
not the C version
Ian Romanick wrote:
Keith Whitwell wrote:
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATC
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Assembly dispatch stubs are only generated for x86 and SPARC. It looks
> like the #if test in dispatch.c is wrong, so that stubs don't even get
> used on SPARC. In any case, Jakub's patch did modify the x86 assembly,
> not the C version. I wasn't
Keith Whitwell wrote:
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATCH(FUNC, ARGS, MESSAG
Ian Romanick wrote:
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATCH(FUNC, ARGS, MESSAGE) \
(_glapi_Dispa
One thing about Jakub's patch is that, on x86, it eliminates the need
for the specialized _ts_* versions of the dispatch functions. It
basically converts the DISPATCH macro (as used in
src/mesa/main/dispatch.c) from:
#define DISPATCH(FUNC, ARGS, MESSAGE) \
(_glapi_Dispatch->FUNC) ARGS
Alan Hourihane wrote:
Is there someone looking to integrate the TLS patches for libGL ??
We should certainly take a look soon and comment upon the patches used.
Here is a patch that covers part of what's in the Redhat patch. This
convert the static_functions table to a list of offsets instead of
Ian Romanick wrote:
Keith Whitwell wrote:
Alan Hourihane wrote:
I emailed Keith regarding this a while back and he had some concerns
over the patches used, but I just wanted to bring to light both RedHat
and now Mandrake are shipping with the TLS versions of libGL and cause
the binary DRI packages
On Fri, May 21, 2004 at 03:08:41PM +0100, Keith Whitwell wrote:
> Alan Hourihane wrote:
> >I emailed Keith regarding this a while back and he had some concerns
> >over the patches used, but I just wanted to bring to light both RedHat
> >and now Mandrake are shipping with the TLS versions of libGL a
Keith Whitwell wrote:
Alan Hourihane wrote:
I emailed Keith regarding this a while back and he had some concerns
over the patches used, but I just wanted to bring to light both RedHat
and now Mandrake are shipping with the TLS versions of libGL and cause
the binary DRI packages to break.
Is there s
Keith Whitwell wrote:
Alan Hourihane wrote:
I emailed Keith regarding this a while back and he had some concerns
over the patches used, but I just wanted to bring to light both RedHat
and now Mandrake are shipping with the TLS versions of libGL and cause
the binary DRI packages to break.
Is there s
Attached is the patches from redhat source tree which are based on
XFree86 4.3.0 for review.
I think this code hits a lot of stuff that Ian has been working on, so
it'd be good if Ian has some comments.
Alan.
XFree86-4.3.0-redhat-libGL-opt-v2.patch.bz2
Description: BZip2 compressed data
XFree
Alan Hourihane wrote:
I emailed Keith regarding this a while back and he had some concerns
over the patches used, but I just wanted to bring to light both RedHat
and now Mandrake are shipping with the TLS versions of libGL and cause
the binary DRI packages to break.
Is there someone looking to inte
22 matches
Mail list logo
