[Dri-devel] Mach64-0-0-4-branch currently unusable
Hi, I cvs updated mach64-0-0-4-branch last night and recompiled (previous update was on sunday). Right after starting glxgears the screen switched off (like with xset dpms force off) and the machine hung. The sysrq keys didn't work. Maybe Peter Anderson's problems are not PowerPC specific? Peter, which branch are you trying? Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64: How much video memory is needed?
I'm now trying mach64-0-0-4-branch with Rage Mobility-M PCI (LR). The compiled X server does not work in a setting more than 800x600 16bpp. How much video memory is needed to use Mach64 DRI in general? I bet you have 8M video RAM! So do I. Today, Mach64 DRI driver does not use GART so it cannot use system memory and we are restricted by the amount of video memory. The team first is going to enable DMA, then - GART (at least I was told so some time ago). So just wait and see... Waiting for 0-0-4 binary snapshots, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
On Fri, 2002-04-26 at 00:41, Peter Andersson wrote: Vector 800 at pc - d58fb02c , lr -d58fb64 mxr - 9032, xp -4200 current - c99fc000, pid - 1077, comm -glxgears mon When i type ? the following menu rolls up: d dump bytes didump instructions dfdump float values dddump double values eprint exception information hdump hash table mmmove a block of memory ms set a block of memory mdcompare two blocks of memory Mprint system.map rprint registers Sprint special registers tprint backtrace lalookup adress in system.map lslookup symbol in system.map xexit monitor This is the xmon (simple kernel debugger) prompt. If the atimisc driver had Option UseFBDev and you used it, the display would be correct... I tried the backtrace option but it only produced a bunch of numbers and letters, and since i am not exactly sure if i am able to read them right i don´t think they are useful for anyone, but if you want me to give it a try please let me know. If you provide the System.map corresponding to the kernel to yaboot, xmon will show symbol names. This is my default yaboot label: image=/vmlinux label=Debian sysmap=/System.map -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64-0-0-4-branch currently unusable
I can't remember, is your card PCI or AGP? Do you see a kernel oops in the system log? On Fri, 26 Apr 2002, Felix Kühling wrote: Hi, I cvs updated mach64-0-0-4-branch last night and recompiled (previous update was on sunday). Right after starting glxgears the screen switched off (like with xset dpms force off) and the machine hung. The sysrq keys didn't work. Maybe Peter Anderson's problems are not PowerPC specific? Peter, which branch are you trying? Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64: How much video memory is needed?
On Fri, 26 Apr 2002, Kaz Sasayama wrote: I'm now trying mach64-0-0-4-branch with Rage Mobility-M PCI (LR). The compiled X server does not work in a setting more than 800x600 16bpp. How much video memory is needed to use Mach64 DRI in general? I have an 8MB card, and I run the X server at 1024x768 @ 16-bit depth or 800x600 @ 24-bit depth. You need enough memory for 3 times the virtual screen size at the given depth (front, back, and depth buffers), plus textures and pixmap cache. The depth buffer is always 16-bit, so at 24-bit depth (32bpp framebuffer) it's smaller than the front and back buffers, but the current branch allocates enough for a 32bpp depth buffer. I have code to fix that, but I need to clean it up before checking it in. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Linux DRM update to 2.4.18 first draft.
--- Thomas Winischhofer [EMAIL PROTECTED] wrote:
Jens Owen wrote:
Mike Mestnik wrote:
sis renamed to i830 (or one was removed and the other added),
I recommend leaving the SiS support in the kernel, for now. Also, the
sis_ds.c patch appears to be reversed.
What did that patch do? (In short words)
The driver was removed. (but not the files)
CONFIG_DRM_SIS was removed from Config.in. sis-objs, obj-$(CONFIG_DRM_SIS),
and {sis.o: ...} were removed from the make file. In drm.h the sys #include
sis.h and #defines where un ifdefed
in sys_ds.c...
-#include linux/malloc.h
+#include linux/slab.h
I'm composing a more elaborate E-Mail.
Thomas
--
Thomas Winischhofer
Vienna/Austria
mailto:[EMAIL PROTECTED] *** http://www.winischhofer.net
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
__
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Patches to kernel-drm
It lookes like there is some one making changes that I think we should be aware of. This could be something done by the back-port project. In any case it looks like this should be put into the CVS, if not all ready there. I'm going to start pruning my patch of things that get removed, and keeping a log so we can propagate it (to CVS ect.). If some one dose submit a patch to the Kernel that effects us, do we get a copy? Like it would be a good idea for drm_agpsupport.h to work on pre24 but my patch removes this support. I didn't realy do this on purpose it's just what diff gave me when I ran it agensed linux-2.4.18 and linux-drm-4.2.0-kernelsource.tar.gz (from alen). __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Patches to kernel-drm
Mike Mestnik wrote: It lookes like there is some one making changes that I think we should be aware of. This could be something done by the back-port project. In any case it looks like this should be put into the CVS, if not all ready there. I'm going to start pruning my patch of things that get removed, and keeping a log so we can propagate it (to CVS ect.). If some one dose submit a patch to the Kernel that effects us, do we get a copy? No chance, unfortunately. Like it would be a good idea for drm_agpsupport.h to work on pre24 but my patch removes this support. I didn't realy do this on purpose it's just what diff gave me when I ran it agensed linux-2.4.18 and linux-drm-4.2.0-kernelsource.tar.gz (from alen). I don't think we need to support development kernels from previous development cycles -- they are dead and buried. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glXGetProcAddress question
On Tue, Apr 23, 2002 at 12:49:20AM +0100, Keith Whitwell wrote: Ian Romanick wrote: On Tue, Apr 23, 2002 at 12:31:46AM +0100, Keith Whitwell wrote: Ian Romanick wrote: What ends up happening is glXGetProcAddress returns the address of the glBegin symbol from my executable (in this case the address of the pointer to function) instead of the address of the glBegin symbol in the library. Is this behavior to spec? Probably the fact that you are declaring a symbol that is reserved by OpenGL invalidates your right to have GL act according to spec. You might get a link error if you tried to link this program against libGL.so, for instance. So, to put it another way, glXGetProcAddress is working fine, but I'm trying to do something that you're not supposed to do. :) Well, you're doing something you're not supposed to do as a result glXGetProcAddress isn't working right. Do you really need to call your symbol glBegin? How about xyzBegin or similar? The most common thing I've seen is to call the indirect function: glBeginProc - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon Card Features DRI Checklist.
On Fri, Apr 26, 2002 at 03:09:46AM +0200, Smitty wrote:
I'm not the most qualified to answer this, but I think most of the more
qualified people are pretty busy adding some of these features. :)
ATI R100 (Radeon)
=
Anti-aliasing
=
Full Screen No
Line Edge Either SW or No
Double Buffering --- Yes
Filtering
=
Anisotrophic texture --- Yes
Bilinear --- Yes
Trilinear -- Yes
KTX buffer region extension No
Key Frame Interpolation No
Gamma Control -- No
Guard Band Clipping No
Mapping
===
Bump --- No. Will be possible once (if) the
extension is added to Mesa. By this I am
assuming you mean environment bumpmapping.
Cubic Envionment --- SW, but currently disable by the HW driver.
Dot Product 3 -- Yes.
Dual-Parabloid - Unsure.
Emboss - What exactly do you mean? If you are
refering to Nvidia's NV_texgen_emboss
extension, then it will likely never be
supported due to Nvidia's IP.
Mip Yes
Perspectively Correct Texture -- Yes.
Page Flipping -- Yes, but I'm not 100% sure.
Single-Pass Multi-Texture -- Yes
System Memory Blits What exactly do you mean?
Superscalar Rendering -- What exactly do you mean?
Specular Highlights Yes
Table Fog -- Unsure
TCL Back Face Culling -- Not currently, but soon.
TCL Hardware --- Not currently, but soon.
Twin Cache Architecture What exactly do you mean?
Texture Units per pipeline (3) - 2 currently, soon to be 3.
Triangle Setup Engine -- Yes
True Colour Rendering -- Yes
Texture
===
Cache -- What exactly do you mean?
Compositing What exactly do you mean?
(De)Compression No
Vertical Sync -- Yes, but I'm not 100% sure.
Vertex Skinning No
Volume Textures Yes, but I'm not 100% sure.
W Buffer --- Unsure.
W Fog -- Yes, but I'm not 100% sure.
Z Plane
===
Z Fog -- Unsure
Z Mask - Unsure
Fast Z Clear --- No
HierachicalZ --- No
HyperZ - No
Z-buffer: 16, 24, 32 bits -- 16 and 24
8 bit Stencil -- Yes
Effects?
Fog Effects What exactly do you mean?
Texture Lighting --- No, but I'm not 100% sure.
Video Textures - No
Reflections Yes
Shadows If you mean {SGIX,ARB}_depth_texture,
then no.
Spotlights - What exactly do you mean?
LOD Biasing Yes
Texture Morphing --- What exactly do you mean?
Video Features
==
Adaptive De-interlacing - See the GATOS project @ http://gatos.sourceforge.net/
Motion compensation - See the GATOS project
IDCT (sp?) -- See the GATOS project
Driver Optimisations
3DNow! - Yes
SSE Yes
SSE2 --- No
--
Tell that to the Marines!
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glXGetProcAddress question
On Wed, Apr 24, 2002 at 04:49:34PM -0600, Brian Paul wrote: Brian Paul wrote: Perhaps you should try out this change before I commit it to the DRI. Try editing build/xc/lib/GL/GL/Makefile, look for the line that has the string -Wl,-soname and replace it with -Wl,-Bsymbolic,-soname. Remove the libGL.so* files and rebuild the lib. That does fix the problem. I guess now you have to decide if you want to help people write applications that may break in unexpected ways on other platforms or even old Linux installs. The real sticking point in all of this is that neither the developer that wrote the bad code (me, in this case) or the end-user get any sort of a useful error message. In my case, I just got a segfault that GDB told me was in a function that I didn't even call. The reason was that it tried to execute code in my function pointer table, and the nearest symbol was one of the other function pointers. This may be a stretch beyond the realm of possability, but is there any way to fix it and give some sort of a compile-time or link-time warning that the developer is only asking for trouble? The big issue being backwards compatability. We need to not only provide it in the DRI drivers, but we need to (try to) provide it in applications that use libGL.so. If nothing else, I'm very good at opening large cans of wriggly worms. :) -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
On 2002.04.25 19:23 Leif Delgass wrote: ... Jose, I just tried removing agpgart before starting X, and I'm getting a kernel NULL pointer dereference. I think it's because we are using dev_priv-buffers-handle to read the vertex buffers -- for PCI, there's no DRM_FIND_MAP for dev_priv-buffers and no DRM_IOREMAP for dev_priv-buffers and therefore no handle. I see... Is there another way to access the buffer for PCI (I know you were trying to use buf-address before), or do we need to initialize the handle another way for PCI? I don't know yet how. This makes me want even more to make the PCI coding more compatible with the AGP/PCI GART one. I think that we should be able to request individual buffers as well (i.e., in addition, but without changing drmAddBufs as it's really better to allocate a big number of buffers there to avoid code duplication), then IOREMAP them as is done with AGP/PCI GART. The problem is that I don't fully understand linux memory management enough. I'll keep studying it to find a solution to this, which I wasn't yet able to do these past 2 days. BTW, I don't know if this is related to Peter's crash in the dispatch_clear, but it will come up once that's fixed. Yep. I'll start to make mach64-0-0-4-branch snapshots so that the PCI people (and the others in general) can remain in the loop avoiding problems afterwards. -- Leif Delgass http://www.retinalburn.net José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] glXGetProcAddress question
Ian Romanick wrote: On Wed, Apr 24, 2002 at 04:49:34PM -0600, Brian Paul wrote: Brian Paul wrote: Perhaps you should try out this change before I commit it to the DRI. Try editing build/xc/lib/GL/GL/Makefile, look for the line that has the string -Wl,-soname and replace it with -Wl,-Bsymbolic,-soname. Remove the libGL.so* files and rebuild the lib. That does fix the problem. I guess now you have to decide if you want to help people write applications that may break in unexpected ways on other platforms or even old Linux installs. The real sticking point in all of this is that neither the developer that wrote the bad code (me, in this case) or the end-user get any sort of a useful error message. In my case, I just got a segfault that GDB told me was in a function that I didn't even call. The reason was that it tried to execute code in my function pointer table, and the nearest symbol was one of the other function pointers. This may be a stretch beyond the realm of possability, but is there any way to fix it and give some sort of a compile-time or link-time warning that the developer is only asking for trouble? The big issue being backwards compatability. We need to not only provide it in the DRI drivers, but we need to (try to) provide it in applications that use libGL.so. Some ideas off the top of my head for detecting a bad libGL: 1. Use dlopen() to open libGL and dlsym() to get glBegin. Compare that pointer to the result of glXGetProcAddress(glBegin). If they're different, something's wrong. 2. Purposely override one of the lesser-used GL functions in your application, such as glIndexMask(). Have your glIndexMask() func just set a flag if it gets called. Try calling/jumping through the pointer returned by glXGetProc- Address(glIndexMask). If your flag got set, you'll know the library wasn't built with -Bsymbolic. Both of these ideas probably have downsides that haven't occured to me yet. If nothing else, I'm very good at opening large cans of wriggly worms. :) Yeah, I gotta hand it you there. :) -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach 64 DMA success!
First off, I haven't checked this in yet, because I need to do some cleanup, but I've got synchronous DMA working for vertex buffers on both AGP and PCI (PCI for me meaning with agpgart unloaded). Unfortunately, at the moment it's actually slower than MMIO, since it's synchronous (wait for idle at the end of every pass) and there's the overhead of the descriptor table setup. So I guess the next thing to do will be to figure out the buffer aging. I set up the descriptor table in PCI space using the pci_pool interface that the bus master test used, and I keep the handles in dev_priv. It took me awhile to figure out how to properly pass the physical address of the buffers to the card. What I'm doing for pci is using: address = (u32) virt_to_phys((void *)buf-address) and for AGP: address = (u32) buf-bus_address and to get a valid pointer for reading/writing the buffer with PCI I use: u32 *p = (u32 *) buf-address Jose, you almost had it before, it's just a matter of using the right types and cast. I'll try and send you a patch soon when I get things cleaned up a bit. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Mach 64 DMA success!
On 2002.04.26 20:17 Leif Delgass wrote: First off, I haven't checked this in yet, because I need to do some cleanup, but I've got synchronous DMA working for vertex buffers on both AGP and PCI (PCI for me meaning with agpgart unloaded). Unfortunately, at the moment it's actually slower than MMIO, since it's synchronous (wait for idle at the end of every pass) and there's the overhead of the descriptor table setup. This is great news! Great work Leif! So I guess the next thing to do will be to figure out the buffer aging. mmm.. I think that we should wait until this weekend to checkout Frank's interrupt model before we get into too much details with buffer aging. Instead of doing buffer aging, perhaps we could just shift the engine idle wait to before submitting the DMA buffer and leave the DMA buffer running while we returned control to the client. This way we could experience some concurrency. We also need to workout the texture uploads to see if we can address the VT switching locking issues. I set up the descriptor table in PCI space using the pci_pool interface that the bus master test used, and I keep the handles in dev_priv. It took me awhile to figure out how to properly pass the physical address of the buffers to the card. What I'm doing for pci is using: address = (u32) virt_to_phys((void *)buf-address) and for AGP: address = (u32) buf-bus_address and to get a valid pointer for reading/writing the buffer with PCI I use: u32 *p = (u32 *) buf-address Jose, you almost had it before, it's just a matter of using the right types and cast. I'll try and send you a patch soon when I get things cleaned up a bit. It's good that you worked it out and PCI is no longer broken. Nevertheless I still want to get to the bottom of this issue as I feel unconfortable with the inconsistency between the different PCI and AGP/PCI-GART treatement everywhere. -- Leif Delgass http://www.retinalburn.net José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Fix for PCI mach64 and DMA code committed
The mach64-0-0-4-branch should be working now for PCI cards, though I don't know if this will be enough to fix ppc -- probably not yet. It uses the correct pointer to read the vertex buffer and thus avoids a NULL pointer dereference in the kernel module. I did find out that on big-endian arches, the framebuffer handle passed to the Mesa driver is the big-endian aperture (the upper 8MB of the extended 16MB aperture). I've also checked in my hacked-up DMA code, but it's currently disabled until we can clean things up a bit. But it does work for me, so if you want to test it: change the #define of MACH64_USE_DMA to 1 in mach64_drv.h in the DRM. If you're updating your source from cvs, you should probably do a fresh 'make World' as some headers have changed here and there. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach 64 DMA success!
On Fri, 2002-04-26 at 21:17, Leif Delgass wrote: It took me awhile to figure out how to properly pass the physical address of the buffers to the card. What I'm doing for pci is using: address = (u32) virt_to_phys((void *)buf-address) That doesn't look right. If the physical and bus address are the same on i386, that's probably coincidence, you should use something like virt_to_bus. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64-0-0-4-branch currently unusable
On Fri, 26 Apr 2002 11:22:08 -0400 (EDT) Leif Delgass [EMAIL PROTECTED] wrote: I can't remember, is your card PCI or AGP? Do you see a kernel oops in the system log? It's an AGP card. And no, there was probably no more time to write out a kernel oops to disc. The last thing I see in the logfiles is the loading of the mach64 drm module. The next thing is syslogd restart :) ... Apr 26 00:34:17 viking modprobe: modprobe: Can't locate module char-major-10-134 Apr 26 00:34:18 viking modprobe: modprobe: Can't locate module char-major-226 Apr 26 00:34:18 viking modprobe: modprobe: Can't locate module char-major-226 Apr 26 00:34:18 viking kernel: [drm] AGP 0.99 on VIA Apollo KT133 @ 0xd000 6 4MB Apr 26 00:34:18 viking kernel: [drm] Initialized mach64 1.0.0 20020417 on minor 0 Apr 26 00:34:18 viking modprobe: modprobe: Can't locate module char-major-81-1 Apr 26 00:34:18 viking kernel: [drm] GUI_STAT=0x Apr 26 00:34:18 viking kernel: [drm] GUI_CNTL=0x0001 Apr 26 00:39:30 viking syslogd 1.4.1#10: restart. ... I wonder whether those modprobe messages mean something. char-major-10-134 belongs to /dev/apm_bios. That's all right, I have ACPI support in my kernel, not APM. char-major-226 is /dev/dri/card0. The char-major-81-1 is /dev/video1. Maybe that's the v4l extension probing for video devices. On /dev/video0 I have a TV card. Regards, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Quick question about FreeBSD
On Thu, 2002-04-25 at 13:43, Adam K Kirchhoff wrote: Can anyone fill me in really quickly about the status of the DRI under FreeBSD? I know that some cards work (Voodoo3 and G400, iirc), but is the latest code on the trunk usable under FreeBSD? Do you still need to pull the code from the BSD specific branch? In short, is it possible to get DRI on a Radeon7500 working under FreeBSD? :-) Adam Info on the status of the DRI on FreeBSD can be found at: http://gladstone.uoregon.edu/~eanholt/dri/ You can use drm-kmod and XFree86 4.2.0 from ports to get it working easily. The trunk code requires newer DRM, which may work with alanh's version which is in CVS, or with my experimental version (which is untested) on the webpage. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] kernel-2.4.18 to linux-drm-CVS-patch
--- Jens Owen [EMAIL PROTECTED] wrote: Finally, it looks like it would also be a good idea to review and possibly move the kernel development changes back into our repository. Specifically, I'm talking about changes to the schedule wait queses as were done to drm_fops.h; changes to the page allocation in i810_dma.c; and any other *new* changes from the kernel development branch. I realize the merge from the kernel repository back to ours is more than we originally talked about. However, it would help keep things synchronized as we move forward. Understanding some of these changes isn't as *mechanical*; and we need to make sure any of the changes we move back to our repository still compile and work on older 2.4 kernels. This patch contains code from kernel-2.4.18 it was diffed with. Root=:pserver:[EMAIL PROTECTED]:/cvsroot/dri Repository=xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel I really don't know what in kernel-2.4.18 was old vs new (better/worse) but I used my best judgment. Will this compile with older 2.4 kernels? I do not know. How should/could I test this. __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com kernel-2.4.18-linux-drm-CVS-patch Description: kernel-2.4.18-linux-drm-CVS-patch
Re: [Dri-devel] Mach64-0-0-4-branch currently unusable
On Fri, 26 Apr 2002 08:41:08 +0200 Felix Kühling [EMAIL PROTECTED] wrote: Hi, I cvs updated mach64-0-0-4-branch last night and recompiled (previous update was on sunday). Right after starting glxgears the screen switched off (like with xset dpms force off) and the machine hung. The sysrq keys didn't work. I updated again this night and now it works. Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon Card Features DRI Checklist. Clarifications part 1
Howzit Ian? Thanks for your response. I'm not the most qualified to answer this, but I think most of the more qualified people are pretty busy adding some of these features. :) Noted. But if yours is the only response and / or there are no differing answers guess what, you will become correct (most qualified) by default. g What exactly do you mean? seems to have a suspiciously high corelation with the marketing blurb features. g In other words it's from ATI's brochures on their various cards. I'll try and clarify. ATI R100 (Radeon) = Mapping === Bump --- No. Will be possible once (if) the extension is added to Mesa. By this I am assuming you mean environment bumpmapping. Yes, Environmental bumpmapping. Emboss - What exactly do you mean? If you are refering to Nvidia's NV_texgen_emboss extension, then it will likely never be supported due to Nvidia's IP. It was in ATI's brochure, I grabbed it out of this brochure point: * Emboss, Dot Product 3 and Environment bump mapping (that's letter for letter, same layout - you decide please) Please see this ATI page on how to do it in HW with OpenGL http://www.ati.com/developer/sdk/RadeonSDK/Html/Tutorials/RadeonBumpMap.html#EMBOSS PC Paradox: (http://www.pcparadox.com/Editorials/BumpMapping/Bump2.shtml#emboss) Emboss Mapping The real name for emboss mapping is Multi-Pass Alpha Blended Bump Mapping. So as you can see, emboss mapping sorta stuck as the name. (and the acronym MPABBM really didn't seem to fit either :) Well there is a reason that emboss mapping has that weird funky name. The name is actually a great description of how this technique gets around the whole lighting problem I discussed on the previous page. But first I'd like to start off by saying that emboss mapping was the first method used to simulate bump mapping in real time, and thus was lacking in many ways. These small problems made emboss mapping look dullish and took an unnecessary amount of time for such a simple rendition of the effect. Ok, now emboss mapping achieves the bumpy effect by creating a monochrome version of the texture map being bumpified and then applying it to the polygon and shifting it slightly. To help you visualize this effect, think of a drop shadow effect, where lettering on a page has a black set of the same lettering offset just a little bit. Drop shadowing and emboss mapping are essentially the same. In emboss mapping once the monochrome version of the texture has been shifted, it is then cut and blended with the original and applied to the texture, giving it the bumpy effect. There are many limitations to emboss mapping, and here are a few. Emboss mapping only supports polygonal objects and can not be applied to a volumetric or multi-lit surfaces. Also Emboss mapping is limited to lighting coming from a certain angle (45 to -45 degrees). It can not handle more than one height of bumps because the bumping has to be uniform across the entire object. And most importantly, Emboss mapping can really slow down your CPU because of all the converting and FPU calculations it has to do to shift a texture perfectly. System Memory Blits What exactly do you mean? I'll dig up a decent definition for you, it is however from DX. Superscalar Rendering -- What exactly do you mean? Perhaps they describe the fact that the R100 renders as super-scalor rendering because it has two pipelines? From Lost Circuits: (http://www.lostcircuits.com/video/atifury/3.shtml) SuperScalar Rendering Engine The RAGE 128 uses two graphics pipelines working in concert to process two pixels each clock cycle. This kind of parallelism is typical of a superscalar architecture. Consequently, the two RAGE 128 engines which render the scene in parallel, is referred to as a Super Scalar Rendering Engine. The speed of rendering is very close to twice that of single pipelined graphic chips. Twin Cache Architecture What exactly do you mean? From PC Insights: (http://www.pcinsight.com/reviews/aiw128/aiw1283.asp) Twin Cache Architecture Of all the 3D features of the Rage 128 chip, the Twin Cache Architecture seems to stand out the most because it is unique to the Rage 128. The Rage 128 uses an 8KB buffer to store texels that are used by the 3D texel engine. In order to improve performance even more though, ATI engineers have also incorporated a 8KB pixel cache used to write pixels back to the frame buffer. From Lost Circuits: (http://www.lostcircuits.com/video/atifury/3.shtml) Twin Cache Architecture Like microprocessors, the on-chip cache in graphics chips is growing dramatically. The RAGE 128 has not only incorporated significantly more on-chip
