[Dri-devel] Mach64 with AGP: still some restrictions on resolution/depth?
Hi all I just tried to run my X in 1280x1024/24bpp (before it was 16bpp) and lost DRM! I got it back only in 800x600/24. Now when we have AGP textures working - what are the restrictions on resolutions/color depth? Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] MP3 SITESI BUTUN MP3LER BURADA BI BAK
!!!ÞOK NAPSTER ARTIK TÜRKÇE!!!
EWET ARTIK MÝLYONLARCA MP3 E ÝSTEDÝÐÝNÝZ
ZAMAN ULAÞABÝLECEKSÝNÝZ
HEMDE ÇOK KOLAY
MUHTEÞEM BÝR PROGRAM TIKLAYACAKSINIZ ÝNDÝRECEKSÝNÝZ
KURMA YOK HEMEN ÝNDÝR HEMEN BAÐLAN
MÝLYONLARCA MP3 E KAVUÞ
BÝR TÜRK MUCÝZESÝ PROGRAM
ÝNDÝRMEK ÝÇÝN TIKLAYINIZ
-
©¢{(ç[É8bAzFÛiÿü0Á8bAzG(ðëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
Re: [Dri-devel] Re: mach64-0-0-4 compiling problems
Also you might want to know that I had problems getting the wrong kernel headers under woody. It seams that 'as explained in the docs for kernel-header-*' the debian headers may not be the same as the kernel headers. If you compile a kernel module ought side the kernel tree it's doomed to get the wrong headers. In my experience X would fail complaining that it couldn't setdrmuniq. I could be wrong though, let me know how things work for you. --- Michael Thaler [EMAIL PROTECTED] wrote: Hello, I just tried to compile the newest mach64-0-0-4 branch to do some tests and got the following error: make[10]: Entering directory `/usr/local/src/DRI-CVS/build/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel' === KERNEL HEADERS IN /lib/modules/2.4.18/build/include === SMP=0 MODULES=0 MODVERSIONS=0 AGP=0 === Compiling for machine i686 === WARNING === WARNING Use 2.4.x kernels ONLY ! === WARNING *** Kernel modules must be configured. Build aborted. O.K., I found the error. I am using Debian Sid and I forgot that I installed a new Kernel Tree sometimes, but did not configure and compile it. So the running kernel was o.k., but the Tree wasn't. I will compile the branch this afternoon and I hope I can post some results of my tests with the Mach64 DMA driver soon. Another question. I am using the Gatos driver for hardware accelerated DVD watching. Can I use them together with the DRI Mach64 drivers? Greetings, Michael --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com debian.README.gz Description: debian.README.gz
Re: [Dri-devel] Re: mach64-0-0-4 compiling problems
Another question. I am using the Gatos driver for hardware accelerated DVD watching. Can I use them together with the DRI Mach64 drivers? I doubt that mixing these drivers will work, because gatos uses its own drm-module (correct me if I'm wrong). You'd probably have to merge both codebases, which is not trivial. You could try a different approach to your problem: Have you tried mplayer's xvidix video out driver? It should work fine with a mach64 card, and be at least as fast as xv, if not faster (i don't know the exact numbers) Greetings, Michael --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] How to trace switching to software rendering
Hi, I'm trying to use a program called gtkradiant (http://zerowing.idsoftware.com/) that is a map editor for quake and all the other games from ID Software. My problem now is that the 3D view is very slow for me. After testing it with different graphic cards it looks like that it works slow with Matrox G400 and 3Dfx voodoo but fast with NVidia (and with LIBGL_ALWAYS_INDIRECT=1 faster than without). Since all the other openGL programms are working fast I think it is an issure with gtkradiant. After searching for a solution I found the XFree86 page about DRI (http://www.xfree86.org/4.2.0/DRI10.htm) saying that under certain conditions the dri driver will switch into software rendering. My question now is how can I detect that switch and find the gl call that cause it? Is there a point where I can set a breakpoint or something else? Bye, Michael --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4 compiling problems
On Fri, 21 Jun 2002, Stefan Lange wrote: Another question. I am using the Gatos driver for hardware accelerated DVD watching. Can I use them together with the DRI Mach64 drivers? I doubt that mixing these drivers will work, because gatos uses its own drm-module (correct me if I'm wrong). You'd probably have to merge both codebases, which is not trivial. The gatos driver replaces the DDX driver modules with it's own, and the gatos DDX driver is based on XFree86 CVS, so it doesn't have DRI support for mach64 yet. Because of this, there's no drm module for the mach64 gatos driver and the two drivers are mutually exclusive. Marc LaFrance is working on merging the gatos XVideo support into the mach64 DDX driver in XFree86 CVS, but I don't know how long it will be before that's ready for release. Since both DRI and gatos are essentially branches of the XFree86 codebase, one of these projects will need to get merged into mainline XFree86 before a merge between DRI and gatos can happen. Once that happens, I don't think a merge will really be that difficult, since the gatos changes are mostly self-contained in source files that the DRI part of the DDX driver doesn't touch. The important thing will be to make sure the registers shared by the scaler and 3D pipeline are left in a consistent state on 3D/2D context switches. You could try a different approach to your problem: Have you tried mplayer's xvidix video out driver? It should work fine with a mach64 card, and be at least as fast as xv, if not faster (i don't know the exact numbers) I just tried the mach64 vidix driver with the latest xine release and it works for me with the mach64 DRI branch (though the vidix driver is new and still a little buggy). I haven't tried it with mplayer. Unfortunately, you need root privileges to use it, but this seems like a possible workaround to get 3D and fast video playback with a single Xserver until a merge happens. -- Leif Delgass http://www.retinalburn.net --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] merge with Gatos
Hi all I recently asked the question about merging Mach64 DRI with Gatos project - and got no answer. So, now I am trying to use xine - and found that mach64 dri snapshots do not properly support XVideo extension (at least in YUV overlay area). So could please anyone tell me what are perspectives of this merge? I realize it is the lowest priority issue but I hope it is not that difficult - now when 2D acceleration is already somehow enabled in DRI driver... Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] How to trace switching to software rendering
Michael Schlueter wrote: Hi, I'm trying to use a program called gtkradiant (http://zerowing.idsoftware.com/) that is a map editor for quake and all the other games from ID Software. My problem now is that the 3D view is very slow for me. After testing it with different graphic cards it looks like that it works slow with Matrox G400 and 3Dfx voodoo but fast with NVidia (and with LIBGL_ALWAYS_INDIRECT=1 faster than without). Since all the other openGL programms are working fast I think it is an issure with gtkradiant. After searching for a solution I found the XFree86 page about DRI (http://www.xfree86.org/4.2.0/DRI10.htm) saying that under certain conditions the dri driver will switch into software rendering. My question now is how can I detect that switch and find the gl call that cause it? Is there a point where I can set a breakpoint or something else? Most of the DRI drivers have a per-context field called 'Fallback'. It's a bitmask which records various reasons why we need to fallback to software rendering. In the case of the mga (G400) driver you'll see these flags in mgacontext.h: #define MGA_FALLBACK_TEXTURE0x1 #define MGA_FALLBACK_DRAW_BUFFER0x2 #define MGA_FALLBACK_READ_BUFFER0x4 #define MGA_FALLBACK_LOGICOP0x8 #define MGA_FALLBACK_RENDERMODE 0x10 #define MGA_FALLBACK_STENCIL0x20 #define MGA_FALLBACK_DEPTH 0x40 If you search the code, you'll find where we set these flags by calling mgaFallback() (via the FALLBACK() macro). You could put a printf in there to print the bit value and get an idea of what's slowing you down. -Brian --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] TCL lockups with Tribes 2
Hi all. I've been testing the latest TCL drivers recently merged into the main cvs trunk thing (sorry I don't quite understand cvs) with various 3D apps, and I'm getting lockups with Tribes 2, after about 5 seconds of 3D rendering (not enough to actually play anything). The lockups seem to be dependant on the time since rendering started more than anything else. I have tried various levels and with sound on / off. 3D screensavers Quake3 work fine, but I can't get any action from Tribes2. I have to ALT-SysRq (SUB) to sync, unmount and reboot each time. I am using a 1600XP Athlon with 256MB DDR Ram, on an Epox (8KHA+ or something like that) motherboard, with a Via KT266A DDR chipset and a 64MB DDR Vivo Radeon (and an SB Live 5.1). I have successfully run the Mesa4 branch with Tribes 2 without lockups, but have had the same problem with every TCL checkout I've tried (sorry I didn't report this earlier - I didn't think the TCL stuff was stable / complete enough to bother complaining about something like Tribes 2). I don't currently have another linux box here which I can use to log into this one and get any info (it that is at all possible) after a crash, but it someone thinks it will be handy, I'll get my friend's PC around here (I will need instructions). Some system info: glxinfo: name of display: :0.0 radeonUpdatePageFlipping allow 0 current 0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20020611 AGP 4x x86/MMX/3DNow! TCL OpenGL version string: 1.2 Mesa 4.0.3 OpenGL extensions: GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add, GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_IBM_rasterpos_clip, GL_MESA_window_pos, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x27 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x28 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x29 24 dc 0 24 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2a 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: VIA Technologies, Inc. VT8367 [KT266] (rev 0). Master Capable. Latency=8. Prefetchable 32 bit memory at 0xe800 [0xebff]. Bus 0, device 1, function 0: PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP] (rev 0). Master Capable. No bursts. Min Gnt=12. Bus 0, device 9, function 0: Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 8). IRQ 11. Master Capable. Latency=32. Min Gnt=2.Max Lat=20. I/O at 0xd000 [0xd01f]. Bus 0, device 9, function 1: Input device controller: Creative Labs SB Live! (rev 8). Master Capable. Latency=32. I/O at 0xd400 [0xd407]. Bus 0, device 11, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) (rev 0). IRQ 11. I/O at 0xd800 [0xd81f]. Bus 0, device 12, function 0: Multimedia video controller: Brooktree Corporation Bt878 (rev 2). IRQ 11. Master Capable. Latency=32. Min Gnt=16.Max Lat=40. Prefetchable 32 bit memory at 0xee00 [0xee000fff]. Bus 0, device 12, function 1: Multimedia controller: Brooktree Corporation Bt878 (rev 2). IRQ 11. Master Capable. Latency=32. Min Gnt=4.Max
