AW: [Dri-devel] XFree-4.1.0 and Rage128Pro: glxgears quit with drmR128SwapBuffers = -14
the subject says it: glxgears (and all other OpenGL-based programs) abort with the message: drmR128SwapBuffers = -14 My configuration: Kernel 2.4.6 XFree86 4.1.0 ATI AIW 128 Pro newly compiled drm kernel modules, r128 XFree86 driver, r128_dri.so, etc. Do you have the DRM from kernel 2.4.9 or later or built from XFree86 4.1.0 source? I tried several ways: from my current kernel 2.4.6 = always yellow window. From sources from the Livid/GatosATI website = drmR128SwapBuffers = -14. From XFree86-4.1.0 source = I'm not really shure that I tried this ... Does an upgrade to kernel 2.4.10 with subsequent building of r128.o from the new kernel sources fix the problem ? Thanks, Matthias Huber ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] twm, 3D and Radeon
* accelerated 3d: glxgears are funny - they do not rotate, but toggle from one position to another My thought on this is that the gears are moving so fast that the only frames that you actually get to see are of two alternating positions. The glxgears program moves the gears a set amount per frame rather then a set amount per time so when you are getting results in the thousands for fps there are a lot of frames that you never see because of the refresh rate of your monitor. I looks the same on my radeon but when I slow down the rotation in the source it looks nice and smooth. * when I move glxgears around the screen I get corruption from window borders (this does not happen if I move plain 2d windows. I know nothing about this. I'll have to try it when I reboot in Linux. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] NVidia Driver Source
Dear DRI developers, I read in the FAQ, that NVidia provide their own binary closed source drivers. Yet visiting the Nvidia homepage driver section I find, that there are not only binary drivers for several distributions, but also a source rpm and a source tarball for those interested. Actually I used this source and the explicit and very details compilation and troubleshooting information there to install the driver on my system. It compiled and works well. Have I misunderstood the concept of closed source or is this perhaps valuable and sufficient information for the DRI project? Has there been a change in the attitude of NVidia? Perhaps someone could change those lines in the FAQ, for NVidia has in my opinion done great work. Thanks a lot if anyone has the time to answer this mail. Johannes Prix, Graz. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NVidia Driver Source
* Johannes Prix ([EMAIL PROTECTED]) wrote: Dear DRI developers, I read in the FAQ, that NVidia provide their own binary closed source drivers. Yet visiting the Nvidia homepage driver section I find, that there are not only binary drivers for several distributions, but also a source rpm and a source tarball for those interested. Actually I used this source and the explicit and very details compilation and troubleshooting information there to install the driver on my system. It compiled and works well. Have I misunderstood the concept of closed source or is this perhaps valuable and sufficient information for the DRI project? My understanding having looked at this 'source' package is that it is not really source. If you look carefully you will see that there is a file in there which is not source but a precompiler binary object together with some source. From what I can tell the source providers a wrapper around the precompiled binary; with the aim that the source can fit the binary to whichever version of the Linux kernel you are using. I may be wrong, but that is what I could find. Dave Have a happy GNU millennium! -- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NVidia Driver Source
On Fri, Oct 05, 2001 at 05:36:49PM +0200, Johannes Prix wrote: I read in the FAQ, that NVidia provide their own binary closed source drivers. Yet visiting the Nvidia homepage driver section I find, that there are not only binary drivers for several distributions, but also a source rpm and a source tarball for those interested. Actually I used this source and the explicit and very details compilation and troubleshooting information there to install the driver on my system. It compiled and works well. Have I misunderstood the concept of closed source or is this perhaps valuable and sufficient information for the DRI project? Has there been a change in the attitude of NVidia? Perhaps someone could change those lines in the FAQ, for NVidia has in my opinion done great work. Thanks a lot if anyone has the time to answer this mail. If you look carefully at the source, you'll find it is just a small wrapper for the actual code. All the actual code that operates the card is in binaries. This makes it easier for them to install their driver on different versions of the Linux kernel, but it really is closed source and doesn't provide any useful information to someone who wants to write drivers for the card. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NVidia Driver Source
The NV source is their kernel driver. This basic function of this routine is to manage DMA transfers of buffers full of graphics commands to the board. This is a very small piece of code that exposes almost nothing of the architecture of the graphics engine. The code that actually builds the buffers full of graphics commands is binary only (and resides in the NVIDIA_GLX stuff). So from any reasonable perspective NV is closed source. Nevertheless, I concur with you that what they provide works well. I have r128, g400, and gf2's in my lab.. and a gf2 on my desk. Mike Johannes Prix wrote: Dear DRI developers, I read in the FAQ, that NVidia provide their own binary closed source drivers. Yet visiting the Nvidia homepage driver section I find, that there are not only binary drivers for several distributions, but also a source rpm and a source tarball for those interested. Actually I used this source and the explicit and very details compilation and troubleshooting information there to install the driver on my system. It compiled and works well. Have I misunderstood the concept of closed source or is this perhaps valuable and sufficient information for the DRI project? Has there been a change in the attitude of NVidia? Perhaps someone could change those lines in the FAQ, for NVidia has in my opinion done great work. Thanks a lot if anyone has the time to answer this mail. Johannes Prix, Graz. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] NVidia Driver Source
The only source files that nVidia provides are very limited files for compiling the necessary kernel driver (which, from what I understand, contains very little info regarding nVidia's hardware). The source rpm they have for NVIDIA_GLX is nothing more than the compiled libraries and X extensions. Adam On Fri, 5 Oct 2001, Johannes Prix wrote: Dear DRI developers, I read in the FAQ, that NVidia provide their own binary closed source drivers. Yet visiting the Nvidia homepage driver section I find, that there are not only binary drivers for several distributions, but also a source rpm and a source tarball for those interested. Actually I used this source and the explicit and very details compilation and troubleshooting information there to install the driver on my system. It compiled and works well. Have I misunderstood the concept of closed source or is this perhaps valuable and sufficient information for the DRI project? Has there been a change in the attitude of NVidia? Perhaps someone could change those lines in the FAQ, for NVidia has in my opinion done great work. Thanks a lot if anyone has the time to answer this mail. Johannes Prix, Graz. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: linux drivers for mach64
On Friday 05 October 2001 10:46, you wrote: i noticed your name on dri.sourceforge.net and was wondering if mach64 support was still being worked on or if the developers aren't going to continue with the project. there are many questions about it in http://dri.sourceforge.net/faq/faq_display.phtml?id=12 and no answers from an official type person so i was hoping to ask you directly. Yes, it's still being worked on. It's just stalled because of issues with things. The work's been stalled because of people being busy with personal issues, etc. However, having said this, I plan on starting back into the work sometime this weekend and give it another go. We're suffering from some things the new ATI driver for XFree86 is inflicting on us amongst other things. A new RagePRO portion may need to be coded to get around the problem (and that is what I plan on starting this weekend...). -- Frank Earl ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glDrawPixels on i810
I'd be happy to get to work making grabbing facilities, etc (for mga, which seems to be the most stable accellerator) but for lack of experience and not much of a place to start.. On the other hand, I'm getting paid to do it (part of my job), so chances are I'll complete it. Any pointers would speed things up. The application (for the company) is: Real time video into (main memory) RGBA surface from SDI based video card Blit from that surface to FB in accellerator. Render with dest alpha in the accellerator. blit from the FB surface to the SDI based video card for SDI output. In other words the lacking pieces match up nicely with integrating XVideo and the DRI to some extent. Any pointers would help. We really want to move away from O2s and NT boxs. Blech they leave a bad taste in my mouth. -Roberto JP [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glDrawPixels on i810
Maybe I'm just paranoid, but why so much on the i810? This chipset is slower than Mach64, and people never got it in the intention of doing games, or other intense graphics. Roberto Peon wrote: I'd be happy to get to work making grabbing facilities, etc (for mga, which seems to be the most stable accellerator) but for lack of experience and not much of a place to start.. On the other hand, I'm getting paid to do it (part of my job), so chances are I'll complete it. Any pointers would speed things up. The application (for the company) is: Real time video into (main memory) RGBA surface from SDI based video card Blit from that surface to FB in accellerator. Render with dest alpha in the accellerator. blit from the FB surface to the SDI based video card for SDI output. In other words the lacking pieces match up nicely with integrating XVideo and the DRI to some extent. Any pointers would help. We really want to move away from O2s and NT boxs. Blech they leave a bad taste in my mouth. -Roberto JP [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glDrawPixels on i810
In our case, it isn't necessarily on the i810. We don't really care what accellerator is used as long as it works well for textures and stenciling. Depth buffering is a bonus, but not necessary for the majority of things that we do. Dest alpha, on the other hand IS. Right now we're evaluating using the MGA- it is slower than NVidia's solutions, however we can modify the source. We don't even care if the graphics are displayed on the computer's screen. What counts for us is live, real-time, reliable video overlay. We have a hard-realtime constraint in our rendering times- We must render (input and output) 30 FPS or the fans at home (not to mention the broadcasters themselves) notice/get annoyed. Can you imagine what the fans would think if they had to deal with frame-drop on TV? (!?!) -Roberto JP [EMAIL PROTECTED] -- Original Message -- From: Carl Busjahn [EMAIL PROTECTED] Date: Fri, 05 Oct 2001 14:39:32 -0400 Maybe I'm just paranoid, but why so much on the i810? This chipset is slower than Mach64, and people never got it in the intention of doing games, or other intense graphics. Roberto Peon wrote: I'd be happy to get to work making grabbing facilities, etc (for mga, which seems to be the most stable accellerator) but for lack of experience and not much of a place to start.. On the other hand, I'm getting paid to do it (part of my job), so chances are I'll complete it. Any pointers would speed things up. The application (for the company) is: Real time video into (main memory) RGBA surface from SDI based video card Blit from that surface to FB in accellerator. Render with dest alpha in the accellerator. blit from the FB surface to the SDI based video card for SDI output. In other words the lacking pieces match up nicely with integrating XVideo and the DRI to some extent. Any pointers would help. We really want to move away from O2s and NT boxs. Blech they leave a bad taste in my mouth. -Roberto JP [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] oops with r128 on Dell Inspiron 4000
Hi, I have a Dell Inspiron 4000 with an ATI Rage Mobility M3 on which DRI doesn't work. The r128 module loads fine, when I try to read from /proc/dri/0/vm, cat segfaults and I get this oops: ksymoops 2.4.3 on i686 2.4.9-ac18. Options used -V (default) -k /proc/ksyms (specified) -l /proc/modules (default) -o /lib/modules/2.4.9-ac18/ (default) -m /boot/System.map-2.4.9-ac18 (default) Unable to handle kernel NULL pointer dereference at virtual address d098ca97 *pde = Oops: CPU:0 EIP:0010:[d098ca97]Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210287 eax: ebx: 0032 ecx: c17c2000 edx: cece4000 esi: c39cdf98 edi: c17c2000 ebp: c17c2000 esp: c39cdee4 ds: 0018 es: 0018 ss: 0018 Process cat (pid: 2842, stackpage=c39cd000) Stack: cece4000 c39cdf98 c17c2000 cece4020 c37ac184 cf60c9e0 cece4000 d09967d4 d09967d7 d09967db d09967df 08061d54 0001 c39cc000 d098cbeb c17c2000 c39cdf98 0c00 c39cdf94 cece4000 00200282 c01f8bb8 Call Trace: [d09967d4] [d09967d7] [d09967db] [d09967df] [d098cbeb] Code: 8b 38 8b 07 0f 18 00 8b 44 24 1c 8b 90 4c 01 00 00 39 d7 0f EIP; d098ca96 [r128]r128__vm_info+9a/1b4 = Trace; d09967d4 [r128].rodata.start+2374/4a3e Trace; d09967d6 [r128].rodata.start+2376/4a3e Trace; d09967da [r128].rodata.start+237a/4a3e Trace; d09967de [r128].rodata.start+237e/4a3e Trace; d098cbea [r128]r128_vm_info+3a/54 Code; d098ca96 [r128]r128__vm_info+9a/1b4 _EIP: Code; d098ca96 [r128]r128__vm_info+9a/1b4 = 0: 8b 38 mov(%eax),%edi = Code; d098ca98 [r128]r128__vm_info+9c/1b4 2: 8b 07 mov(%edi),%eax Code; d098ca9a [r128]r128__vm_info+9e/1b4 4: 0f 18 00 prefetchnta (%eax) Code; d098ca9c [r128]r128__vm_info+a0/1b4 7: 8b 44 24 1c mov0x1c(%esp,1),%eax Code; d098caa0 [r128]r128__vm_info+a4/1b4 b: 8b 90 4c 01 00 00 mov0x14c(%eax),%edx Code; d098caa6 [r128]r128__vm_info+aa/1b4 11: 39 d7 cmp%edx,%edi Code; d098caa8 [r128]r128__vm_info+ac/1b4 13: 0f 00 00 sldt (%eax) The Tainted: P is caused by the ALSA drivers not having any license tags. kernel: Linux galadriel 2.4.9-ac18 #2 ons okt 3 02:14:02 CEST 2001 i686 unknown DRI driver chekced out of CVS on October 2, dmesg output: [drm] AGP 0.99 on Intel 440BX @ 0xf000 64MB [drm] Initialized r128 2.1.6 20010405 on minor 0 lspci -vvv output: 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility M3 AGP 2x (rev 02) (prog-if 00 [VGA]) Subsystem: Dell Computer Corporation: Unknown device 00b0 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at f400 (32-bit, prefetchable) [size=64M] Region 1: I/O ports at ec00 [size=256] Region 2: Memory at fdffc000 (32-bit, non-prefetchable) [size=16K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [50] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=0 SBA+ AGP- 64bit- FW- Rate=none Capabilities: [5c] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- If you need any more info, I'll be happy to provide it. -- Dagfinn I. Mannsåker GPG Public Key ID: 0x51ECFAC6 Fingerprint: 48BB A64D CE9B 9A06 65DF 395C D42E CDC4 51EC FAC6 PGP signature
Re: [Dri-devel] oops with r128 on Dell Inspiron 4000
On Sat, Oct 06, 2001 at 02:46:44AM +0200, Dagfinn Ilmari Mannsåker wrote: Hi, I have a Dell Inspiron 4000 with an ATI Rage Mobility M3 on which DRI doesn't work. The r128 module loads fine, when I try to read from /proc/dri/0/vm, cat segfaults and I get this oops: With 2.4.10-ac7 it no longer oopses, but X still says Direct rendering disabled when starting, and /proc/dri/0/vm is empty except for the headers. The same goes if I use the r128 module checked out from CVS today. -- Dagfinn I. Mannsåker GPG Public Key ID: 0x51ECFAC6 Fingerprint: 48BB A64D CE9B 9A06 65DF 395C D42E CDC4 51EC FAC6 msg01824/pgp0.pgp Description: PGP signature
[Dri-devel] twm, 3D and Radeon
Before I try delving deeper into this, maybe someone can tell me what is going on. * Radeon: 1002:5144 * 2d is working fine * software GL is working fine * accelerated 3d: glxgears are funny - they do not rotate, but toggle from one position to another * when I move glxgears around the screen I get corruption from window borders (this does not happen if I move plain 2d windows. Thoughts ? I am using XFree86 CVS as of yesterday (October 4th). thanks Vladimir Dergachev ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
