- Wine-Devel - list.winehq.org

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

Dan Kegel wrote: > > If it turns out glibc's new __thread variable support really can do what > you need on all platforms, do you agree that it might be better to use > that? Insert the word "new" between "all" and "platforms", and maybe you'll have more of an appreciation for my point of view :-) > Which platforms are those? I didn't see this in your previous email. How about basically every IA32 Linux installation out there (or, at the very least, those that are currently supported by our drivers)? How many people are actually using systems that have full support for __thread? As I understand it, RedHat 8.1 will be the first large-scale release that does. -- Gareth

2 1

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

Daniel Jacobowitz wrote: > > Note the "always" in Roland's paragraph. Note the fact that he said it would require one of the dynamic access models (GD or LD), which require at least one function call to access thread local variables. As I've said, this is an unacceptable hit on performance. > When you say two or three, are these two or three pointers or two or > three large tables? Two or three pointers. I'm pretty sure we use less than 8 pointers all up, although many of those aren't performance critical. Three of ours most definitely are, and it would be nice if moving to a couple more didn't break things. We only ever use thread-local pointers, never whole structs or anything like that. > In any case, it sounds like you could: > - select the thread-local variables that you need fast access to > - Arrange for those variables to be tagged with an > __attribute__((tls_model("initial-exec"))), or something similar. > - Make sure the TLS_STATIC_SURPLUS is big enough to hold them. Will this be okay, considering that two shared libraries will need access to the variables (libGL.so itself and the driver backend)? Can you use IE or LE with variables that live in another shared library? > I don't see a problem, but you'd have to do some serious reading of the > TLS ABI documents.... they're quite thorough. Sure, the code itself isn't hard to understand. The problem is, at runtime, how do I know what code to generate to access a given __thread variable? Do I have do disassemble a function that accesses the variable to know the right model to use? Fixed offsets make this trivial, but maybe this isn't a real problem after all. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 1

wine-patches broken?
by Stefan Leichter Feb. 22, 2003

Feb. 22, 2003

Hello, since Thursday i have tried two times to send a mail to wine-patches but the mails does not show up there. I have also check the archive on winehq. The mails are not in. To check the mail account i have send the last mail to another email address of me, where it was received. Anyone else have this problem? There are two special things on my email account that may trigger the problem: * the email address used for posting has mail delivery disables for the mailing lists wine-patches and wine-devel. * the domain the mails are send (t-online.de) do not match the domain of the email address. This causes sometimes problems with spamfilers, abuse ... Bye Stefan

1 0

Re: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

Roland McGrath wrote: > > These people clearly haven't read all of the TLS paper, or looked at the > GCC implementation of __thread long enough to notice -ftls-model and > __attribute__ ((tls_model)). This is what I was talking about. I've read the entire document several times, and still can't see a way that a dynamically loadable shared library can be guaranteed to use the single-instruction Local Exec access model. If I'm wrong, please explain why. > I think the TLS document intends to explain what the models mean in > practical terms on each architecture, but I can believe it's not all > that clear. The GCC manual doesn't explain the access models and code > sequences, just tells you how to tell the compiler what you want in the > terms that the TLS document defines. > > If you want maximal flexibility, i.e. to always work with dlopen, then > indeed you must use the "dynamic" TLS access models (GD or LD). You can > use the Initial Exec model if you want faster accesses at the cost of some > flexibility. libGL.so simply has to work with dlopen -- if for no other reason than essentially all major 3D games (Quake3, Doom3, UT2003 etc) dlopen libGL.so rather than linking with it. This is not going to change. > When compiling PIC, IE-model accesses have one additional indirection, > i.e. loading the offset from the GOT just as the address of a global > variable is loaded in PIC. See the instruction sequences in the TLS spec. I'm pretty sure all implementations of OpenGL are not compiled as PIC at this point in time. That's a whole other discussion, however. > If you use static linking, these instruction sequences reduce to constants > at link time (i.e. direct "%gs:NNN" accesses on x86). Can you describe how I could use static linking here? As I said, libGL.so must be a dynamically loadable shared library. What we want is the single-instruction Local Exec access model. At this point in time, my understanding of the situation is that these are mutually exclusive requirements. > If you link a shared object containing IE-model access relocs, the object > will have the DF_STATIC_TLS flag set. By the spec, this means that dlopen > might refuse to load it. As I said, not being able to dlopen libGL.so is unacceptable. > In glibc, we actually allocate some excess space in the thread-local > storage area layout determined at startup time. This lets a dynamically > loaded module use static TLS if its PT_TLS segment fits in the available > surplus. (In sysdeps/generic/dl-tls.c, see TLS_STATIC_SURPLUS.) If there > is insufficient space preallocated, then loading the module will fail. In > fact, we put this feature there with GL in mind and can adjust the > preallocated surplus for what is most useful in practice. I think the set of performance critical thread-local variables is something like two or three (depending on the implementation). The libGL.so API dispatcher needs fast access to one or two of these (dispatch table pointers), while the driver backend needs fast access to all of them (context pointer and dispatch table pointers). The other thread-local variables are generally not accessed in performance-critical situations. Another issue I forgot to mention, or forgot to make clear, is that we need to be able to access these thread-local variables in runtime generated code. A driver's top-level API functions are often generated at runtime, and need to be able to do things like switch dispatch tables (obviously, they'd have direct access to the context they were associated with, and so wouldn't need to go through the pointer in TLS). Are we guaranteed that the __thread variables aren't going to move around? How would we work out what code to generate to access a given __thread variable? (I've included both phil-list and wine-devel, if you'd like this discussion kept to one or other of these lists, please say so). -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

3 2

RE: Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

Dan Kegel wrote: > > It does look like the TLS model does what you want it to, > and no new methods are needed. Can you explain in more detail > why your new proposal is needed, if you still think it is? To be clear, what I'm proposing requires ZERO code changes to Wine and glibc. It will work today, with Wine implementations already in the field. All I'm proposing we do is make sure it continues to work in the future, irrespective of the decision made regarding the use of glibc's new __thread variable support. As I said in my last email, there are some unresolved issues with using __thread variables: 1) We need fast TLS access on platforms where __thread variables are not supported. 2) libGL.so must be able to be dynamically loaded. Failing to dlopen libGL.so will, at the very least, make the entire Linux gaming community very unhappy :-) 3) It is unclear how online generated code can interact with __thread variables. Perhaps this is simpler than I think... -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

3 2

wcmd/wine default window configuration
by J. Grant Feb. 22, 2003

Feb. 22, 2003

Hello I have been using wcmd lately, its been really useful to my research. However, could wcmd default to its "command history" (a la doskey) value to something other than zero please? Perhaps 50 would be enough, it would not take up much memory for the queue strcture I think. I do not know if this is wcmd, but the wcmd context menu uses a serif font. I think in UI design serif is not a good choice... most programs use a sans serif one, such as the widget in wcmd->propeties. Sans serif is generally accepted as more appealing in most contexts. It would be great if the wcmd text area was bigger too, current it starts as 80x25, however, if I change it to 80x80 in the wcmd prefs (then resize the window, as it does not auto adjust) and type "dir" the same top 80x25 chars are the only ones used to display text. I ran cmd.exe from within wcmd and the same problem showed up. So it appears that its either the way Wine displays windows, or wcmd. I tried "wineconsole ./cmd.exe" too, that locked up my terminal with lots of NCURSES fixme printf's. cmd.exe in MS-Windows is resizable vertically, and the extra lines are used. Regards JG

3 6

Fast thread-local storage for OpenGL drivers
by Gareth Hughes Feb. 22, 2003

Feb. 22, 2003

It is critically important for OpenGL drivers to have fast (single-instruction) access to thread local variables. I'd be happy to provide more information to anyone who's interested, but a typical case where TLS access can severely hurt performance is at the very front-end of an OpenGL library. Ideally, you'd like something like the following: libGL.so: // This function loads a dispatch table pointer from // thread-local storage and jumps through to the // backend function (which typically resides in a // different shared library). glTexCoord2f: mov %fs:DISPATCH_TABLE_OFFSET, %eax jmp *__glapi_TexCoord2f(%eax) // Points to __my_TexCoord2f libGLcore.so: // This function copies some data into the OpenGL // context, sets some magic flags to record what data // was copied, and returns. __my_TexCoord2f: mov %fs:CONTEXT_OFFSET, %eax // Copy 2 floats into the context // Set a flag ret All in all, you have 2 TLS accesses in less than 10 instructions or so. Even if you don't understand exactly what's going on here, you can see that it is important to have fast access to thread-local data. While glibc's new thread library implementation has many benefits, particularly to application programmers (with support for the new keyword '__thread', and so on), it basically forces a function call per thread local variable access for situations like the one I described above. This is clearly unacceptable for a high-performance OpenGL driver. Furthermore, the glibc developers have been completely unwilling to work with OpenGL driver developers (Open Source or otherwise) to provide a mechanism to access thread-local data in a way that meets our performance requirements. Therefore, I'd like to propose a solution where Wine and the OpenGL driver cooperate to provide such a TLS access mechanism (at least on x86 platforms). Wine currently uses %fs to access the Windows Thread Environment Block (TEB), while glibc uses %gs to access its per-thread data. With the following patch to Wine's TEB structure: --- include/thread.h 2002-12-17 16:06:25.000000000 -0500 +++ include/thread.h.new 2003-02-21 14:27:50.000000000 -0500 @@ -116,10 +116,12 @@ DWORD alarms; /* --3 22c Data for vm86 mode */ DWORD vm86_pending; /* --3 230 Data for vm86 mode */ void *vm86_ptr; /* --3 234 Data for vm86 mode */ + /* here is plenty space for wine specific fields (don't forget to change pad6!!) */ + DWORD pad6[608]; /* --n 238 */ + DWORD ogl_data[16]; /* --n bb8 OpenGL driver private data */ /* the following are nt specific fields */ - DWORD pad6[624]; /* --n 238 */ UNICODE_STRING StaticUnicodeString; /* -2- bf8 used by advapi32 */ USHORT StaticUnicodeBuffer[261]; /* -2- c00 used by advapi32 */ void *stack_base; /* -2- e0c Base of the stack */ we reserve %fs:0xbb8 to %fs:0xbf8 for use by the OpenGL driver. Any and all OpenGL implementations can use this area, and we agree that when Wine is present, it leaves this area untouched. The question of who allocates the TEB should be pretty straight forward: when an OpenGL driver is first loaded, if the TEB is missing it is allocated as expected. I would imagine when Wine is running that it would have the chance to allocate the TEB before the OpenGL driver is loaded, and thus the OpenGL driver wouldn't have to do anything. The size of the reserved area should be sufficient, although we can debate that if required. Comments, questions are welcome. I've CC'ed Brian Paul and Keith Whitwell of Mesa/DRI fame, as I know they are interested in this issue. Please CC us on any replies, as we are not subscribed to the list. -- Gareth Hughes (gareth(a)nvidia.com) OpenGL Developer, NVIDIA Corporation

2 3

wcmd mark/paste
by J. Grant Feb. 22, 2003

Feb. 22, 2003

Hi, wcmd mark/paste has greatly improved since the last version, the current CVS feels very good so far. However, to copy text it is still not possible to drag over the text as in other X apps. In fact even if Context menu->Edit->Mark is selected it is necessary to use the keyboard to increase the selection area. This is not very quick because keyboard repeat is not used, so I have to hammer my arrow keys like I am playing an old Atari game! (perhaps related to the other X11 Clipboard thread currently) I'm glad to see the copied text is not corrupted anymore The wine debugger also exhibits this problem. The "quick edit" functionality is great, however I am still getting an extra date column on the right of my pastes when typing "dir" (date column is on the left of dir output). Regards JG

4 7

Building WinMM on mingw
by Steven Edwards Feb. 22, 2003

Feb. 22, 2003

I think the export in ntdll may be wrong playsound.o(.text+0x7d7): In function `PlaySound_Alloc': e:/users/steven/source/wine/dlls/winmm/playsound.c:222: undefined reference to `RtlCreateUnicodeStringFromAsciiz(a)8' E:\users\steven\mingw\bin\dllwrap.exe: E:\users\steven\mingw\bin\gcc exited with status 1 make: *** [winmm.dll] Error 1 Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/

2 1

registry patch
by Matthieu Foillard Feb. 22, 2003

Feb. 22, 2003

Hi, this fix a bug when data is null. (3dsmax v3 now works with this) Note that i'm not a wine developper and this patch might not be the right way to fix the problem. Someone on #winehq told me this is acceptable so... Index: dlls/advapi32/registry.c =================================================================== RCS file: /home/wine/wine/dlls/advapi32/registry.c,v retrieving revision 1.50 diff -u -3 -p -r1.50 registry.c --- dlls/advapi32/registry.c 20 Jan 2003 23:23:12 -0000 1.50 +++ dlls/advapi32/registry.c 14 Feb 2003 22:49:13 -0000 @@ -902,7 +902,7 @@ DWORD WINAPI RegSetValueExA( HKEY hkey, if (!is_version_nt()) /* win95 */ { - if (type == REG_SZ) count = strlen(data) + 1; + if (type == REG_SZ && data != NULL) count = strlen(data) + 1; } else if (count && is_string(type)) { -- Matthieu Foillard <m.foillard(a)taktile.com> tel : 0146090496 - gsm : 0686574170 pgp : 0x1609654F

2 1