Re: Thread Local Storage libGL
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 DISPATCH(FUNC, ARGS, MESSAGE) \ (_glapi_Dispatch-FUNC) ARGS to: #define DISPATCH(FUNC, ARGS, MESSAGE) \ const struct _glapi_table * d = _glapi_Dispatch;\ if ( __builtin_expect( d == NULL, 0 ) )\ d = get_dispatch();\ (d-FUNC) ARGS There is some extra cost in the non-threaded case, but it seems very minimal. In the x86 assembly case, it's only a test and a conditional branch that is usually not taken. Does this seem like a reasonable change to make across the board? Hmm. The _ts_* macros were introduced to eliminate exactly that sort of test - though we probably coded it up in a less optimal way than that. Are you saying that the dispatch tables would really become compiled 'C'? At the moment they are typically generated as assembly and use a jmp rather than calling a new function as in either of the examples above. 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 really clear about that before. My proposal is to modify the C version, the x86 assembly version, and the SPARC assembly version. I've worked up a patch to gl_x86_asm.py that I can post on Monday. Some time in the next couple weeks I'm going to create PowerPC dispatch stubs. The PPC ABI is a little odd, though, so it may not be trivial. My feeling is that the non-threaded case should run as fast as possible, being the normal usage. Maybe some timings would make things clearer. Since the branch is going to be correctly predicted every time it's executed (in the non-threaded case), the performance hit should be on the order of a couple clock-cycles. I should be able to get some timings on Monday or Tuesday. I'll just do a loop of calling some GL function a million times or something. Any idea which function would be likely to take the least time to execute? I want to find the case where the dispatch functions have the most impact. Just stick a return at the top of some random function use that... Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Thread Local Storage libGL
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. I wasn't really clear about that before. My proposal is to modify the C version, the x86 assembly version, and the SPARC assembly version. I've worked up a patch to gl_x86_asm.py that I can post on Monday. Just to get every one on the same page. The SPARC assembly version is only for solaris. It dose not, and can not, even build on linux! Last time I checked DRI would not build on SPARC/Linux, crashing on the Solaris ASM code. Hmm, there are definite references to __linux__ in the code - looks like the intention is there. Why not look at the generator scripts post a patch to fix it? Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
No problem, here it is. Kristian Andr Ventura Lemos wrote: I'm getting: tar: Read 2380 bytes from gradients.tar.tar tar: This does not look like a tar archive tar: Skipping to next header tar: Error exit delayed from previous errors Could you please send me over the tarball? Thanks On Sun, 2004-05-23 at 18:57, Kristian Hgsberg wrote: I'm getting the same lockups, and I can consistently reproduce it with the simple GL program in this mail: http://cairographics.org/pipermail/cairo/2004-April/001175.html The example with the 1D texture runs fine, but the 2D example locks up my machine. HTH, Kristian gradients.tar.gz Description: GNU Zip compressed data
Re: drm 830 problem
This only happens with 2.6 kernels. Prior do the lockup, everything works (I can see it through ssh), but the display gets blank, and never comes back. doesn't happen for me, 00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics Device (rev 02) [drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82865G Integrated Graphics Device OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 865G 20040506 x86/MMX/SSE2 OpenGL version string: 1.2 Mesa 6.1 This is the latest DRM on a 2.6.6 kernel, you migt want to try 2.6.7-rc1 to check if it is a DRM issue, what XFree reelase are you running .. Dave. On Fri, 2004-05-21 at 18:07, Keith Whitwell wrote: Do you mind if I take this to dri-devel? What happens prior to the lockup? Does it only happen with 2.6 kernels? Keith Andre - Can you give any more information on what might be triggering the lockups? I'm getting the same lockups, and I can consistently reproduce it with the simple GL program in this mail: http://cairographics.org/pipermail/cairo/2004-April/001175.html The example with the 1D texture runs fine, but the 2D example locks up my machine. HTH, Kristian --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id[81]66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Development setup
Maurice van der Pot wrote: I have just started looking into DRI development and I have been experiencing some difficulties using gdb. For example, I cannot currently step into functions of libGL (it was compiled with debug info and LD_LIBRARY_PATH is set correctly). Another thing is that the symbols from r200_dri.so are only loaded after I have typed sharedlibrary r200_dri, they're not loaded automatically when the shared object is loaded even though gdb's option (I forget its name) to autoload symbols is on. How are you building? Are you building everything in the DRI tree? libGL in the DRI tree and the drivers in the Mesa tree? The libGL built in the Mesa tree is *NOT* the one used with the DRI drivers. The libGL built in the DRI tree (or from the DRI binary snapshots) should have all the debug symbols included. As for r200_dri.so, are you sure it's getting the right one? If you run with 'LIBGL_DEBUG=verbose' it will print out which driver binary is being used. Realistically, you *need* two systems for driver debugging. I've found that using a skunky old laptop to ssh in and run gdb is the best setup. In a pinch, an old 286 with a terminal program as a serial terminal will also work. As I was struggling to put together a convenient setup for debugging it got me wondering how those of you who use gdb for debugging have things set up. I'm interested to know things like locations of compiled libs/executables wrt the system libs, environment variables, makefile/config modifications, etc. For a developer, the best bet is to get the DRI tree and the Mesa tree. Build the DRI tree and do a 'make install' as root *once*. Then do your development in the Mesa tree, build your drivers in the Mesa tree, and run with 'LIBGL_DRIVERS_DIR' set to the lib directory in the Mesa tree (i.e., from the top of the Mesa tree do 'export LIBGL_DRIVERS_DIR=$(pwd)/lib'. Maybe I can gather this information into a document on the Wiki later on. Not a bad idea. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Thread Local Storage libGL
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. I wasn't really clear about that before. My proposal is to modify the C version, the x86 assembly version, and the SPARC assembly version. I've worked up a patch to gl_x86_asm.py that I can post on Monday. Just to get every one on the same page. The SPARC assembly version is only for solaris. It dose not, and can not, even build on linux! Last time I checked DRI would not build on SPARC/Linux, crashing on the Solaris ASM code. Does the code in src/mesa/glapi/glapi.c (generate_entrypoint specifically) cause the crash or just the code in src/mesa/sparc/glapi_sparc.S? My guess is that Linux uses 32-bit user-mode, but the asm code in glapi_sparc.S defaults to 64-bit on v9. Perhaps we could come up with a better define, such as USE_SPARC_32BIT_USER to determine which stubs to build. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Thread Local Storage libGL
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 assembly, not the C version. I wasn't really clear about that before. My proposal is to modify the C version, the x86 assembly version, and the SPARC assembly version. I've worked up a patch to gl_x86_asm.py that I can post on Monday. Just to get every one on the same page. The SPARC assembly version is only for solaris. It dose not, and can not, even build on linux! Last time I checked DRI would not build on SPARC/Linux, crashing on the Solaris ASM code. Does the code in src/mesa/glapi/glapi.c (generate_entrypoint specifically) cause the crash or just the code in src/mesa/sparc/glapi_sparc.S? My guess is that Linux uses 32-bit user-mode, but the asm code in glapi_sparc.S defaults to 64-bit on v9. Perhaps we could come up with a better define, such as USE_SPARC_32BIT_USER to determine which stubs to build. I just committed a version of the entrypoint generator script based on the new XML Python code. I played around with the output of that on a SPARC based SunOS 5.9 (from uname) box. It looks like when 64-bit binaries are generated (i.e., -m64 is used), __arch64__ is defined. If 32-bit binaries are generated it is not defined. This was true with GCC 2.95.2, 3.0, and 3.3. It turned out that __sparc_v9__ was *never* defined, even if -mcpu=v9 was supplied. None of the SPARC systems that I have access to have Sun's compiler installed, so I don't know if that also defined __arch64__ when building 64-bit binaries. If SPARC Linux also gets the __arch64__ treatment, I'd suggest that we use that determine which version of the stub to use instead of a combination of __sparc_v9__ and __linux__. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xorg] Re: Damage/Composite + direct rendering clients
Andy Ritger wrote: The other concern (how to make sure direct rendering has completed by the time the drawable is used as a source in a composite operation) conceptually would be solved as you describe, but I expect the implementation would be buried deeper I guess I don't see what the problem is. The graphics device processes commands as a FIFO. Groups of direct rendering commands are surrounded by a lock. If the compositor uses the same lock, synchronization and proper ordering are guaranteed. Determining if direct rendering has damaged a region is another kettle of fish, though... --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Getting a DRM right from the start
Sorry for taking so long to reply. In some cultures, taking 9 days to reply to an e-mail means that much thought was put into the reply. ;) Felix Kühling wrote: === Header files in the DRM === drm.h: driver-independent types and definitions for the 3D driver to communicate with the DRM. Driver-indepenent / OS-independent. drmP.h: driver-independent internal types and definitions. Driver-indepenent / OS-dependent. savage_drm.h: any definitions needed by the 3D driver to communicate with the DRM (sarea, sarea defines, ioctl parameter structures). Someone recently proposed to use a sanitized copy of this file (and probably drm.h) in the 3D driver instead of the kernel header file. That would mean that these definitions have to be kept in sync in 3 places: kernel, sanitized user-space copy and Xserver (see below). Does that make sense? Basically, this defines the user / kernel interface for the driver. savage_drv.h: driver-internal data types like the dev_private structure and function prototypes, some macros for BCI access. savage.h: DRM template customization === Header files in the Xserver === savage_sarea.h: Basically a copy of the sarea defines and sarea structure in the kernel but with different naming conventions. I vaguely remember that this was because of XFree86's policy not to use external header files or something such. savage_common.h: Ioctl parameter structures with XFree86 naming conventions. Same rationale as for savage_sarea.h, I guess. Close. There used to be separate *_drm.h files for each operating-system. For some drivers, such as i830, there still is. The XFree86 policy is to not include platform-dependent files, so a new file that mirroed the stuff in the OS dependent files was needed. In modern drivers, anything that lives in drm/shared can be considered platform-independent, IMHO. === 64bit issues === Basically any fields in data structures shared between kernel and user-space must have a fixed size in order to allow 32-bit user space to work with a 64-bit kernel. Is that correct? Then what are the right types (u32, __u32, uint32, ...?) that are available in both the kernel (possibly linux and BSD) and user-space? Or if we're not going to share header files between kernel tree and 3D drivers, then what types would be used in the kernel and which types in user-space? IMO, the C99 types should be used. That is the portable, future-proof way. I seem to recall some Linux kernel developers having issue with anything other than __u32 / __u64 (or was it u32 / u64?) being used, but I don't know what they were. On any given platform, __u32 had better be the exact same type as the C99 uint32_t, or that platform is broken! For keeping the DRM portable among OS's, should fixed-size number types be defined in drm.h/drmP.h? Yuck. :( Nobody wants more types that mean the same thing as existing types. Having drm_u32_t or some such sounds really, really unpleasant. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
Dave Airlie wrote: This only happens with 2.6 kernels. Prior do the lockup, everything works (I can see it through ssh), but the display gets blank, and never comes back. doesn't happen for me, 00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics Device (rev 02) I have 00:02.0 VGA compatible controller: Intel Corp. 82830 CGC [Chipset Graphics Controller] (rev 04) [drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82865G Integrated Graphics Device [drm] Initialized i830 1.3.2 20021108 on minor 0: [drm] Initialized i830 1.3.2 20021108 on minor 1: OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 865G 20040506 x86/MMX/SSE2 OpenGL version string: 1.2 Mesa 6.1 I have OpenGL vendor string: VA Linux, Inc OpenGL renderer string: Mesa DRI Intel(R) 830M 20021115 x86/MMX/SSE OpenGL version string: 1.2 Mesa 5.0.2 This is the latest DRM on a 2.6.6 kernel, you migt want to try 2.6.7-rc1 to check if it is a DRM issue, what XFree reelase are you running .. I'm running 2.6.6 too with the X.org 6.7.0 release. Basically, the latest from Fedora devel. I tried to update Mesa to the latest (6.0.1) and now it seems to work - it doesn't crash, but the gradient example I mentioned earlier comes out flat-shaded... Thanks, Kristian --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i830 texture compression support..
Dave Airlie wrote: The attached patch provides s3tc (and broken fxt) texture compression support on the i8xx (x30) chipsets, You need to apply the radeon/r200 patch from Roland first, Roland do you want to merge this patch into yours? Yes, I've merged it. New version can be found here (so I don't have to spam the list with code): http://homepage.hispeed.ch/rscheidegger/dri_experimental/libtxc_dxtn040524.tar.gz http://homepage.hispeed.ch/rscheidegger/dri_experimental/mesa_r200_radeon_i830_txc_cvs040524.diff.gz (nothing new except the i830 merge). (sorry no directory listing, seems to be not allowed for homepages, and the stupid server doesn't honor .htaccess neither) I have one question though, how is RGB_DXT1 and RGBA_DXT1 going to work? As far as I can see, there's no difference at all between these two formats as far as the driver is concerned, which can't be correct (pixels which need to get decompressed as black, fully opaque for RGB_DXT1 need to be black, fully transparent for RGBA_DXT1). I'm not sure how this is supposed to work, maybe with changing texture environments? I guess RGBA_DXT1 isn't used a lot though (the compression library also does not a good job for that weird format). So far I've tested this with texcmp - thats how I know FXT doesn't work, do we have support for FXT in Mesa? No, and since texcmp only uses on-line compressed textures, it sure will fail. I did not add FXT support in the s3tc patch since I lack the hardware, and also since there are 0 applications (afaik) which use precompressed fxt1 textures (remember the patch started to make it possible to use precompressed textures, the software compression/decompression stuff was just added to make the extension support OGL-compliant). It _might_ be interesting to add fxt1 compression for on-line compression, since it might be better from a legal point of view, though it's hard to imagine that one extension (s3tc) would infringe on a patent while the other (fxt) wouldn't, given how terribly similar they are (at least the fxt1 cc_mixed mode)... I believe though Daniel Borca is working on it (by using code from the Glide3/Texus2 library). do I have any chance of getting ut2004 demo going on an i865 chipset? at the moment I'm missing some floors and things.. Can't help you there ;-). Roland --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
I'm getting: tar: Read 2380 bytes from gradients.tar.tar tar: This does not look like a tar archive tar: Skipping to next header tar: Error exit delayed from previous errors Could you please send me over the tarball? Thanks On Sun, 2004-05-23 at 18:57, Kristian Høgsberg wrote: I'm getting the same lockups, and I can consistently reproduce it with the simple GL program in this mail: http://cairographics.org/pipermail/cairo/2004-April/001175.html The example with the 1D texture runs fine, but the 2D example locks up my machine. HTH, Kristian -- I/O, I/O, It's off to disk I go, A bit or byte to read or write, I/O, I/O, I/O... signature.asc Description: This is a digitally signed message part
Re: [Xorg] Re: Damage/Composite + direct rendering clients
On Mon, 24 May 2004, Ian Romanick wrote: Andy Ritger wrote: The other concern (how to make sure direct rendering has completed by the time the drawable is used as a source in a composite operation) conceptually would be solved as you describe, but I expect the implementation would be buried deeper I guess I don't see what the problem is. The graphics device processes commands as a FIFO. Groups of direct rendering commands are surrounded by a lock. If the compositor uses the same lock, synchronization and proper ordering are guaranteed. How does the composite manager use the same lock? If it's simply using Render requests to perform the compositing, does the X server need to lock whenever it processes a Render request. Does it do so today? What happens if the X server performs the Render request in software? You're also assuming you have one global fifo, whereas some hardware has a separate fifo per hw graphics client and the hw context switches between fifos. Determining if direct rendering has damaged a region is another kettle of fish, though... Yes, but I actually think that is going to be the easy part :) Thanks, - Andy --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
Mike Mestnik wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: There are two types of VTs - text and graphical. It is only practical to have a single graphical VT because of the complexity of state swapping a graphical VT at VT swap. Right now we can all-ready run X on multiple VTs and with DRI-reinit can run GL apps on all of them. It may noy be the most elegant thing but it workes. We need the OS to keep state, even graphical, GART and all. I don't see how a 128M GART is diffrent then 2Gb system memory. Should we have GART swap space on the HD, a GART partition? I'm for making the OS VT swap multiheaded DR?I? setups at whatever cost. An elegant implementation would not swap the entire GART at VT switches but only present the new VT framebuffer as new display on the screen while maintaining the AGP states. Check out e.g. MacOS-X's animated multiple login screen: At every new session start the current session just rotates smoothly animated into the background and a new one is brought up. In this model you can retain the entire graphics state at VT switch, only another (currently invisible) frambuffer/screen/display/VT is made visible. This allows straightforward multihead implementations, any frambuffer/screen/display/VT can get attached to any head, they are just a piece of framebuffer memory which is either located in graphics memory or system memory and can get relocated on request, even to other graphics cards. How about this for a new way to look at the problem? System based xterm, that's a new one. I don't see how it's better then what we have now. probably not -- the MacOS-X alike approach looks more promising. At SAK a new display framebuffer would get launched and brought to front, the currently running application is only need get killed if it locks the graphics engine in an locked state. Unfortunally that means that parts of the window stack implementation need to run in kernel space (or a tightly connected trusted agent in userspace). Don't know whether this is a problem, the DirectFB core showed that it's possible to implement this cleanly in a few thousand lines of code. Holger --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
On Mon, 2004-05-24 at 11:15, Dave Airlie wrote: doesn't happen for me, 00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics Device (rev 02) :00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) [drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82865G Integrated Graphics Device [drm] Initialized i830 1.3.2 20021108 on minor 0 OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 865G 20040506 x86/MMX/SSE2 OpenGL version string: 1.2 Mesa 6.1 OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM 20021115 x86/MMX+/SSE2 OpenGL version string: 1.2 Mesa 5.0.2 This is the latest DRM on a 2.6.6 kernel, you migt want to try 2.6.7-rc1 to check if it is a DRM issue, what XFree reelase are you running .. I'm running (xorg): X Protocol Version 11, Revision 0, Release 6.7 -- I/O, I/O, It's off to disk I go, A bit or byte to read or write, I/O, I/O, I/O... signature.asc Description: This is a digitally signed message part
test savage mx
Hi all. I've tested the code on my SAVAGE MX an discovered that: - Opengl acceleration works fine, with a colour depth of only 16 bit due to lack of video ram (only 8192 k) - Xvidinfo says NO ADAPTORS FOUND, and it is almost impossible to run a dvd and so on. I used to see dvd and Xvid with Tim Robert's driver (even playing and running heavy applications) on my slackware 9.1 and I wonder if I will be able in the future with my new gentoo. Maybe there is something wrong with my XFree configuration. If so, help is welcome! Greetings Matia --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [r200] sigfault in update_light (current DRI and Mesa CVS)
On Sun, 2004-05-23 at 22:52, Dieter Ntzel wrote:
Program received signal SIGSEGV, Segmentation fault.
0x40670b99 in update_light (ctx=0x805e208) at r200_state.c:1143
1143 for (p = 0 ; p MAX_LIGHTS; p++) {
That doesn't make much sense, I don't see a pointer being dereferenced
here. Please double check your build.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: test savage mx
--- [EMAIL PROTECTED] wrote: Hi all. I've tested the code on my SAVAGE MX an discovered that: - Opengl acceleration works fine, with a colour depth of only 16 bit due to lack of video ram (only 8192 k) - Xvidinfo says NO ADAPTORS FOUND, and it is almost impossible to run a dvd and so on. H... Xv works fine for me on all my savage chips. It should work on your MX as well. is there anything weird in the log? what does xvinfo show? Alex I used to see dvd and Xvid with Tim Robert's driver (even playing and running heavy applications) on my slackware 9.1 and I wonder if I will be able in the future with my new gentoo. Maybe there is something wrong with my XFree configuration. If so, help is welcome! Greetings Matia __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
André Ventura Lemos wrote: On Mon, 2004-05-24 at 11:15, Dave Airlie wrote: doesn't happen for me, 00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics Device (rev 02) :00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) [drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82865G Integrated Graphics Device [drm] Initialized i830 1.3.2 20021108 on minor 0 OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 865G 20040506 x86/MMX/SSE2 OpenGL version string: 1.2 Mesa 6.1 OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM 20021115 The '2002' part of the date should be a hint -- please download a recent snapshot from dri.sf.net try with that. Keith --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: MergedFrameBuffer: New meta-mode syntax needed.
On Mon, 2004-05-24 at 03:25, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
On Mon, 2004-05-24 at 01:04, Mike Mestnik wrote:
--- Michel Dnzer [EMAIL PROTECTED] wrote:
I mean what about in places where this should have allready been done,
deep inside the driver. Do we just exept incorrect rendoring?
I wouldn't, but most people seem to.
* The 3D engine imposes alignment requirements on the target
buffer (1024 bytes or even a multiple thereof IIRC), you can't
move it on a pixel basis.
That's great, '{ xi[1] = x1 + 2048 - (round down to nerest alignment
requirement); }'
Yes, the alignment is only 128 bits BTW.
The question is do we put these xi's in temporary space or not. If not do
we just express them as fullfleged cliprects? It seams to be the easy
way, but memory hungry.
I don't think those couple of bytes matter? :)
I don't see the relation from these cliprects to the viewport, exept that
there objects on the same 2d grid. I think that currently we have
cliprects crossing the line, all of them is just not getting rendered too
cause of where the viewport is.
So what I realy need to know is how do I move the viewport? I don't see
how splitting up the cliprects will do that for me.
I don't see what the viewport has to do with this either, do you mean
the 3D engine target offset? That's the RB3D_COLOROFFSET register.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Thread Local Storage libGL
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 offsets instead of a list of pointers. According to 'objdump -R' on the Mesa libGL, it cuts out about 1800 R_386_RELATIVE relocs. However, the size of the library *increases* by about 24k. That doesn't make sense to me. Here's an updated version of that patch. There are some significant differences. 1. *All* architectures use the string offset table. To do this, gl_procs.py was modified to generate a big character array called gl_string_table in glprocs.h. The static_functions array now contains offsets into that array instead of pointers to strings. If gl_procs.py is invoked with '-m short' it will generate a (hard to read) character array. If it is invoked with no option or '-m long' it will generate a big (~16k) string. The string version of the .h file generates a warning from GCC. 2. The same glprocs.h is used even for the optimized x86 case. This is done by defining NEED_FUNC_POINTERS only on non-x86. Actually, it should only be defined on architectures that don't have generated assembly dispatch stubs. 3. All of the _ts_ dispatch code is *gone*. The x86 assembly dispatch code and the C dispatch code reflect this. The SPARC assembly dispatch has not yet been updated, but it should follow the x86 model. This means that this cod will catch fire, fallover, and sink into the swamp on SPARC. This will obviously need to be fixed before that portion of the patch is committed. Unless there are objections, I would like to commit the new glprocs.h and the non-x86 specific code in glapi.c to support it. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Thread Local Storage libGL
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 revision 1.1
diff -u -d -r1.1 gl_procs.py
--- a/src/mesa/glapi/gl_procs.py18 May 2004 18:33:40 - 1.1
+++ b/src/mesa/glapi/gl_procs.py24 May 2004 23:04:12 -
@@ -36,48 +36,137 @@
class PrintGlProcs(gl_XML.FilterGLAPISpecBase):
name = gl_procs.py (from Mesa)
- def __init__(self):
+ def __init__(self, long_strings):
+ self.long_strings = long_strings
gl_XML.FilterGLAPISpecBase.__init__(self)
self.license = license.bsd_license_template % ( \
Copyright (C) 1999-2001 Brian Paul All Rights Reserved.
(C) Copyright IBM Corporation 2004, BRIAN PAUL, IBM)
+
def printRealHeader(self):
- print ''
print '/* This file is only included by glapi.c and is used for'
print ' * the GetProcAddress() function'
print ' */'
print ''
- print 'static const struct name_address_offset static_functions[] = {'
+ print 'typedef struct {'
+ print 'int Name_offset;'
+ print '#ifdef NEED_FUNCTION_POINTER'
+ print 'void * Address;'
+ print '#endif'
+ print 'unsigned int Offset;'
+ print '} glprocs_table_t;'
+ print ''
+ print '#ifdef NEED_FUNCTION_POINTER'
+ print '# define NAME_FUNC_OFFSET(n,f,o) { n , gl ## f , o }'
+ print '#else'
+ print '# define NAME_FUNC_OFFSET(n,f,o) { n , o }'
+ print '#endif'
+ print ''
return
def printRealFooter(self):
- print ' { NULL, NULL, 0 } /* end of list marker */'
- print '};'
+ print ''
+ print '#undef NAME_FUNC_OFFSET'
return
- def printFunction(self, f):
- print ' { gl%s, (GLvoid *) gl%s, _gloffset_%s },' \
- % (f.name, f.name, f.real_name)
+ def printFunctionString(self, f):
+ if self.long_strings:
+ print 'gl%s\\0' % (f.name)
+ else:
+ print 'g','l',,
+ for c in f.name:
+ print '%s', % (c),
+
+ print '\\0',
+
+ def printFunctionOffset(self, f, offset_of_name):
+ print 'NAME_FUNC_OFFSET( % 5u, %s, _gloffset_%s ),' %
(offset_of_name, f.name, f.real_name)
+
+
+ def printFunctions(self):
+ print ''
+ if self.long_strings:
+ print 'static const char gl_string_table[] ='
+ else:
+ print 'static const char gl_string_table[] = {'
+
+ keys = self.functions.keys()
+ keys.sort()
+ for k in keys:
+ if k 0: continue
+ self.printFunctionString(self.functions[k])
+
+ keys.reverse()
+ for k in keys:
+ if k = -1: continue
+ self.printFunctionString(self.functions[k])
+
+ if self.long_strings:
+ print ';'
+ else:
+ print '};'
+
+ print ''
+ print 'static const glprocs_table_t static_functions[] = {'
+
+ keys = self.functions.keys()
+ keys.sort()
+ base_offset = 0
+ for k in keys:
+ if k 0: continue
+ self.printFunctionOffset(self.functions[k], base_offset)
+
+ # The length of the function's name, plus 2 for gl,
+ # plus 1 for the NUL.
+
+ base_offset += len(self.functions[k].name) + 3
+
+ keys.reverse()
+ for k in keys:
+ if k = -1: continue
+ self.printFunctionOffset(self.functions[k], base_offset)
+
+ # The length of the function's name, plus 2 for gl,
+ # plus 1 for the NUL.
+
+ base_offset += len(self.functions[k].name) + 3
+
+ print 'NAME_FUNC_OFFSET( -1, NULL, -1 )'
+ print '};'
+ return
def show_usage():
- print Usage: %s [-f input_file_name] % sys.argv[0]
+ print Usage: %s [-f input_file_name] [-m mode] % sys.argv[0]
+ print mode can be one of:
+ print long - Create code for compilers that can handle very
+ print long
Re: drm 830 problem
Keith Whitwell wrote: Andr Ventura Lemos wrote: On Mon, 2004-05-24 at 11:15, Dave Airlie wrote: doesn't happen for me, 00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics Device (rev 02) :00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) [drm] Initialized i830 1.3.2 20021108 on minor 0: Intel Corp. 82865G Integrated Graphics Device [drm] Initialized i830 1.3.2 20021108 on minor 0 OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 865G 20040506 x86/MMX/SSE2 OpenGL version string: 1.2 Mesa 6.1 OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM 20021115 The '2002' part of the date should be a hint -- please download a recent snapshot from dri.sf.net try with that. Hmm... CVS HEAD advertises 20021108: http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/linux/i830.h?rev=1.13view=auto Look for #define DRIVER_DATE. Kristian --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
Kristian Hgsberg wrote: Keith Whitwell wrote: The '2002' part of the date should be a hint -- please download a recent snapshot from dri.sf.net try with that. Hmm... CVS HEAD advertises 20021108: http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/linux/i830.h?rev=1.13view=auto Look for #define DRIVER_DATE. Yes, the driver in the freedesktop.org tree is *ancient*. That's why he said to try an updated driver from dri.sf.net. :) --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
i830 t_vertex.c nitpick
I think I've noticed a problem in i830_tris.c, in i830RenderStart. Let's say you've got fog turned on but not specular. Then v0 has VRTX_HAS_SPEC set, and you're emitting the fog factor and a 3-byte pad. If you then turn on specular, v0 still has VRTX_HAS_SPEC set, so the test at the end won't do the _tnl_install_attrs because v0 is the same as it was before, even though the tnl code would have changed to emit the specular instead of the pad. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
Hmm... CVS HEAD advertises 20021108: http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/linux/i830.h?rev=1.13view= auto Look for #define DRIVER_DATE. Yes, the driver in the freedesktop.org tree is *ancient*. That's why he said to try an updated driver from dri.sf.net. :) not sure if Ian got confused or his trees backways :-), anyhoo, that is the DRM DRIVER_DATE, most of the 3d work is done in the mesa driver, http://dri.freedesktop.org/cgi-bin/cvsweb/mesa/Mesa/src/mesa/drivers/dri/i830/i830_context.c and that is 2004, grab a snapshot it can't harm, I'm going to install FC2 on my i865 at home rsn.. (I've burned the CDs...) Dave. David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i830 texture compression support..
I have one question though, how is RGB_DXT1 and RGBA_DXT1 going to work? As far as I can see, there's no difference at all between these two formats as far as the driver is concerned, which can't be correct (pixels which need to get decompressed as black, fully opaque for RGB_DXT1 need to be black, fully transparent for RGBA_DXT1). I'm not sure how this is supposed to work, maybe with changing texture environments? I guess RGBA_DXT1 isn't used a lot though (the compression library also does not a good job for that weird format). yup I've noticed this myself, I'm going to track it down, but it's not used much so I thought the patch might be more use with it broken than waiting for me to fix it :-) given how terribly similar they are (at least the fxt1 cc_mixed mode)... I believe though Daniel Borca is working on it (by using code from the Glide3/Texus2 library). cool that explains that ... I might dig up a pre-compressed fxt1 texture from somewhere... Dave. do I have any chance of getting ut2004 demo going on an i865 chipset? at the moment I'm missing some floors and things.. Can't help you there ;-). Roland -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
Ian Romanick [EMAIL PROTECTED] writes: Yes, the driver in the freedesktop.org tree is *ancient*. That's why he said to try an updated driver from dri.sf.net. :) i am confused. if i go to dri.sf.net, under cvs downloads it says: The DRI project has moved its CVS services to http://dri.freedesktop.org/ , to reduce the pains related to SourceForge's overloaded CVS services. To check out DRI CVS from freedesktop.org anonymously, first you must login: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri login etc. i assumed the driver at freedesktop.org is the current one. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
I haven't followed DRI closely, so this may be a FAQ or just a stupid question, but why is the DRI module in the 2.6.6 kernel almost two years old? there are 3 components to a 3d driver, DRM, DRI and DDX :-), DRM - lives in kernel - the i830 DRM hasn't needed any major changes in the two years. DRI driver - lives in Mesa tree and /usr/X11R6/lib/modules/dri/i830_dri.so, this is now at 2004, the version in X.org tree is older, probably same as in XFree86, DDX driver - lives in DRI and X.org trees, this is the 2d driver mainly but calls the 3d driver initialisation, So you have a new DRM, but an older DRI. to update your DRI use a snapshot .. Dave. Kristian -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Memory management of AGP and VRAM
These seem to be good requierments of any conclusion that is reached. 1. On the fly context switching. 1a. Even if the GART is %100 full for the new/old context. 1b. Even if the VideoRam is %100 full for the new/old context. 1c. Even if the Card(s) are locked for exlusive use. 1d. Even if add you fav gripe here. 1e. Even if hell has frozen over and a nutron boom has damaged your video card. --- Holger Waechtler [EMAIL PROTECTED] wrote: Mike Mestnik wrote: --- Jon Smirl [EMAIL PROTECTED] wrote: There are two types of VTs - text and graphical. It is only practical to have a single graphical VT because of the complexity of state swapping a graphical VT at VT swap. Right now we can all-ready run X on multiple VTs and with DRI-reinit can run GL apps on all of them. It may noy be the most elegant thing but it workes. We need the OS to keep state, even graphical, GART and all. I don't see how a 128M GART is diffrent then 2Gb system memory. Should we have GART swap space on the HD, a GART partition? I'm for making the OS VT swap multiheaded DR?I? setups at whatever cost. An elegant implementation would not swap the entire GART at VT switches but only present the new VT framebuffer as new display on the screen while maintaining the AGP states. Check out e.g. MacOS-X's animated multiple login screen: At every new session start the current session just rotates smoothly animated into the background and a new one is brought up. In this model you can retain the entire graphics state at VT switch, only another (currently invisible) frambuffer/screen/display/VT is made visible. This allows straightforward multihead implementations, any frambuffer/screen/display/VT can get attached to any head, they are just a piece of framebuffer memory which is either located in graphics memory or system memory and can get relocated on request, even to other graphics cards. How about this for a new way to look at the problem? System based xterm, that's a new one. I don't see how it's better then what we have now. probably not -- the MacOS-X alike approach looks more promising. At SAK a new display framebuffer would get launched and brought to front, the currently running application is only need get killed if it locks the graphics engine in an locked state. Unfortunally that means that parts of the window stack implementation need to run in kernel space (or a tightly connected trusted agent in userspace). Don't know whether this is a problem, the DirectFB core showed that it's possible to implement this cleanly in a few thousand lines of code. Holger --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Thread Local Storage libGL
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 code I needed to replace it with. --- Keith Whitwell [EMAIL PROTECTED] 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 assembly, not the C version. I wasn't really clear about that before. My proposal is to modify the C version, the x86 assembly version, and the SPARC assembly version. I've worked up a patch to gl_x86_asm.py that I can post on Monday. Just to get every one on the same page. The SPARC assembly version is only for solaris. It dose not, and can not, even build on linux! Last time I checked DRI would not build on SPARC/Linux, crashing on the Solaris ASM code. Hmm, there are definite references to __linux__ in the code - looks like the intention is there. Why not look at the generator scripts post a patch to fix it? Keith __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Thread Local Storage libGL
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. glibc is built for both 64bit and 32bit binarys. Normally the differance is... sparc32 make all; # vs just running make all and this is needed for many programs that don't take into account 64bit systems. --- Ian Romanick [EMAIL PROTECTED] 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 assembly, not the C version. I wasn't really clear about that before. My proposal is to modify the C version, the x86 assembly version, and the SPARC assembly version. I've worked up a patch to gl_x86_asm.py that I can post on Monday. Just to get every one on the same page. The SPARC assembly version is only for solaris. It dose not, and can not, even build on linux! Last time I checked DRI would not build on SPARC/Linux, crashing on the Solaris ASM code. Does the code in src/mesa/glapi/glapi.c (generate_entrypoint specifically) cause the crash or just the code in src/mesa/sparc/glapi_sparc.S? My guess is that Linux uses 32-bit user-mode, but the asm code in glapi_sparc.S defaults to 64-bit on v9. Perhaps we could come up with a better define, such as USE_SPARC_32BIT_USER to determine which stubs to build. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Thread Local Storage libGL
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 coulden't find what C code I needed to replace it with. The C dispatch stubs are in the header file src/mesa/glapi/glapitemps.h. They are built in src/mesa/main/dispatch.c. --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 830 problem
Dave Airlie wrote: Hmm... CVS HEAD advertises 20021108: http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/linux/i830.h?rev=1.13view= auto Look for #define DRIVER_DATE. Yes, the driver in the freedesktop.org tree is *ancient*. That's why he said to try an updated driver from dri.sf.net. :) not sure if Ian got confused or his trees backways :-), Oops. My bad. I saw http://freedesktop.org/; and jumped to conclusions. Sorry. anyhoo, that is the DRM DRIVER_DATE, most of the 3d work is done in the mesa driver, http://dri.freedesktop.org/cgi-bin/cvsweb/mesa/Mesa/src/mesa/drivers/dri/i830/i830_context.c --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
