[Dri-devel] New code in mach64-0-0-3-dma-branch: how to approach?
Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in own words: Most of the first cut of the DMA code. It's got most of the dispatch architecture in place (Lacks actual DMA submission (The easy part, really...)) so it's not done yet, but I promised people that done or not, I'd do a check-in of this... The part which is missing is more or less what we have in the mach64-0-0-4-branch, except that the state update is still being made with MMIO. So either we add the remaining parts to mach64-0-0-3-branch or we bring Frank's changes to mach64-0-0-4-branch. Personally I'm more in favor of the later, since it will avoid redundant work of merging back and forward, and will also enable the PowerPC architecture to participate in testing. So before we starting the merge, it's needed to include the state update in the buffers. Although I still have some concerns about security, the fact is that the only security problem we've seen so far is that a malicious client can lock the card (by setting a 0 texture address offset) and is not clear that we can recover from that too. The DMA submission does create some obstacules indiscriminate register access, as Frank commented in his code: Through some pretty thorough testing, it has been found that the RagePRO engine will pretty much ignore any commands sent via the gui-master pathway that aren't gui operations (the register gets set, but the actions that are normally associated with the setting of those said registers doesn't happen.). So, it's safe to send us buffers of gui commands from userspace (altering the buffer in mid-execution will at worst scribble all over the screen and pushing bogus commands will have no apparent effect...) But above all, is much easier to put the state update in the client for now - while the security isn't completely worked out - so that we can move forward with the DMA support, and at any time if we do come to the conclusion that this model isn't secure we can easily switch back. José Fonseca
[Dri-devel] Bamboo Floorings
Bamboo Flooring Limited ; The most environmentally friendly, hardest wearing hard wood flooring is now available at the best prices! Save almost £5000 on a 1500 sq. meter delivery These bamboo products are made from NATURAL materials using modern technology, retaining the original advantages of bamboo. The benefits are that after three years growth from the selectively managed forests, the main stems are straight. Therefore, distinctive because there is little difference between upper and lower diameter. ; As it is the fastest growing grass plant it is ENVIRONMENTALLY the best product available for hard flooring. It is becoming the most fashionable flooring; an example is that it is been laid in the famous SAVOY HOTEL. It will look elegant and classy in Hotels, Sports Halls, Dance Floors or in the home. People with allergies or suffer from hay fever will benefit. This is because with three UV coatings, it provides a smooth, dust free surface. It is also slip resistant and easy to maintain and clean. It will reduce expenditure in Hotels, pubs and the home. Unlike carpets and other inferior flooring surfaces, it will not fade when exposed to direct sunlight. It can withstand lighted cigarettes, spillages and heavy or constant traffic. Prices 15 x 1850 x 92 mm board is £24 a square meter. 15 x 920 x 92 mm board is £23 a square meter. 12 x 920 x 92 mm board is £15 a square meter. 12 x 1850 x 92 mm board is £16 a square meter. Please contact Nick Reaks to place an order or for any other information Tel 01423 524529 or 07710 0329523 email [EMAIL PROTECTED] If you do not want to receive emails from us please reply with remove Bamboo Flooring Limited.htm Description: Binary data
Re: [Dri-devel] New code in mach64-0-0-3-dma-branch: how to approach?
On Wed, 1 May 2002, José Fonseca wrote: Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in own words: Most of the first cut of the DMA code. It's got most of the dispatch architecture in place (Lacks actual DMA submission (The easy part, really...)) so it's not done yet, but I promised people that done or not, I'd do a check-in of this... The part which is missing is more or less what we have in the mach64-0-0-4-branch, except that the state update is still being made with MMIO. So either we add the remaining parts to mach64-0-0-3-branch or we bring Frank's changes to mach64-0-0-4-branch. Personally I'm more in favor of the later, since it will avoid redundant work of merging back and forward, and will also enable the PowerPC architecture to participate in testing. I agree. Frank is using basically the same setup for the descriptor table as I have, so that should merge well. We can add the necessary list initialization to _dma_init and keep the bus master test and setup from the mach64-0-0-4-branch, I think. One thing I realized concerning blits: the utah driver uses the host_data[0-15] registers to do blits which treats blits as a GUI-master operation. This means it works with pseudo-DMA. I think the better way to do it is to use the system bus master method and interrupt handling that Frank has set up. However, if we want to keep an MMIO mode, we'll have to have an alternate method for blits. So before we starting the merge, it's needed to include the state update in the buffers. Although I still have some concerns about security, the fact is that the only security problem we've seen so far is that a malicious client can lock the card (by setting a 0 texture address offset) and is not clear that we can recover from that too. The DMA submission does create some obstacules indiscriminate register access, as Frank commented in his code: Through some pretty thorough testing, it has been found that the RagePRO engine will pretty much ignore any commands sent via the gui-master pathway that aren't gui operations (the register gets set, but the actions that are normally associated with the setting of those said registers doesn't happen.). So, it's safe to send us buffers of gui commands from userspace (altering the buffer in mid-execution will at worst scribble all over the screen and pushing bogus commands will have no apparent effect...) But above all, is much easier to put the state update in the client for now - while the security isn't completely worked out - so that we can move forward with the DMA support, and at any time if we do come to the conclusion that this model isn't secure we can easily switch back. This would make the driver work more like the utah setup, so it might make it easier to reuse some of the code, and it would be easier to get the proper order of state and vertex data in the buffers. On the security issue, I think we need to be careful about how we handle blits. Frank's code for _dma_buffers allows sending buffers to the DRM, does that mean this takes the place of _dma_vertex? I assume you still need to call this to allocate the buffers before filling them. -- Leif Delgass http://www.retinalburn.net
[Dri-devel] PCI buffers and buffer private struct
I realized what was causing the oops when trying to access the buffer private struct in the PCI path. The DRM template code for addbufs_pci does __not__ allocate memory for a private structure for the buffers, whereas the template code for addbufs_agp and addbufs_sg does. I'm not sure if we'll need private buffer data if we're using interrupts rather than buffer aging. I suppose the primitive type would be needed if we move the command placement in vertex buffers to the drm. Does anyone know why the template code omits private structures for PCI DMA buffers? -- Leif Delgass http://www.retinalburn.net
Re: [Dri-devel] New code in mach64-0-0-3-dma-branch: how to approach?
On 2002.05.01 16:18 Leif Delgass wrote: One thing I realized concerning blits: the utah driver uses the host_data[0-15] registers to do blits which treats blits as a GUI-master operation. This means it works with pseudo-DMA. I think the better way to do it is to use the system bus master method and interrupt handling that Frank has set up. However, if we want to keep an MMIO mode, we'll have to have an alternate method for blits. I suppose we can do as we have been doing so far: using the MMIO frame buffer. Anyway, the MMIO support is interesting as a debugging aid, since theoretically every hardware should work with DMA. So before we starting the merge, it's needed to include the state update in the buffers. ... This would make the driver work more like the utah setup, so it might make it easier to reuse some of the code, and it would be easier to get the proper order of state and vertex data in the buffers. Yes. I think that the gamma driver does this as well. On the security issue, I think we need to be careful about how we handle blits. Frank's code for _dma_buffers allows sending buffers to the DRM, does that mean this takes the place of _dma_vertex? I assume you still need to call this to allocate the buffers before filling them. The gamma driver also uses a general buffer submission DMA IOCTL instead of _dma_vertex, but I think that we could just use the current _dma_vertex interface for the time being, since they are semantically identical. José Fonseca
Re: [Dri-devel] Mach64 for ppc xf86-log etc
I attached a complete diff that should do the right thing. I believe this is the only way to do this in a portable fashion, even if results in some redundant work being done on bigendian machines. I also avoided to increment the pointer inside the macros, just in case the le32_to_cpu macro reuses it's argument. Peter, apply it by making something like patch -p1 -i mach64-endian-mmio.diff in the xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel and report back to us when you have time. Sorry about the lateness of my reply but i have been away over night and didn´t get this mail until just recently. The patch fails when patching mach64_state.c. It exits with HUNK #2 FAILED at 535 and i am not comfortable with applying the changes manually since there are a great risc that i would do something wrong. I am using the latest dri branch which i downloaded a couple of minutes ago. Michael, have you got hold of the screenshot or would you like me to re send it to you? Peter
Re: [Dri-devel] Mach64 for ppc xf86-log etc
On Wed, 1 May 2002, Peter Andersson wrote:
Sorry about the lateness of my reply but i have been away over night and
didn´t get this mail until just recently. The patch fails when patching
mach64_state.c. It exits with HUNK #2 FAILED at 535 and i am not
comfortable with applying the changes manually since there are a great
risc that i would do something wrong. I am using the latest dri branch
which i downloaded a couple of minutes ago.
Try the attached patch. It's merged with the current changes so it should
apply. I checked in some changes after Jose made his original patch.
--
Leif Delgass
http://www.retinalburn.net
? ppc.diff
Index: mach64_drv.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_drv.h,v
retrieving revision 1.1.6.3.2.11
diff -u -r1.1.6.3.2.11 mach64_drv.h
--- mach64_drv.h1 May 2002 00:10:29 - 1.1.6.3.2.11
+++ mach64_drv.h1 May 2002 18:02:15 -
-359,9 +359,8
#define MACH64_ADDR(reg) (MACH64_BASE(reg) + reg)
-#define MACH64_DEREF(reg) *(volatile u32 *)MACH64_ADDR(reg)
-#define MACH64_READ(reg) le32_to_cpu(MACH64_DEREF(reg))
-#define MACH64_WRITE(reg,val) do { MACH64_DEREF(reg) = cpu_to_le32(val); } while (0)
+#define MACH64_READ(reg) readl(MACH64_ADDR(reg))
+#define MACH64_WRITE(reg,val) writel((val),MACH64_ADDR(reg));
#define DWMREG00x0400
Index: mach64_state.c
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_state.c,v
retrieving revision 1.1.6.4.2.17
diff -u -r1.1.6.4.2.17 mach64_state.c
--- mach64_state.c 1 May 2002 00:10:29 - 1.1.6.4.2.17
+++ mach64_state.c 1 May 2002 18:02:16 -
-526,7 +526,8
while ( used ) {
u32 reg, count;
- reg = le32_to_cpu(*p++);
+ reg = le32_to_cpu(*p);
+ p++;
used--;
count = (reg 16) + 1;
-543,7 +544,8
--fifo;
/* data is already little-endian */
- MACH64_DEREF(reg) = *p++;
+ MACH64_WRITE(reg, le32_to_cpu(*p));
+ p++;
used--;
reg += 4;
Re: [Dri-devel] Radeon Card Features DRI Checklist.
On Mon, Apr 29, 2002 at 04:40:21AM +0200, Smitty wrote: Added: Pixel shader Programmable texture blending modes - Yes. EXT_texture_env_combine is supported, and ARB_texture_env_combine and ARB_texture_env_crossbar will be soon. ATIX_texture_env_combine3 is not supported, but probably could be. NV_texture_env_combine4 is also not supported, but I think the hardware could do it. The extension is marked as Nvidia proprietary, but I have no idea what their current stance is on this WRT DRI (nor am I in any position to ask them, obviously). http://www.artxinc.com/developer/sdk/RadeonSDK/Html/Info/Extensions/ATIX_texture_env_combine3.html http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_env_combine4.txt Projective Textures-- Yes, I think. Changed: Mapping === Environment Bump --- No. Dot Product 3 Bump-- Yes. Emboss Bump Yes. The card supports all the required blend modes, but NV_textgen_emboss is not supported, so you have to calculate the texture coordinates yourself. This extension is also marked as Nvidia proprietary, so see my comment about blending modes, above. http://oss.sgi.com/projects/ogl-sample/registry/NV/texgen_emboss.txt Texture === Cache -- Automatically supported by the hardware. -- Tell that to the Marines! ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
On Wed, 1 May 2002, Leif Delgass wrote:
Try the attached patch. It's merged with the current changes so it should
apply. I checked in some changes after Jose made his original patch.
Oops, I had an errant semicolon there. Try this one. Patch with:
patch -p0 -i mach64-endian-mmio-3.diff
--
Leif Delgass
http://www.retinalburn.net
Index: mach64_drv.h
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_drv.h,v
retrieving revision 1.1.6.3.2.11
diff -u -r1.1.6.3.2.11 mach64_drv.h
--- mach64_drv.h1 May 2002 00:10:29 - 1.1.6.3.2.11
+++ mach64_drv.h1 May 2002 18:22:34 -
-359,9 +359,8
#define MACH64_ADDR(reg) (MACH64_BASE(reg) + reg)
-#define MACH64_DEREF(reg) *(volatile u32 *)MACH64_ADDR(reg)
-#define MACH64_READ(reg) le32_to_cpu(MACH64_DEREF(reg))
-#define MACH64_WRITE(reg,val) do { MACH64_DEREF(reg) = cpu_to_le32(val); } while (0)
+#define MACH64_READ(reg) readl(MACH64_ADDR(reg))
+#define MACH64_WRITE(reg,val) writel((val), MACH64_ADDR(reg))
#define DWMREG00x0400
Index: mach64_state.c
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/Attic/mach64_state.c,v
retrieving revision 1.1.6.4.2.17
diff -u -r1.1.6.4.2.17 mach64_state.c
--- mach64_state.c 1 May 2002 00:10:29 - 1.1.6.4.2.17
+++ mach64_state.c 1 May 2002 18:22:35 -
-526,7 +526,8
while ( used ) {
u32 reg, count;
- reg = le32_to_cpu(*p++);
+ reg = le32_to_cpu(*p);
+ p++;
used--;
count = (reg 16) + 1;
-543,7 +544,8
--fifo;
/* data is already little-endian */
- MACH64_DEREF(reg) = *p++;
+ MACH64_WRITE(reg, le32_to_cpu(*p));
+ p++;
used--;
reg += 4;
Re: [Dri-devel] New code in mach64-0-0-3-dma-branch: how to approach?
On Wednesday 01 May 2002 03:58 am, JosX Fonseca wrote: Frank just commited a set of changes to the mach64-0-0-3-dma-branch. Is in own words: Most of the first cut of the DMA code. It's got most of the dispatch architecture in place (Lacks actual DMA submission (The easy part, really...)) so it's not done yet, but I promised people that done or not, I'd do a check-in of this... Yeah, if you'll remember, I said that I'd complete the code/test it barring fate handing me another full plate. Well, I probably shouldn't have made that comment, because I didn't get much of any coding done last week. I won't bore you w/the details, suffice it to say that I had to scramble to try to fix my financial situation due to my so-called employer's not paying me consistently. The part which is missing is more or less what we have in the mach64-0-0-4-branch, except that the state update is still being made with MMIO. So either we add the remaining parts to mach64-0-0-3-branch or we bring Frank's changes to mach64-0-0-4-branch. Personally I'm more in favor of the later, since it will avoid redundant work of merging back and forward, and will also enable the PowerPC architecture to participate in testing. I'm for it, I was going to actually consider doing that very thing but the fun on my end of things just kept me distracted enough that I couldn't sit down and just code the whole thing. For the record, NEVER stay around at a company if they don't do a consistent and regular payroll run at the appointed times per their policies- any inconsistencies show in that situation, you should leave it right then and there. So before we starting the merge, it's needed to include the state update in the buffers. Although I still have some concerns about security, the fact is that the only security problem we've seen so far is that a malicious client can lock the card (by setting a 0 texture address offset) and is not clear that we can recover from that too. I was able to make it recover from the locked state with DMA, etc. with the XAA FIFO size change by using the reset code in the mach64-0-0-3-dma-branch. Something to check would be to see if a 0 texture address offset would hang things with the interrupt (another reason for having it...) handler checking to see if we're locked up solid. I couldn't get the X server to do it's usual lockup behavior (if you ran X after doing the DMA test with the little testbed driver, it'd lock up tight...) when I inserted a forced reset like the one in my submitted code- and the DMA code worked just fine after startup (Of course, it reset the FIFO size...). -- Frank Earl ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] my first probe with dri and ati rage mobility P/M/compaq e500
Hello, I have trayed with DRI (mach64 driver from 04.30.2002) and cannot see any difference in perfomance. Without install of DRI I had about ~170 FPS by gears, and glxinfo says DRI is on(?-) astonishment). With DRI and libGL.so linked to mesa, I had ~175 FPS and glxinfo says DRI is on. (OK, i can leave wit it) With DRI and libGL.so linked to one from SuSE (glxinfo means it's from SGI), I had ~175 FPS and glxinfo says DRI is off (|-( astonishment again). What make I wrong? I'm missing very well a install manual for modules that now under development(specialy mach64). My system is basicaly SuSE Linux 7.3 PRO(but 2.4.19-pre7 + XFree86-4.2.0 + KDE 3.0.0). I would like to have a realy 3D perfomance with my card. I have not any chance to change it. Can I maybe help? I'm a software developer, unfortunately not for firmware or other similar things. Best regards Alexander(Alex) Kern ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Hi Do you use some framebuffer device? To the best of my knowledge - no. You can start to give us the last lines of /var/log/messages, as I think that there should be a kernel oops in there. The XFree86.log may be interesting too. YESS! There is OOPS. See attached. Cheers, Sergey May 1 20:50:56 localhost kernel: [drm] Creating pci pool May 1 20:50:56 localhost kernel: [drm] Allocating descriptor table memory May 1 20:50:56 localhost kernel: [drm] descriptor table: cpu addr: 0xc0318000, bus addr: 0x00318000 May 1 20:50:56 localhost kernel: [drm] Starting DMA test... May 1 20:50:56 localhost kernel: [drm] starting DMA transfer... May 1 20:50:56 localhost kernel: [drm] waiting for idle... May 1 20:50:56 localhost kernel: [drm] waiting for idle...done May 1 20:50:56 localhost kernel: [drm] DMA test succeeded, using synchronous DMA mode May 1 20:51:02 localhost kernel: [drm] freeing descriptor table from pci pool May 1 20:51:02 localhost kernel: Unable to handle kernel paging request at virtual address 5a5a5a5a May 1 20:51:02 localhost kernel: printing eip: May 1 20:51:02 localhost kernel: c01aec39 May 1 20:51:02 localhost kernel: *pde = May 1 20:51:02 localhost kernel: Oops: May 1 20:51:02 localhost kernel: CPU:0 May 1 20:51:02 localhost kernel: EIP:0010:[pool_find_page+25/128]Not tainted May 1 20:51:02 localhost kernel: EIP:0010:[c01aec39]Not tainted May 1 20:51:02 localhost kernel: EFLAGS: 00013096 May 1 20:51:02 localhost kernel: EIP is at pool_find_page [kernel] 0x19 May 1 20:51:02 localhost kernel: eax: 5a5a5a5a ebx: 5a5a5a5a ecx: 5a5a5a5a edx: d0c48000 May 1 20:51:02 localhost kernel: esi: 5a5a5a5a edi: 5a5a5a5a ebp: 5a5a5a5a esp: d0b23e84 May 1 20:51:02 localhost kernel: ds: 0018 es: 0018 ss: 0018 May 1 20:51:02 localhost kernel: Process X (pid: 1383, stackpage=d0b23000) May 1 20:51:02 localhost kernel: Stack: c0321a84 0001 3296 5a5a5a5a 5a5a5a5a 5a5a5a5a cde3d000 c01aecbf May 1 20:51:02 localhost kernel:5a5a5a5a 5a5a5a5a 5a5a5a5a 0001 d0bd8bcc cde3d000 d0b23f48 cde3d000 May 1 20:51:02 localhost kernel:d2987cb6 5a5a5a5a 5a5a5a5a 5a5a5a5a 5a5a5a5a d298d720 006c 0002 May 1 20:51:02 localhost kernel: Call Trace: [pci_pool_free+31/240] pci_pool_free [kernel] 0x1f May 1 20:51:02 localhost kernel: Call Trace: [c01aecbf] pci_pool_free [kernel] 0x1f May 1 20:51:02 localhost kernel: [mach64:mach64_do_cleanup_dma+154/196] mach64_do_cleanup_dma [mach64] 0x9a May 1 20:51:02 localhost kernel: [d2987cb6] mach64_do_cleanup_dma [mach64] 0x9a May 1 20:51:02 localhost kernel: [mach64:__insmod_mach64_S.rodata_L304+17424/26288] __insmod_mach64_S.rodata_L304 [mach64] 0x4410 May 1 20:51:02 localhost kernel: [d298d720] __insmod_mach64_S.rodata_L304 [mach64] 0x4410 May 1 20:51:02 localhost kernel: [mach64:mach64_dma_init+173/196] mach64_dma_init [mach64] 0xad May 1 20:51:02 localhost kernel: [d2987d8d] mach64_dma_init [mach64] 0xad May 1 20:51:02 localhost kernel: [mach64:mach64_ioctl+239/256] mach64_ioctl [mach64] 0xef May 1 20:51:02 localhost kernel: [d2982d97] mach64_ioctl [mach64] 0xef May 1 20:51:02 localhost kernel: [sys_ioctl+535/560] sys_ioctl [kernel] 0x217 May 1 20:51:02 localhost kernel: [c0143907] sys_ioctl [kernel] 0x217 May 1 20:51:02 localhost kernel: [system_call+51/56] system_call [kernel] 0x33 May 1 20:51:02 localhost kernel: [c0106ecb] system_call [kernel] 0x33 May 1 20:51:02 localhost kernel: May 1 20:51:02 localhost kernel: May 1 20:51:02 localhost kernel: Code: 8b 00 8b 54 24 20 eb 39 8b 04 24 89 c2 89 44 24 04 8b 72 10
Re: [Dri-devel] my first probe with dri and ati rage mobility P/M/compaq e500
Alex, On 2002.05.01 20:50 alexander kern wrote: Hello, I have trayed with DRI (mach64 driver from 04.30.2002) and cannot see any difference in perfomance. Without install of DRI I had about ~170 FPS by gears, and glxinfo says DRI is on(?-) astonishment). With DRI and libGL.so linked to mesa, I had ~175 FPS and glxinfo says DRI is on. (OK, i can leave wit it) With DRI and libGL.so linked to one from SuSE (glxinfo means it's from SGI), I had ~175 FPS and glxinfo says DRI is off (|-( astonishment again). What make I wrong? I'm missing very well a install manual for modules that now under development (specialy mach64). My system is basicaly SuSE Linux 7.3 PRO(but 2.4.19-pre7 + XFree86-4.2.0 + KDE 3.0.0). It could be that the glxgears is picking other libGL.so. Please run ldd on glxinfo and glxgears. On the other hand could just be a coincidence. At this moment, the mach64 is under some heavy changes as we prepare to make subtancial improvements so it's a little slow. (I think that on my system glxgears is running at the same fps, both accel and not accel, too). But if you you run a real opengl app (like tuxracer), you will surely notice the difference in that case. What happens is that the bottleneck is in the communication to the card, so throughtput will be limited by the limited bandwidth, while complicated stuff (as texturing) will still run much faster than software. I would like to have a realy 3D perfomance with my card. I have not any chance to change it. Join the club! ;-) Can I maybe help? I'm a software developer, unfortunately not for firmware or other similar things. Every help is welcome! First let's try to fix your problem, in the mean while lurk around in the first chapters of the developer's FAQ (http://dri.sourceforge.net/doc/faq/) to see what this is all about. Best regards Alexander(Alex) Kern Regards, José Fonseca ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
On 1 May 2002, Sergey V. Udaltsov wrote: Hi Do you use some framebuffer device? To the best of my knowledge - no. You can start to give us the last lines of /var/log/messages, as I think that there should be a kernel oops in there. The XFree86.log may be interesting too. YESS! There is OOPS. See attached. Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in CVS now. Just update and rebuild and install the kernel module. This is not related to your original problem though, I'm not sure what would be causing a lockup on vt switches if no GL contexts are running. Cheers, Sergey -- Leif Delgass http://www.retinalburn.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
I have compiled the new kernel drivers and get the following error when trying to run glxgears: Error flushing vertex buffer: return = -16 Peter ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
On Wed, 1 May 2002, Peter Andersson wrote: I have compiled the new kernel drivers and get the following error when trying to run glxgears: Error flushing vertex buffer: return = -16 Peter That means the engine is locking up. Either wait_for_idle fails (DMA) or wait_for_fifo fails (MMIO). Is MACH64_USE_DMA set to 0 or 1? Is this with the MMIO patch applied? -- Leif Delgass http://www.retinalburn.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] New code in mach64-0-0-3-dma-branch: how to approach?
On Wed, 1 May 2002, Frank C. Earl wrote: The part which is missing is more or less what we have in the mach64-0-0-4-branch, except that the state update is still being made with MMIO. So either we add the remaining parts to mach64-0-0-3-branch or we bring Frank's changes to mach64-0-0-4-branch. Personally I'm more in favor of the later, since it will avoid redundant work of merging back and forward, and will also enable the PowerPC architecture to participate in testing. I'm for it, I was going to actually consider doing that very thing but the fun on my end of things just kept me distracted enough that I couldn't sit down and just code the whole thing. For the record, NEVER stay around at a company if they don't do a consistent and regular payroll run at the appointed times per their policies- any inconsistencies show in that situation, you should leave it right then and there. Frank, I merged your changes by hand into my 0-0-4 local tree and it compiles and runs (of course not using the interrupt path yet). Since we don't call the ioctl to install the interrupt handler yet, that path isn't used. A couple of changes I made were omitting some of the includes that drmP.h already includes and changing DMA(dma_immediate_bh) to mach64_dma_immediate_bh (which is the same thing). There were some changes already made in 0-0-4 that I ommitted, but there weren't many conflicts. I'm attaching the patch against 0-0-4 so you can take a look at it. If it looks ok as a starting point, I can check it in. -- Leif Delgass http://www.retinalburn.net mach64-dma-merge.diff.gz Description: GNU Zip compressed data
Re: [Dri-devel] Mach64 for ppc xf86-log etc
Leif Delgass wrote: On Wed, 1 May 2002, Peter Andersson wrote: I have compiled the new kernel drivers and get the following error when trying to run glxgears: Error flushing vertex buffer: return = -16 Peter That means the engine is locking up. Either wait_for_idle fails (DMA) or wait_for_fifo fails (MMIO). Is MACH64_USE_DMA set to 0 or 1? Is this with the MMIO patch applied? I have applied the patch supplied by you, (mach64-endian-mmio-3.diff). And MACH_USE_DMA is set to 1. Peter ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ 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.05.01 23:11 Peter Andersson wrote: Leif Delgass wrote: On Wed, 1 May 2002, Peter Andersson wrote: I have compiled the new kernel drivers and get the following error when trying to run glxgears: Error flushing vertex buffer: return = -16 Peter That means the engine is locking up. Either wait_for_idle fails (DMA) or wait_for_fifo fails (MMIO). Is MACH64_USE_DMA set to 0 or 1? Is this with the MMIO patch applied? I have applied the patch supplied by you, (mach64-endian-mmio-3.diff). And MACH_USE_DMA is set to 1. Peter Well, it should work on both cases, but the patch was meant to test with MACH_USE_DMA set to 0. Again, it should work with set as 1 (otherwise means a regression), but we wanted that it also worked with set as 0. Leif, if this doesn't work, I think that we should commit the mach64-endian-mmio-3.diff patch (since it's the Right Thing anyway), and have Peter do a cvs update -C to be sure everything is in sync (and set USE_DMA to 0 afterwards too). (I'm going to bed now so I won't be able to do this until tomorrow). José Fonseca ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64 (Rage XL) trouble
Hello! I've finally had a chance to upgrade to XFree86 4.2.0, and am trying out the bleeding edge builds for mach64. :) Quick version: it doesn't work. Long version: I think I have an AGP problem. glxinfo reports that direct rendering is off. the mach64 kernel driver compiled and is loaded, but agpgart errors out: mtrr: Serverworks LE detected. Write-combining disabled. mtrr: your processor doesn't support write-combining Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 816M agpgart: unable to determine aperture size. [drm] Initialized mach64 1.0.0 20010107 on minor 0 the drm and things were built from (against stock kernel 2.4.18): mach64-20020427-linux.i386.tar.bz2 Nothing very interesting happens in XFree86.log either. Couldn't find anything useful about the agpgart error either. I'm at a loss! (And unfortunately, the ati driver is REALLY slow for just regular 2D stuff. I can watch things repaint, etc. Wasn't like that in XFree86 4.1.0...) What should I do next? -- Kees Cook@outflux.net ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 for ppc xf86-log etc
Well, it should work on both cases, but the patch was meant to test with MACH_USE_DMA set to 0. Again, it should work with set as 1 (otherwise means a regression), but we wanted that it also worked with set as 0. I have just changed the MACH_USE_DMA to 0 and recompiled the kernel modules and still get the same error, Error flushing vertex buffer: return = -16 Peter ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64-0-0-4-branch snapshots
Hi Whoops. The oops is my fault, it's a bug in _cleanup_dma. It's fixed in CVS now. Just update and rebuild and install the kernel module. This is not related to your original problem though, I'm not sure what would be causing a lockup on vt switches if no GL contexts are running. OK, thanks. So it will be a part of today's build, won't it? I will take and test it tomorrow... Report will follow... Cheers, Sergey ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Radeon Card Features DRI Checklist. (Ian Romanick) Spam
Howzit Ian? First off, dankie. snip Noted, used, and added a few mechanisms to deal with: I think Nvidia proprietary Texture === Cache -- Automatically supported by the hardware. Not according to Michael Ntlworld, and he backed it up. Oh and I won't post such a massive email, I'll use links.g btw the list is now up on the (card) status page of dri.sourceforge.net. One last thing, is that there is a whole list of 11 items of which status is listed as Unsure of Status. Once finished (up to date at least), the fact that this list is created I can get moving on the Rage 128, and then the Mach 64 feature lists. Spam About the spam we've been getting on the list I've heard good things about SpamCop: http://spamcop.net I believe that you need the email headers and I'm on the DRI *digest* option... Liam it depends ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Radeon Card Features DRI Checklist. (Ian Romanick) Spam
On Thu, May 02, 2002 at 03:38:02AM +0200, Smitty wrote: Howzit Ian? First off, dankie. snip Noted, used, and added a few mechanisms to deal with: I think Nvidia proprietary Texture === Cache -- Automatically supported by the hardware. Not according to Michael Ntlworld, and he backed it up. Yeah, but the radeon hardware may have caches for things that are automatic as part of its processing and they are probably more likely what is being referred to here if you've been reading ati docs. What I described was what the driver does to get textures from the app to where the hardware uses them and what it does when the set of textures grows bigger than the available card memory. It's likely that what Ian says here is true as well, as he said a number of times, it depends what it actually means. -- Michael. ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
