Okay, here's an almost-functional implementation of an OpenGL dispatch
layer and driver backend. The dispatching into a dlopened driver
backend works, the backend just doesn't do anything terribly interesting
yet (been struggling with bad allergies all week, so I'm not thinking
very clearly a
I'm putting the finishing touches on some example asm code that might be
generated at runtime by an OpenGL driver, to go with a sample dispatch
layer, that exercises some of the issues we've been discussing over the
past week. As it's 6:20am, I might go home and sleep first though ;-)
Thanks to
Keith Whitwell wrote:
>
> Gareth,
>
> A simplified example of the dispatch & codegen layers sounds like an
> excellent way to get across the performance environment we're working
> in. Let me know if I can help putting this together.
Agreed -- hence the effort to put this together ;-)
I'm e
>
> Yes, in coding up an example to send you all, this issue became clear to
> me. We need to define thread-local variables in libGL.so and reference
> them from a dlopened driver backed. The important functions that
> reference these variables are often tiny (less than 10 instructions), so
Keith Whitwell wrote:
>
>>
>> __thread doesn't require -fpic. There are 4 different TLS models (on
>> IA-32):
>> -ftls-model=global-dynamic
>> -ftls-model=local-dynamic
>> -ftls-model=initial-exec
>> -ftls-model=local-exec
>>
>> Neither of these require -fpic, though the first 3 use pic
>> regis
>
> __thread doesn't require -fpic. There are 4 different TLS models (on IA-32):
> -ftls-model=global-dynamic
> -ftls-model=local-dynamic
> -ftls-model=initial-exec
> -ftls-model=local-exec
>
> Neither of these require -fpic, though the first 3 use pic
> register (if not -fpic, they just load i
On Tue, May 21, 2002 at 05:09:00PM -0700, Gareth Hughes wrote:
> David S. Miller wrote:
> >
> > Even if this were not the case, stupid compilation tools are not an
> > excuse to put changes into the C library. That is a fact.
>
> We've been talking about two completely separate issues:
>
>
David S. Miller wrote:
>
> Even if this were not the case, stupid compilation tools are not an
> excuse to put changes into the C library. That is a fact.
We've been talking about two completely separate issues:
- Fast thread-local storage for libGL and GL drivers.
- PIC for libGL and GL
David S. Miller wrote:
>
> Why does it matter? Jakub has shown how to get the same kind of
> non-PIC relocations you want in the GL libraries by using private
> versions of symbols.
Using a feature that is "a very new thing" (to quote Jakub) -- only "GCC
3.2 (mainline CVS), the Red Hat GCC
Sorry for the delay in getting back to you, I've been offline since late
last week moving into a new building at work.
I've been working on some sample code that clearly demonstrates the
issues we (as in vendors of OpenGL on Linux) face. I'm hoping to have
that wrapped up this afternoon and w
On Thu, 2002-05-16 at 20:08, Gareth Hughes wrote:
>
> > Beside, I don't understand why you react like this. Using __thread is
> > the best you can ever get. It'll be portable (Solaris 9 already has the
> > support as well) and it's faster than anything you can get to access the
> > data.
>
> I
Dieter Nützel <[EMAIL PROTECTED]> wrote:
> Only short question/remark.
>
> Does this all play nicely with IBM's NGPT
> http://oss.software.ibm.com/pthreads/ ?
I'm not familiar with that project yet, but there's no reason why it
can't (if they hang the TCB off %gs as well).
-- Gareth
Only short question/remark.
Does this all play nicely with IBM's NGPT
http://oss.software.ibm.com/pthreads/ ?
Thanks,
Dieter
--
Dieter Nützel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: [EMAIL PROTECTED]
Jakub Jelinek wrote:
> On Fri, May 17, 2002 at 01:17:22PM +0100, Keith Whitwell wrote:
>
>>The __indirect stuff is rarely used.
>>
>
> Ok, fine. But if it is rarely used, why isn't it -fpic?
The dispatch table in libGL.so is used all the time - this thread was started
by Gareth with discuss
On Fri, May 17, 2002 at 01:17:22PM +0100, Keith Whitwell wrote:
> The __indirect stuff is rarely used.
Ok, fine. But if it is rarely used, why isn't it -fpic?
Few more random things which might help the drivers:
1) using fprintf (stderr, ...) all around is a bad idea,
that means 2 runtime rel
Jakub Jelinek wrote:
> On Fri, May 17, 2002 at 10:48:07AM +0100, Keith Whitwell wrote:
>
>>Yes, we've been aware of this for a little while. One thing that we've got a
>>bit of in there is assembly for the non-threaded dispatch case (the opensource
>>libGL.so doesn't really handle the threaded
On Fri, May 17, 2002 at 10:48:07AM +0100, Keith Whitwell wrote:
> Yes, we've been aware of this for a little while. One thing that we've got a
> bit of in there is assembly for the non-threaded dispatch case (the opensource
> libGL.so doesn't really handle the threaded case in a performant way, b
Jakub Jelinek wrote:
>>And gcc -v gives:
>>
>>gcc version 2.96 2731 (Mandrake Linux 8.1 2.96-0.62mdk)
>>
>>Is this a versions thing or am I screwing up elsewhere?
>>
>
> It is a very new thing.
> Only GCC 3.2, the Red Hat GCC 3.1 package and gcc-2.96-RH >= 2.96-108
> (dunno which Mandrake v
On Fri, May 17, 2002 at 11:50:10AM +0100, Keith Whitwell wrote:
> OK, trying the __attribute__ stuff doesn't seem to work for me:
>
>
> f12.h:3: warning: `visibility' attribute directive ignored
> f12.h:4: warning: `visibility' attribute directive ignored
>
>
> Where f12.h looks like:
>
> ---
> create either linker script like:
> { global: gl*; DRI*; XF86DRI*; local: *; }
> or
> GL_1.0 { global: gl*; DRI*; XF86DRI*; local: *; }
> then pass this file to linker at libGL.so link time, like
> gcc -shared ... -Wl,--version-script,libGL.map ...
>
> This way you get rid of most R_386_PC32 r
Jakub Jelinek wrote:
>
> On Fri, May 17, 2002 at 12:30:56AM +0100, Keith Whitwell wrote:
> > > BTW: Last time I looked at libGL (in March), these were things which I
> > > came over:
> > > 1) libGL should IMHO use a version script (at least an anonymous one
> > >if you want to avoid assigning
Jakub Jelinek wrote:
> On Thu, May 16, 2002 at 08:08:02PM -0700, Gareth Hughes wrote:
>
>>Let's be clear about what I'm proposing: you agree to reserve an
>>8*sizeof(void *) block at a well-defined and well-known offset in the
>>TCB. OpenGL is free to access that block, but only that block.
>
Jakub Jelinek wrote:
>
> On Thu, May 16, 2002 at 08:08:02PM -0700, Gareth Hughes wrote:
> > Let's be clear about what I'm proposing: you agree to reserve an
> > 8*sizeof(void *) block at a well-defined and well-known offset in the
> > TCB. OpenGL is free to access that block, but only that block
On Thu, May 16, 2002 at 08:08:02PM -0700, Gareth Hughes wrote:
> Let's be clear about what I'm proposing: you agree to reserve an
> 8*sizeof(void *) block at a well-defined and well-known offset in the
> TCB. OpenGL is free to access that block, but only that block.
But you define no way how l
On Fri, May 17, 2002 at 10:22:23AM +0300, Momchil Velikov wrote:
> > "Jakub" == Jakub Jelinek <[EMAIL PROTECTED]> writes:
>
> >> How do you detect threading without making these calls to libpthreads.so?
>
> Jakub> Weak symbols.
>
> Jakub> extern pthread_t pthread_self (void) __attribute__ (
> "Jakub" == Jakub Jelinek <[EMAIL PROTECTED]> writes:
>> How do you detect threading without making these calls to libpthreads.so?
Jakub> Weak symbols.
Jakub> extern pthread_t pthread_self (void) __attribute__ ((weak));
Jakub> (resp. #pragma weak pthread_self).
Jakub> Then if (&pthread_se
On Fri, May 17, 2002 at 12:30:56AM +0100, Keith Whitwell wrote:
> > BTW: Last time I looked at libGL (in March), these were things which I
> > came over:
> > 1) libGL should IMHO use a version script (at least an anonymous one
> >if you want to avoid assigning a specific GL_x.y symbol version
A question about the __thread stuff: does it require -fPIC? What
happens if you don't compile a library with -fPIC, and have __thread
variables declared in that library?
-- Gareth
___
Have big pipes? SourceForge.net is looking for d
Gareth Hughes wrote:
>
> Let's be clear about what I'm proposing: you agree to reserve an
> 8*sizeof(void *) block at a well-defined and well-known offset in the
> TCB.
Of course, I should add that space for such a block exists, and has
existed for some time. My proposal requires no real cha
Ulrich Drepper wrote:
>
> Everything which is not part of glibc is third-party. It's the same as
> if some program would require access to internal data structures of
> libGL. There are several different layouts of the thread descriptor and
> it's only getting worse. The actual layout doesn't
On Thu, 2002-05-16 at 17:54, Gareth Hughes wrote:
> What do you mean, a third party program? We're talking about a system
> library (libGL.so) here.
Everything which is not part of glibc is third-party. It's the same as
if some program would require access to internal data structures of
libGL
Ulrich Drepper wrote:
>
> This is the only way you'll get access to thread-local storage. It is
> out of question to allow third party program peek and poke into the
> thread descriptor.
What do you mean, a third party program? We're talking about a system
library (libGL.so) here. There is a
On Thu, 2002-05-16 at 15:41, Gareth Hughes wrote:
> I would like to propose a small change to the pthread_descr structure in
> the latest LinuxThreads code, to better support OpenGL on GNU/Linux
> systems (particularly on x86, but not excluding other platforms). The
> purpose of this patch is to
Jakub Jelinek wrote:
> Hi!
>
> What percentage of applications use different dispatch
> tables among its threads? How often do dispatch table changes
> occur? If both of these are fairly low, computing a dispatch table
> in an awx section at dispatch table switch time might be fastest
I should a
Gareth Hughes wrote:
>
> Keith Whitwell wrote:
> >>
> >>2) last time I looked, libGL.so was linked unconditionally against
> >> libpthread. This is punnishing all non-threaded apps, weak undefined
> >> symbols work very well
> >
> >
> > This is because we currently use the standard way of ge
Keith Whitwell wrote:
>>
>>2) last time I looked, libGL.so was linked unconditionally against
>> libpthread. This is punnishing all non-threaded apps, weak undefined
>> symbols work very well
>
>
> This is because we currently use the standard way of getting thread-local-data
> and detectin
Jakub Jelinek wrote:
>
> Hi!
>
> What percentage of applications use different dispatch
> tables among its threads? How often do dispatch table changes
> occur? If both of these are fairly low, computing a dispatch table
> in an awx section at dispatch table switch time might be fastest
> (ie. p
Jakub Jelinek wrote:
> Hi!
>
> What percentage of applications use different dispatch
> tables among its threads? How often do dispatch table changes
> occur? If both of these are fairly low, computing a dispatch table
> in an awx section at dispatch table switch time might be fastest
> (ie. prep
Hi!
What percentage of applications use different dispatch
tables among its threads? How often do dispatch table changes
occur? If both of these are fairly low, computing a dispatch table
in an awx section at dispatch table switch time might be fastest
(ie. prepare something like:
.section dispat
39 matches
Mail list logo
