Re: [Dri-devel] possible error in drm documentation, plus DMA question
Philip Brown wrote: I'm reading through http://dri.sourceforge.net/doc/drm_low_level.html int drmDMA(int fd, drmDMAReqPtr request) drmDMA can be used to reserve DMA buffers and to dispatch previously reserved DMA buffers. reserve DMA buffers?? I thought it is only currently used to dispatch them, and actual allocation of DMA buffers is done via I think they mean to get a buffer from the pool previously allocated by drmAddBufs(). drmAddBufs -- initialize global pool of buffers drmDMA -- get a buffer from the pool -- or send it to hardware. But you have to remember that the dma code in the original drm was hopelessly inappropriate for the drivers we ended up writing, so is largely unused. We probably only use the first meaning of drmDMA in any actual driver. Keith --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drmScatterGatherAlloc missing from docs
Philip Brown wrote: http://dri.sourceforge.net/doc/drm_low_level.html should be updated with a functional description of drmScatterGatherAlloc() [and probably a few other drmXXXYYY() routines that have appeared since 1999 ;-) ] Patches welcome... :-) Keith --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Corrupted textures on 64bit tuxracer
On Tue, 11 Mar 2003, Dave Jones wrote: On x86_64 (probably any 64bit arch also, but I haven't tested ia64 or alpha yet), tuxracer experiences texture corruption on ice patches and the sides of some hills. This is occurs on the very first race, so it's not hard to reproduce. AS you're gliding along, the grey patch approaches and flickers terribly, but the portions that are white snow seem to work fine. Wierd. I used a radeon 7500 to develop the x86-64 agpgart code, _and_ I used tuxracer almost exclusively to test it, and hadn't noticed any problems. I'll upgrade X to our latest beta rpm in a while, and see if I can reproduce here, as its been a while since I tested it (definitly before 4.3.0 came out). It does appear to be TCL related, so older X servers probably wouldn't show it. Just wondering if anyone else experiences this on 64bit archs with tuxracer to help determine if it might be a bug in the game, or a bug on the X side of things. It sounds like a DRI regression, although it could also be something as subtle as toolchain problems. During early agpgart development, broken gcc's made some really wacky effects happen in tuxracer 8-) With the environment variable set as Michel suggested, the main problem disappears. The other 'problem' I saw seems to just be a visual effect rather than a bug. I don't generally run tuxracer ever, so I never really noticed it before. ;o) I think this can be written off as a tuxracer bug now. Thanks. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drmScatterGatherAlloc missing from docs
On Wed, Mar 12, 2003 at 08:39:31AM +, Keith Whitwell wrote: Philip Brown wrote: http://dri.sourceforge.net/doc/drm_low_level.html should be updated with a functional description of drmScatterGatherAlloc() Patches welcome... :-) love to.. if I understood it... which would be facilitated by docs... or code comments... Best I have so far is, int drmScatterGatherAlloc(int fd, unsigned long size, unsigned long *handle); drmScatterGatherAlloc is called to allocate a large chunk of DMA-suitable memory. Calling it more than once is an error. Once the memory is allocated, the user-level may access it through passing the handle to drmAddMap() with drmMapType DRM_SCATTER_GATHER. User-level code only sees the virtual address space. physical address of the allocated memory is passed to the hardware through FM [*] int drmAgiAlloc(int fd, unsigned long size, unsigned long type, unsigned long *address, unsigned long *handle); cf: drmScatterGatherAlloc(), FM [*] FM == old programming joke. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm-filp-0-1-branch and radeon
Keith Whitwell wrote:
Keith Whitwell wrote:
Linus Torvalds wrote:
On Sun, 2 Mar 2003, Linus Torvalds wrote:
The _second_ DRI-enabled X startup caused problems, even if I had done
multiple non-DRI X sessions in between. This is what makes me think
that
the DRI kernel modules keep some history around that they
shouldn't. And
maybe the problem is hidden if you actually unload and re-load the
modules (is that what most people do?)
Ok, I went in and looked for suspicious behaviour, and I found some.
Look at AGP and MTRR behaviour: both of them are initialized by
drm_init() at module load time.
Both of them are _de-initialized_ by the DRM(takedown)() code, and
never
re-initialized by the DRM(setup)() code.
So an example of badness would be:
- load DRM modules (in my case as part of kernel bootup, since they
arecompiled in):
- initialize MTRR and AGP mappings
- run X with DRI.
- Everything is happy.
- exit DRI X
- we are the last close case for DRI, so DRM(release)() calls
DRM(takedown)(), which frees AGP and MTRR
- restart non-DRI X
- nothing happens
- kill non-DRI X
- nothing happens
- run X with DRI again
- oops. We now have neither AGP nor MTRR's set up, even though
the code looks like it is assuming it.
Yeah, maybe I'm missing where somebody else re-initializes AGP and
MTRR, but my point is that these things do not seem to nest
correctly. That mtrr_del() in particular seems to be wrong, and I do
indeed get a
mtrr: MTRR 2 not used
when shutting down X normally.
Comments? I haven't really gone through the whole path of what
happens at open()/release() time, and these are really nothing more
than that looks suspicious, maybe somebody who knows the code
better than I can take a better look at it.
Yes it looks suspicious, but I don't think it's the cause of the
lockups on X recycle.
Evidence for this:
- The lockup is new, while the code has been suspicious forever...
- I can exit and restart X just fine, it's only recycle that
locks. From the kernel point of view, these should be the same.
- In the Mesa embedded branch, I have a demo that closes reopens
its connections to the kernel without exiting. Again this works fine.
I've also verified that this lockup wasn't introduced in the filp
work, ie. it had already sneaked into the trunk somehow.
OK, I've had some time to track this down. It comes down to the changes
introduced to radeon_driver.c around 29 Oct last year.
revision 1.45
date: 2002/10/29 13:49:25; author: mdaenzer; state: Exp; lines: +30 -19
* preserve CRTC{,2}_OFFSET_CNTL in 2D driver to avoid bad effects when
pageflipping after a mode switch
* take current page into account in AdjustFrame(); writing the CRTC offset
via the CP was probably a bad idea as this can happen asynchronously,
reverted
* take frame offset into account when flipping pages
* handle CRTC2 as well for pageflipping (untested)
* preserve GEN_INT_CNTL on mode switches to prevent interrupts from getting
disabled
Michel, have you got time to look into why this is causing server
recycles to hang? I can't reproduce it on all machines, so it's
possible that your test box is one of the ones unaffected by this lockup
-- if you can't reproduce, let me know...
I'll poke around in the meantime try figure it out.
In fact the lockup comes down to this one line:
--- radeon_driver.c 28 Oct 2002 02:21:14 - 1.44
+++ radeon_driver.c 29 Oct 2002 13:49:25 - 1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0;
save-cap1_trig_cntl = 0;
save-bus_cntl = info-BusCntl;
+save-gen_int_cntl = info-gen_int_cntl;
/*
* If bursts are enabled, turn on discards
* Radeon doesn't have write bursts
Michel, what are the consequences of removing this?
Keith
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm-filp-0-1-branch and radeon
On Mit, 2003-03-12 at 10:55, Keith Whitwell wrote: In fact the lockup comes down to this one line: --- radeon_driver.c 28 Oct 2002 02:21:14 - 1.44 +++ radeon_driver.c 29 Oct 2002 13:49:25 - 1.45 @@ -4639,6 +4639,7 @@ save-cap0_trig_cntl = 0; save-cap1_trig_cntl = 0; save-bus_cntl = info-BusCntl; +save-gen_int_cntl = info-gen_int_cntl; /* * If bursts are enabled, turn on discards * Radeon doesn't have write bursts Michel, what are the consequences of removing this? Well, the idea of this line is to preserve the interrupts the chip generates over mode changes. What does this get set to before the lockup? Something else than during the first server generation? Thanks for tracking this down Keith, I'd love to dive into this, but I'm supposed to be learning for the exam tomorrow. :( I'll hopefully find the time during the weekend at the latest. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: radeon dri xserver recycle lockup
On Mit, 2003-03-12 at 12:29, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote:
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25 -1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0;
save-cap1_trig_cntl = 0;
save-bus_cntl = info-BusCntl;
+save-gen_int_cntl = info-gen_int_cntl;
/*
* If bursts are enabled, turn on discards
* Radeon doesn't have write bursts
Michel, what are the consequences of removing this?
Hmm. Things are slightly compilcated by the fact that this code has been
reworked since this change was made. To get rid of the lockup on the dri
trunk I have to use the attached patch. It's a little heavy handed...
It basically disables interrupts AFAICS.
No - they still seem to work, which makes sense as they are turned on in the
drm module (which also writes to RADEON_GEN_INT_CONTROL).
But they stop working when you switch modes, don't they?
Does this patch (against the XFree86 trunk) help instead?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v
retrieving revision 1.32
diff -p -u -r1.32 radeon_dri.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2003/02/19 09:17:30 1.32
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2003/03/12 13:08:30
@@ -1585,6 +1585,7 @@ void RADEONDRICloseScreen(ScreenPtr pScr
if (info-irq) {
drmCtlUninstHandler(info-drmFD);
info-irq = 0;
+ info-ModeReg.gen_int_cntl = 0;
}
/* De-allocate vertex buffers */
Re: [Dri-devel] drm-filp-0-1-branch and radeon
OK, now that the recycle lockup has been found fixed, I don't see any problems with this patch. Has anyone got any objections to merging it to the trunk? Eric, do you think this will be impossible to support on bsd? It seems to fix some fundamental braino's in the orignal drm... Keith --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
Am Dienstag, 11. März 2003 11:06 schrieb Keith Whitwell: Charl P. Botha wrote: On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Can you summarize the problems that remain? I'm seeing all manner of bad behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of 'holds heavyweight lock' errors, the occasional lockup. It's a mess... Ack. VTK TaskParallelismWithPorts: all (inner) triangles of the isosurface are not (wrong) colored = R200_NO_TCL fix it VTK/bin ./TaskParallelism TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion `vb.context == ctx' failed. Abbruch (core dumped) !!! Screen corruption in some upper lines !!! Redraw fix it. VTK/bin ./TaskParallelism TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion `vb.context == ctx' failed. Abbruch (core dumped) Reading symbols from /usr/X11R6/lib/modules/dri/r200_dri.so...done. Loaded symbols for /usr/X11R6/lib/modules/dri/r200_dri.so #0 0x41427701 in kill () from /lib/libc.so.6 (gdb) bt #0 0x41427701 in kill () from /lib/libc.so.6 #1 0x412b589a in pthread_kill () from /lib/libpthread.so.0 #2 0x412b5d92 in raise () from /lib/libpthread.so.0 #3 0x41428a23 in abort () from /lib/libc.so.6 #4 0x414220ea in __assert_fail () from /lib/libc.so.6 #5 0x4188c845 in r200VtxFmtFlushVertices () from /usr/X11R6/lib/modules/dri/r200_dri.so #6 0x401b1950 in vtkOpenGLRenderWindow::SetPixelData () from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so #7 0x40048d40 in vtkCompositeManager::Composite () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #8 0x40047de9 in vtkCompositeManager::EndRender () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #9 0x40046379 in vtkCompositeManagerEndRender () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #10 0x410f7afd in vtkCallbackCommand::Execute () from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so #11 0x4113c5ea in vtkSubjectHelper::InvokeEvent () from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so #12 0x4113c962 in vtkObject::InvokeEvent () from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so #13 0x4017ff11 in vtkRenderWindow::Render () from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so #14 0x401bb3da in vtkXOpenGLRenderWindow::Render () from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so #15 0x401a74de in vtkXRenderWindowInteractorCallback () from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so #16 0x40d55f3e in XtDispatchEventToWidget () from /usr/X11R6/lib/libXt.so.6 #17 0x40d56832 in _XtDefaultDispatcher () from /usr/X11R6/lib/libXt.so.6 #18 0x40d56bb9 in XtDispatchEvent () from /usr/X11R6/lib/libXt.so.6 #19 0x401a6852 in vtkXRenderWindowInteractor::Start () from /opt/VTK/V4.0/VTK/lib/libvtkRendering.so #20 0x40047658 in vtkCompositeManager::StartInteractor () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #21 0x08049670 in process () #22 0x4006e964 in vtkThreadedController::Start () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #23 0x4006e7c0 in vtkThreadedController::vtkThreadedControllerStart () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #24 0x41139be1 in vtkMultiThreader::SingleMethodExecute () from /opt/VTK/V4.0/VTK/lib/libvtkCommon.so #25 0x4006eb40 in vtkThreadedController::SingleMethodExecute () from /opt/VTK/V4.0/VTK/lib/libvtkParallel.so #26 0x08049716 in main () #27 0x414177d1 in __libc_start_main () from /lib/libc.so.6 (gdb) info registers eax0x0 0 ecx0x6 6 edx0x412c127c 1093407356 ebx0x14d2 5330 esp0xbfffe998 0xbfffe998 ebp0xbfffe9b4 0xbfffe9b4 esi0x14d2 5330 edi0x412ba8c0 1093380288 eip0x41427701 0x41427701 eflags 0x202514 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x2b 43 gs 0x2b 43 fctrl 0x37f895 fstat 0x0 0 ftag 0x0 0 fiseg 0x0 0 fioff 0x0 0 foseg 0x1f80 8064 fooff 0x0 0 fop0x0 0 xmm0 0x xmm1 0x xmm2
Re: [Dri-devel] reproducible VTK + DRI breakage
Am Dienstag, 11. März 2003 18:29 schrieb Michel Dänzer: RADEON_NO_VTXFMT=1 NO, not for me. VTK/bin ./TaskParallelism Speicherschutzverletzung (core dumped) DRI CVS taken on 10.03.2003. -Dieter --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm-filp-0-1-branch and radeon
On Wed, Mar 12, 2003 at 01:57:03PM +, Keith Whitwell wrote: OK, now that the recycle lockup has been found fixed, I don't see any problems with this patch. Has anyone got any objections to merging it to the trunk? FW(L)IW, you have my vote. As mentioned earlier, your filp work fixes all kinds of nasty problems on my setup. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: mesa-4-0-4-branch)
Keith Whitwell [EMAIL PROTECTED] wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/ Changes by: [EMAIL PROTECTED] 03/03/12 05:54:45 Log message: Fix recycle lockup (Michel Danzer) Modified files: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/: Tag: mesa-4-0-4-branch radeon_dri.c Not bad - this fixes all crash scenarios I had with my Radeon. This makes not only FlightGear run stable but also fixes the freeze with 'Solace' (wildly moving the output window over the screen). Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] patch for function naming consistency
I just noticed that in drivers/ati, every single function related to DRI
initialization,etc. is named RADEONDRIXxxxYyyy ... except
RADEONPreInitDRI()
Here's a patch to fix that, and R128PreInitDRI()
I had to make the patch by hand this time, since cvs seems down or
something.
--- /tmp/radeon_driver.c2003-03-12 10:09:06.08000 -0800
+++ radeon_driver.c 2003-03-12 10:10:05.60004 -0800
@@ -2859,7 +2859,7 @@
}
#ifdef XF86DRI
-static Bool RADEONPreInitDRI(ScrnInfoPtr pScrn)
+static Bool RADEONDRIPreInit(ScrnInfoPtr pScrn)
{
RADEONInfoPtr info = RADEONPTR(pScrn);
@@ -3182,7 +3182,7 @@
if (!RADEONPreInitAccel(pScrn)) goto fail;
#ifdef XF86DRI
-if (!RADEONPreInitDRI(pScrn))goto fail;
+if (!RADEONDRIPreInit(pScrn))goto fail;
#endif
/* Free the video bios (if applicable) */
--- /tmp/r128_driver.c 2003-03-12 10:09:06.09000 -0800
+++ r128_driver.c 2003-03-12 10:09:33.420044000 -0800
@@ -1664,7 +1664,7 @@
}
#ifdef XF86DRI
-static Bool R128PreInitDRI(ScrnInfoPtr pScrn)
+static Bool R128DRIPreInit(ScrnInfoPtr pScrn)
{
R128InfoPtr info = R128PTR(pScrn);
@@ -1885,7 +1885,7 @@
if (!R128PreInitAccel(pScrn)) goto fail;
#ifdef XF86DRI
-if (!R128PreInitDRI(pScrn))goto fail;
+if (!R128DRIPreInit(pScrn))goto fail;
#endif
/* Free the video bios (if applicable) */
Re: [Dri-devel] drmScatterGatherAlloc missing from docs
Philip Brown wrote: http://dri.sourceforge.net/doc/drm_low_level.html should be updated with a functional description of drmScatterGatherAlloc() [and probably a few other drmXXXYYY() routines that have appeared since 1999 ;-) ] I'm talking from my hat a bit here, but how hard would it be to mark up the source files appropriately so that we could automatically generate up-to-date documentation using doxygen? I know the DRM sources are different (esp. the templatized versions), so it may not be as straight forward as with the user-mode code. Thoughts? --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] reproducible VTK + DRI breakage
Am Mittwoch, 12. März 2003 16:42 schrieb Dieter Nützel: Am Dienstag, 11. März 2003 11:06 schrieb Keith Whitwell: Charl P. Botha wrote: On Tue, 2003-03-11 at 10:16, Keith Whitwell wrote: Charl P. Botha wrote: In anycase, if you have wxPython and VTK with working Python wrappings installed, please run the attached example. Manipulate the 3D cone in both windows and then close the one window. Manipulating the remaining 3D cone for a second or two should result in a drmCmdBuffer: -22 application crash. You'll be pleased to hear that I've now got access to a HT enabled box with which I can reproduce some or all of the problems you guys have been seeing with threaded apps. Hopefully there'll be some fixes soon. Hmmm, new toys to play with! Thanks for thinking about us. ;) Keith, your filp-1 patch completely killed the drmCmdBuffer: -22 bug on my box. I have not been able to reproduce it since with VTK or synthetic tests. Can you summarize the problems that remain? I'm seeing all manner of bad behaviour with glthreads - lots of GL_INVALID_OPERATION errors, lots of 'holds heavyweight lock' errors, the occasional lockup. It's a mess... Ack. VTK TaskParallelismWithPorts: all (inner) triangles of the isosurface are not (wrong) colored = R200_NO_TCL fix it VTK/bin ./TaskParallelism TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion `vb.context == ctx' failed. Abbruch (core dumped) !!! Screen corruption in some upper lines !!! Redraw fix it. VTK/bin ./TaskParallelism TaskParallelism: r200_vtxfmt.c:949: r200VtxFmtFlushVertices: Assertion `vb.context == ctx' failed. Abbruch (core dumped) Still there, even after latest pull (12.03.2003). -Dieter --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] possible memleak in drivers/char/drm/drm_drv.h::drm_init() ?
Hello! Seems this is right list/person to post this. I am looking at ./drivers/char/drm/drm_drv.h::drm_init() (latest 2.4), and it seems there is a memleak on error exit path. If DRM(stub_register)(DRIVER_NAME, DRM(fops),dev) fails, DRM(device) and DRM(minor) memory areas are not freed before exit. Is this looking real? Bte, Oleg --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: possible memleak in drivers/char/drm/drm_drv.h::drm_init() ?
On Wed, Mar 12, 2003 at 11:34:08PM +0300, Oleg Drokin wrote: Hello! Seems this is right list/person to post this. I am looking at ./drivers/char/drm/drm_drv.h::drm_init() (latest 2.4), and it seems there is a memleak on error exit path. If DRM(stub_register)(DRIVER_NAME, DRM(fops),dev) fails, DRM(device) and DRM(minor) memory areas are not freed before exit. Is this looking real? I don't know. The drm code is intentionally obsfucated. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
On Mit, 2003-03-12 at 19:15, Philip Brown wrote: I just noticed that in drivers/ati, every single function related to DRI initialization,etc. is named RADEONDRIXxxxYyyy ... except RADEONPreInitDRI() Here's a patch to fix that, and R128PreInitDRI() This change doesn't seem obvious to me; the RADEONDRIxxx() functions are in radeon_dri.c and directly related to the DRI, whereas RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in radeon_driver.c and mainly processes the DRI related driver options. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote: On Mit, 2003-03-12 at 19:15, Philip Brown wrote: I just noticed that in drivers/ati, every single function related to DRI initialization,etc. is named RADEONDRIXxxxYyyy ... except RADEONPreInitDRI() Here's a patch to fix that, and R128PreInitDRI() This change doesn't seem obvious to me; the RADEONDRIxxx() functions are in radeon_dri.c and directly related to the DRI, whereas RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in radeon_driver.c Maybe it belongs in radeon_dri.c, then? Coincidence of current location, should not be a reason for avoiding logical naming and grouping. If you like, I'll submit patches for doing the move AND rename. and mainly processes the DRI related driver options. Consistency is a Good Thing. It is nice and easy to do grep RADEONDRI tags to get a list of all DRI-related functions for radeon. [The fact that you can get more complicated with grep RADEON | grep DRI should not excuse the lack of consistency in naming] So RADEONPreInitDRI() doesnt actually do any rendering; So what. It is still DRI related. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
Philip Brown wrote: On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote: This change doesn't seem obvious to me; the RADEONDRIxxx() functions are in radeon_dri.c and directly related to the DRI, whereas RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in radeon_driver.c Maybe it belongs in radeon_dri.c, then? Coincidence of current location, should not be a reason for avoiding logical naming and grouping. If you like, I'll submit patches for doing the move AND rename. [snip] So RADEONPreInitDRI() doesnt actually do any rendering; So what. It is still DRI related. I think Michel is saying that this name is more consistent because this function groups more closely with the other RADEONPreInit functions than with the other RADEONDRI functions. I guess it's six of one, half-a-dozen of the other... --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
On Mit, 2003-03-12 at 23:14, Philip Brown wrote: On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote: On Mit, 2003-03-12 at 19:15, Philip Brown wrote: I just noticed that in drivers/ati, every single function related to DRI initialization,etc. is named RADEONDRIXxxxYyyy ... except RADEONPreInitDRI() Here's a patch to fix that, and R128PreInitDRI() This change doesn't seem obvious to me; the RADEONDRIxxx() functions are in radeon_dri.c and directly related to the DRI, whereas RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in radeon_driver.c Maybe it belongs in radeon_dri.c, then? Coincidence of current location, should not be a reason for avoiding logical naming and grouping. If you like, I'll submit patches for doing the move AND rename. and mainly processes the DRI related driver options. Consistency is a Good Thing. Sure, but there are two conflicting kinds of consistency here: * DRI related functions are called RADEONDRIxxx() * functions called from RADEONPreInit() are called RADEONPreInitxxx() To me, RADEONPreInitDRI() seems to belong in the latter group rather (option processing is a typical PreInit() job), at least I don't see an urgent reason why it absolutely has to be in the former. That said, I can live with it either way. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
Philip Brown wrote: On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote: On Mit, 2003-03-12 at 19:15, Philip Brown wrote: I just noticed that in drivers/ati, every single function related to DRI initialization,etc. is named RADEONDRIXxxxYyyy ... except RADEONPreInitDRI() Here's a patch to fix that, and R128PreInitDRI() This change doesn't seem obvious to me; the RADEONDRIxxx() functions are in radeon_dri.c and directly related to the DRI, whereas RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in radeon_driver.c Maybe it belongs in radeon_dri.c, then? Coincidence of current location, should not be a reason for avoiding logical naming and grouping. If you like, I'll submit patches for doing the move AND rename. and mainly processes the DRI related driver options. Consistency is a Good Thing. It is nice and easy to do grep RADEONDRI tags to get a list of all DRI-related functions for radeon. [The fact that you can get more complicated with grep RADEON | grep DRI should not excuse the lack of consistency in naming] So RADEONPreInitDRI() doesnt actually do any rendering; So what. It is still DRI related. I agree w/ Ian. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
Jens Owen wrote: Philip Brown wrote: On Wed, Mar 12, 2003 at 10:21:17PM +0100, Michel Dänzer wrote: On Mit, 2003-03-12 at 19:15, Philip Brown wrote: I just noticed that in drivers/ati, every single function related to DRI initialization,etc. is named RADEONDRIXxxxYyyy ... except RADEONPreInitDRI() Here's a patch to fix that, and R128PreInitDRI() This change doesn't seem obvious to me; the RADEONDRIxxx() functions are in radeon_dri.c and directly related to the DRI, whereas RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in radeon_driver.c Maybe it belongs in radeon_dri.c, then? Coincidence of current location, should not be a reason for avoiding logical naming and grouping. If you like, I'll submit patches for doing the move AND rename. and mainly processes the DRI related driver options. Consistency is a Good Thing. It is nice and easy to do grep RADEONDRI tags to get a list of all DRI-related functions for radeon. [The fact that you can get more complicated with grep RADEON | grep DRI should not excuse the lack of consistency in naming] So RADEONPreInitDRI() doesnt actually do any rendering; So what. It is still DRI related. I agree w/ Ian. I mean Michael... -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: patch for function naming consistency
On Wed, 12 Mar 2003, Philip Brown wrote: I just noticed that in drivers/ati, every single function related to DRI initialization,etc. is named RADEONDRIXxxxYyyy ... except RADEONPreInitDRI() Here's a patch to fix that, and R128PreInitDRI() This change doesn't seem obvious to me; the RADEONDRIxxx() functions are in radeon_dri.c and directly related to the DRI, whereas RADEONPreInitDRI() (along with other RADEONPreInitxxx() functions) is in radeon_driver.c Maybe it belongs in radeon_dri.c, then? Coincidence of current location, should not be a reason for avoiding logical naming and grouping. If you like, I'll submit patches for doing the move AND rename. and mainly processes the DRI related driver options. Consistency is a Good Thing. It is nice and easy to do grep RADEONDRI tags to get a list of all DRI-related functions for radeon. [The fact that you can get more complicated with grep RADEON | grep DRI should not excuse the lack of consistency in naming] So RADEONPreInitDRI() doesnt actually do any rendering; So what. It is still DRI related. I think you're looking at function naming from a point of view of what all functions contain the 3 letters 'DRI' grouped together in the function name and wanting to change the name of RADEONPreInitDRI() because it doesn't match the others, rather than looking at the logical grouping of where the function exists now. I agree with Michel and think it is properly named as is, and in the proper location. What is the function classification based on? Is it based on performing a PreInit operation, or is it a DRI function that does preinit? I see it as the former as it is called from RadeonPreInit. IMHO, the names of functions and the file they are located in should be based on the functionality that they are providing, and should be grouped based on similar functionality and not based on similarities in portions of their names. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: patch for function naming consistency
On Wed, Mar 12, 2003 at 06:26:44PM -0500, Mike A. Harris wrote: [] IMHO, the names of functions and the file they are located in should be based on the functionality that they are providing, and should be grouped based on similar functionality and not based on similarities in portions of their names. I agree with that sentiment 100%. Which is why when I see the function in question, as providing a DRI-specific function that does not *exist* if DRI is not compiled in, it seems straightforward to me that as such, it should have a DRI-oriented name, and belongs in radeon_dri.c --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: patch for function naming consistency
On Wed, 12 Mar 2003, Philip Brown wrote: [] IMHO, the names of functions and the file they are located in should be based on the functionality that they are providing, and should be grouped based on similar functionality and not based on similarities in portions of their names. I agree with that sentiment 100%. Which is why when I see the function in question, as providing a DRI-specific function that does not *exist* if DRI is not compiled in, it seems straightforward to me that as such, it should have a DRI-oriented name, and belongs in radeon_dri.c With several people in disagreement with you though, I guess it might be a decision perhaps that should fall more into the lap of the driver maintainer or project lead or somesuch. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: patch for function naming consistency
Mike A. Harris wrote: On Wed, 12 Mar 2003, Philip Brown wrote: [] IMHO, the names of functions and the file they are located in should be based on the functionality that they are providing, and should be grouped based on similar functionality and not based on similarities in portions of their names. I agree with that sentiment 100%. Which is why when I see the function in question, as providing a DRI-specific function that does not *exist* if DRI is not compiled in, it seems straightforward to me that as such, it should have a DRI-oriented name, and belongs in radeon_dri.c With several people in disagreement with you though, I guess it might be a decision perhaps that should fall more into the lap of the driver maintainer or project lead or somesuch. Well, I didn't have much to do with this code when it was written, but I'm happy for it to stay where it is and as it is named for now. If someone wanted to take on a bigger task of comprehensively spring-cleaning the radeon 2d driver, that might be interesting, but renaming moving that one function won't do anything to make the driver easier to navigate. Keith --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
On Wed, Mar 12, 2003 at 11:56:42PM +, Keith Whitwell wrote: Well, I didn't have much to do with this code when it was written, but I'm happy for it to stay where it is and as it is named for now. If someone wanted to take on a bigger task of comprehensively spring-cleaning the radeon 2d driver, that might be interesting, but renaming moving that one function won't do anything to make the driver easier to navigate. A journey of 1000 miles begins with a single step --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: dri_driver_features.phtml dri_radeon_features.html
On Tue, 11 Mar 2003 18:34:16 -0700 Brian Paul [EMAIL PROTECTED] wrote: Smitty wrote: Hi Brian In light of your well maintained: http://dri.sourceforge.net/doc/dri_driver_features.phtml I think it's about time that: http://dri.sourceforge.net/doc/dri_radeon_features.html crawled into a hole and died. Do you want to pull in anything from this page or can I get rid of it (permanently)? As far as I'm concerned you can remove the later. It goes into more detail than I think is necessary. Perhaps, its got until the end of the week, then it's gone, if anyone wants it, some of the info in it they'd better grab it before then. The status page seems redundant too: http://dri.sourceforge.net/dri_status.phtml When one clicks on Status on the left (or page header) I think the new table page should come up. Disagree here, the dri_drivers_page won't fit in there, the status page links to some info / websites, that would have to make its way into driver_features first. But I do think that better billing can be given to driver_features on dri_status. cheers Liam --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: dri driver features page - radeon_naming
The DRI website contains a few other inaccuracies about ATI's Radeon video hardware. Nothing mission critical, but it is incorrect: http://dri.sourceforge.net/doc/radeon_naming.html Radeon VE a.k.a Radeon 7000, is not R100, it is RV100. So what does this mean for users of DRI? Another thing missing is the original Radeon LE, which was made by a third party in the Asian region. This card is claimed to have no TCL unit, however it is a Radeon QD and is identical to any other Radeon R100 cards (which are also QD), and does in fact have a TCL unit. I believe the BIOS and/or Windows drivers for this card simply disable the TCL unit, but since the chip is a QD, like all other QD boards, it has a TCL unit. It's not missing: * Radeon DDR / LE Hidden right in front of you. g The only difference I know of between this board, and the real Radeon 7200 aka Radeon 64 DDR, is the type and speed of the memory, and that the TCL unit is somehow disabled via software. 7200 is SDR. * Radeon 8700 (FireGL) It's really called FireGL 8700 and FireGL 8800, and both are as stated on the page Radeon R200 based chips, but neither was ever marketed as Radeon 8700 or Radeon 8800, so that will just confuse anyone reading it. It is more correct to list this card the way that ATI names it, under it's FireGL name. Done. At the bottom of the page: * 7X00 denotes a R100 based card. Should be removed, as Radeon 7000, is RV100, not R100. We are in disagreement about the relevance of the V. Also, ATI just released 3 new cards this week, none of which are supported in X yet, but which are likely incredibly easy to add support for once the PCI IDs are known. The Radeon 9200 Pro, Radeon 9600 Pro, and Radeon 9800 Pro Also non-Pro versions of these cards. Radeon 9200 Pro == RV280 Only problem is that we're beginning to embrace ATI's marchitecture, eg a RV280 is a RV250 on a card with AGP 8x. What is the point of this card? From what spec's I can gather it's going to be smacked around by the recently renamed R9100, so much for numbering schemes. Radeon 9600 Pro == R300 RV350 Radeon 9800 Pro == R300 R350 Just thought I'd post this to help improve the accuracy and completeness of that Radeon page. It is certainly becoming accurately and completely confusing. Someone over at ATI is playing silly buggers with a once understandable numbering scheme. I think their product line is becoming too large in an attempt to achieve greater market segmentation. I'm trying to strike a balance between keeping it simple and providing all pertinent information. Liam it depends --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri driver features page - website in CVS
PS: Editing files like this makes me kind of nervous, we should really work out a way to handle the website in CVS. What's the difficulty in having it in CVS? it's extremely trivial to set up, you just tell the web server to cvs up from the repository every few hours or so. The website as a whole is rather large, although it is now a heck of a lot smaller after I did some major house cleaning in the last month. These spring to mind: res/ snapshots/ I'm interested in what you say about putting the website in CVS as it should make it easier for developers, who use CVS all the time. But if I'm uploading / editing files on the webserver how is CVS going to remain synced with my newest changes? I'd rather not use CVS myself just for the website, when I mess up a single character I just ssh onto the webserver and use vi to change it. Also when something is being considered I like to test it / play with and update a page repeatedly while hitting the refresh button. I tweak the page like this because many pages have their headers / footers / style sheets added on the server via PHP, and so look very different when they are actually served up. When it's right I .tar.gz and download it, to sync my local copy up with the active copy. All very useful. I'm not a CVS expert so I don't know if you can keep all this functionality alive. Liam it depends --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] drm-filp-0-1-branch and radeon
On Wed, 2003-03-12 at 05:57, Keith Whitwell wrote: OK, now that the recycle lockup has been found fixed, I don't see any problems with this patch. Has anyone got any objections to merging it to the trunk? Eric, do you think this will be impossible to support on bsd? It seems to fix some fundamental braino's in the orignal drm... It's the second thing on my list, after some mopup after the XFree86 4.3.0 update. I haven't looked at it seriously enough yet. Please give me a few days to get it at least building again on BSD. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page - website in CVS
On Mit, 2003-03-12 at 23:15, Smitty wrote: PS: Editing files like this makes me kind of nervous, we should really work out a way to handle the website in CVS. What's the difficulty in having it in CVS? it's extremely trivial to set up, you just tell the web server to cvs up from the repository every few hours or so. The website as a whole is rather large, We don't need to put everything into CVS right away, but the way several people are editing the same files right now is dangerous. I'd rather not use CVS myself just for the website, when I mess up a single character I just ssh onto the webserver and use vi to change it. Also when something is being considered I like to test it / play with and update a page repeatedly while hitting the refresh button. You can still do that, you just do a cvs commit when you're done. Ideally though, you'd only make changes in your private checkout, commit when you're done and then bring the public site up to date with cvs up (which we might be able to automate somehow). When it's right I .tar.gz and download it, to sync my local copy up with the active copy. All very useful. I'm not a CVS expert so I don't know if you can keep all this functionality alive. Of course. :) You're basically emulating parts of the functionality of CVS with other tools. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] AMD x86-64
http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html When AMD's engineers started looking for legacy x86 features to jettison, the first thing to go was the segmented memory model. Programs written to the x86-64 ISA will use a flat, 64-bit virtual address space. Furthermore, legacy x86 applications running in long mode's compatibility sub-mode must run in protected mode. Support for real mode and virtual-8086 mode are absent in long mode and available only in legacy mode. This isn't too much of a hassle, though, since, except for a few fairly old legacy applications, modern x86 apps use protected mode. - So if the x86-64 is getting rid of real mode when running a 64b OS, how is XFree going to make those nasty old vm86 INT 10 calls for things like getting DDC and resetting secondary adapters? = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: patch for function naming consistency
On Wed, 12 Mar 2003, Keith Whitwell wrote: With several people in disagreement with you though, I guess it might be a decision perhaps that should fall more into the lap of the driver maintainer or project lead or somesuch. Well, I didn't have much to do with this code when it was written, but I'm happy for it to stay where it is and as it is named for now. If someone wanted to take on a bigger task of comprehensively spring-cleaning the radeon 2d driver, that might be interesting, but renaming moving that one function won't do anything to make the driver easier to navigate. Agreed. Also, there are IMHO large enough portions of code that are common to both the r128 and radeon driver at least, which could be moved to a common shared file. Unless it's objected to, I'll be investigating something like that in the future. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
On Thu, 2003-03-13 at 00:20, Philip Brown wrote: On Wed, Mar 12, 2003 at 11:56:42PM +, Keith Whitwell wrote: Well, I didn't have much to do with this code when it was written, but I'm happy for it to stay where it is and as it is named for now. If someone wanted to take on a bigger task of comprehensively spring-cleaning the radeon 2d driver, that might be interesting, but renaming moving that one function won't do anything to make the driver easier to navigate. A journey of 1000 miles begins with a single step But not if that step is over a cliff, onto a landmine or down a hole... --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: dri driver features page - radeon_naming
On Thu, 13 Mar 2003 00:15:41 +0200 Smitty [EMAIL PROTECTED] wrote: 7200 aka Radeon 64 DDR, is the type and speed of the memory, and that the TCL unit is somehow disabled via software. 7200 is SDR. You sure about that? My Radeon DDR VIVO identified itself (under windows) as a 7200... --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] AMD x86-64
On Wed, 12 Mar 2003, Jon Smirl wrote: So if the x86-64 is getting rid of real mode when running a 64b OS, how is XFree going to make those nasty old vm86 INT 10 calls for things like getting DDC and resetting secondary adapters? It contains an emulator for real-mode 8086. How do you think they do it on other platforms with AGP/PCI but not x86? ;) -Peter Of course, I'm not unbiased, but in my humble opinion, I've gotten close to something that I can be really proud of. -- Knuth on The Art of Computer Programming. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] AMD x86-64
--- Peter \Firefly\ Lund [EMAIL PROTECTED] wrote: On Wed, 12 Mar 2003, Jon Smirl wrote: So if the x86-64 is getting rid of real mode when running a 64b OS, how is XFree going to make those nasty old vm86 INT 10 calls for things like getting DDC and resetting secondary adapters? It contains an emulator for real-mode 8086. How do you think they do it on other platforms with AGP/PCI but not x86? ;) And people wonder why XFree is so big -Peter = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] patch for function naming consistency
On 13 Mar 2003 03:24:10 + Alan Cox [EMAIL PROTECTED] wrote: A journey of 1000 miles begins with a single step But not if that step is over a cliff, onto a landmine or down a hole... I like that ;-) --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Re: dri driver features page - radeon_naming
On Thu, 13 Mar 2003, Ian Molton wrote: 7200 aka Radeon 64 DDR, is the type and speed of the memory, and that the TCL unit is somehow disabled via software. 7200 is SDR. You sure about that? My Radeon DDR VIVO identified itself (under windows) as a 7200... The original Radeon R100 chip was released in various products with different memory configurations. I believe all 4 of the following were shipped products: Radeon 32 SDR Radeon 32 DDR Radeon 64 SDR Radeon 64 DDR Also VIVO and AiW variants of the above. Every single board I've personally encountered all used the same Radeon chip, which is PCI ID: 1002:5144 aka. Radeon R100 QD. Some of these board variants were later discontinued, while others were rebranded as Radeon 7200. The Radeon 7200 is merely a new cosmetic name for the existing boards, however the chips are the same. Depending on how new or old your Windows (or XFree86) drivers are, any of the above cards will be detected as either Radeon QD or Radeon 7200. They are all one and the same however, just with different memory configurations. The Radeon QD chip supports TCL in hardware, and it works in XFree86 using the Radeon TCL code on all of them (since they're all the same chip). There was also another card which was called ATI Radeon LE which was made by 3rd party for the Asian market (according to an FAQ which may or may not still be on ATI's website). This card was a slower clocked card, which was intended as a lower priced Light Edition for that particular market and it is claimed to not have the hardware TCL unit. However, the card identifies itself also as a Radeon QD which we of course know does have the hardware TCL unit. I have never actually used or seen one of these in person, but I do know people who have had them, and have used the TCL features on the hardware in Windows (aparently hacking some registry settings), although I don't know anyone whom has used TCL on them in Linux. I presume that the card's BIOS disables the TCL unit (or perhaps just doesn't enable it) at POST, and so the Windows drivers aren't able to use it - or perhaps it is entirely a driver/registry thing. Not entirely sure, as I've never personally touched one. I do know however that all boards containing the Radeon QD chip do in fact have a useable TCL unit on them. Hope this helps to clarify the R100 line a bit. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Fw: PROTECT YOUR INFORMATION AND YOUR COMPUTER! ib izlkec
Norton AntiVirus 2003 Sale 59.95 only $ 29.99 Limited Time Downloadable Version Simple and powerful, Norton AntiVirus 2003 protects your PC against viruses--and it covers e-mail and instant messaging, too. The program's clear and simple interface shows you what you're protected against, how up-to-date your virus definitions are, and when you last checked your whole system Installation is simple: you can accept all the defaults without worry, and you'll be prompted to go online and get up-to-date definitions as soon as you install. If a virus is found, the software will try to automatically repair the file. In addition to looking for known viruses, the Norton AntiVirus Bloodhound feature tries to spot new viruses and worms by their behavior. AntiVirus 2003 also checks for viruses in files you download from the Web, in e-mail, and now in instant messages. If you use MSN Messenger you'll need to reboot; other messaging tools are protected straight away. With e-mail, Norton AntiVirus 2003 can check incoming and outgoing messages and files in POP3 clients like Outlook Express. While AntiVirus 2002 would only stop you from getting infected by an e-mail worm, this version stops you from passing the infection on to others Click here to protect your computer To Be taken off our mailing list click here ulgagfm hzuehdoirjajetyylworrucpv m bpntnfsvtj sgjcapxxclhgbjf d
Re: [Dri-devel] Re: radeon dri xserver recycle lockup
Michel Dänzer wrote:
On Mit, 2003-03-12 at 12:29, Keith Whitwell wrote:
Michel Dänzer wrote:
On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote:
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25 -1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0;
save-cap1_trig_cntl = 0;
save-bus_cntl = info-BusCntl;
+save-gen_int_cntl = info-gen_int_cntl;
/*
* If bursts are enabled, turn on discards
* Radeon doesn't have write bursts
Michel, what are the consequences of removing this?
Hmm. Things are slightly compilcated by the fact that this code has been
reworked since this change was made. To get rid of the lockup on the dri
trunk I have to use the attached patch. It's a little heavy handed...
It basically disables interrupts AFAICS.
No - they still seem to work, which makes sense as they are turned on in the
drm module (which also writes to RADEON_GEN_INT_CONTROL).
But they stop working when you switch modes, don't they?
Does this patch (against the XFree86 trunk) help instead?
Index: programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c
===
RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v
retrieving revision 1.32
diff -p -u -r1.32 radeon_dri.c
--- programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2003/02/19 09:17:30 1.32
+++ programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c 2003/03/12 13:08:30
@@ -1585,6 +1585,7 @@ void RADEONDRICloseScreen(ScreenPtr pScr
if (info-irq) {
drmCtlUninstHandler(info-drmFD);
info-irq = 0;
+ info-ModeReg.gen_int_cntl = 0;
}
/* De-allocate vertex buffers */
Yes, committed.
Keith
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] radeon dri xserver recycle lockup
In fact the lockup comes down to this one line:
--- radeon_driver.c28 Oct 2002 02:21:14 -1.44
+++ radeon_driver.c29 Oct 2002 13:49:25 -1.45
@@ -4639,6 +4639,7 @@
save-cap0_trig_cntl = 0;
save-cap1_trig_cntl = 0;
save-bus_cntl = info-BusCntl;
+save-gen_int_cntl = info-gen_int_cntl;
/*
* If bursts are enabled, turn on discards
* Radeon doesn't have write bursts
Michel, what are the consequences of removing this?
Hmm. Things are slightly compilcated by the fact that this code has been
reworked since this change was made. To get rid of the lockup on the dri
trunk I have to use the attached patch. It's a little heavy handed...
Anyone have any better ideas? Otherwise I'm going to commit this here as it
at least it resolves the lockup.
Keith
Index: radeon_dri.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v
retrieving revision 1.44
diff -u -r1.44 radeon_dri.c
--- radeon_dri.c6 Feb 2003 19:13:40 - 1.44
+++ radeon_dri.c12 Mar 2003 10:50:20 -
@@ -1148,7 +1148,7 @@
info-irq = 0;
} else {
unsigned char *RADEONMMIO = info-MMIO;
- info-ModeReg.gen_int_cntl = INREG( RADEON_GEN_INT_CNTL );
+ info-ModeReg.gen_int_cntl = 0; /* INREG( RADEON_GEN_INT_CNTL ); */
}
}
Index: radeon_driver.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.56
diff -u -r1.56 radeon_driver.c
--- radeon_driver.c 25 Jan 2003 22:25:44 - 1.56
+++ radeon_driver.c 12 Mar 2003 10:50:21 -
@@ -4384,7 +4384,7 @@
save-subpic_cntl= INREG(RADEON_SUBPIC_CNTL);
save-viph_control = INREG(RADEON_VIPH_CONTROL);
save-i2c_cntl_1 = INREG(RADEON_I2C_CNTL_1);
-save-gen_int_cntl = INREG(RADEON_GEN_INT_CNTL);
+save-gen_int_cntl = 0; /* INREG(RADEON_GEN_INT_CNTL); */
save-cap0_trig_cntl = INREG(RADEON_CAP0_TRIG_CNTL);
save-cap1_trig_cntl = INREG(RADEON_CAP1_TRIG_CNTL);
save-bus_cntl = INREG(RADEON_BUS_CNTL);
@@ -4400,7 +4400,7 @@
/* Save register for vertical blank interrupts */
if (info-irq) {
- save-gen_int_cntl = INREG(RADEON_GEN_INT_CNTL);
+ save-gen_int_cntl = 0; /* INREG(RADEON_GEN_INT_CNTL); */
}
/* Save registers for page flipping */
Re: [Dri-devel] radeon dri xserver recycle lockup
On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote: In fact the lockup comes down to this one line: --- radeon_driver.c28 Oct 2002 02:21:14 -1.44 +++ radeon_driver.c29 Oct 2002 13:49:25 -1.45 @@ -4639,6 +4639,7 @@ save-cap0_trig_cntl = 0; save-cap1_trig_cntl = 0; save-bus_cntl = info-BusCntl; +save-gen_int_cntl = info-gen_int_cntl; /* * If bursts are enabled, turn on discards * Radeon doesn't have write bursts Michel, what are the consequences of removing this? Hmm. Things are slightly compilcated by the fact that this code has been reworked since this change was made. To get rid of the lockup on the dri trunk I have to use the attached patch. It's a little heavy handed... It basically disables interrupts AFAICS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon dri xserver recycle lockup
Michel Dänzer wrote: On Mit, 2003-03-12 at 11:51, Keith Whitwell wrote: In fact the lockup comes down to this one line: --- radeon_driver.c28 Oct 2002 02:21:14 -1.44 +++ radeon_driver.c29 Oct 2002 13:49:25 -1.45 @@ -4639,6 +4639,7 @@ save-cap0_trig_cntl = 0; save-cap1_trig_cntl = 0; save-bus_cntl = info-BusCntl; +save-gen_int_cntl = info-gen_int_cntl; /* * If bursts are enabled, turn on discards * Radeon doesn't have write bursts Michel, what are the consequences of removing this? Hmm. Things are slightly compilcated by the fact that this code has been reworked since this change was made. To get rid of the lockup on the dri trunk I have to use the attached patch. It's a little heavy handed... It basically disables interrupts AFAICS. No - they still seem to work, which makes sense as they are turned on in the drm module (which also writes to RADEON_GEN_INT_CONTROL). Keith --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
