Re: [Dri-devel] mga-stereo-patch
On Mon, 2002-09-23 at 09:00, Michel Dänzer wrote: I've incorporated this and turned it into a template: http://penguinppc.org/~daenzer/DRI/drm-vblank-template.diff I've put a new one up at http://people.freebsd.org/~anholt/dri/files/framethrottle2.diff which includes MGA support. I'll work on r128 when I get some time again. I may have reversed the IRQ_ACTIVE - IRQ_NR change inadvertently, I/we can change that back. Sleep is my top priority right now. I can't imagine anything but checking for the cause of the IRQ and kicking something off accordingly. The r200 client lib doesn't check for the irq number, but I couldn't figure out what exactly that was being checked for. To see if the IRQ is enabled. Oops, I hadn't realized that the ddx was doing the irq init. Would it be worthwhile to have the vblank-enabling done by clients and refcounted so the interrupts are only coming in when there was a need to track them? Well, I was registering 0.0 - 0.4% cpu utilization for interrupts, so maybe we don't care that much. Also, it seems the driver init macros should be functions. Is there any reason why they aren't? Because they didn't use to do much, or because the oringal pre-templated version of the init functions had those bits of code inlined, so the obvious transformation turned them into macros. There's nothing to stop us calling a function from those macros. DRM(driver_preinstall) etc.? Done. Removed the macros completely. One worry I have with the radeon_irq.c code at the moment is the proliferation of ifdef's for linux vs. freebsd code. I'd like to see this get cleaned up -- if nothing else it's ugly... It's not quite as bad with this patch, still we might want to define DRM_WAKEUP or similar. I need to make that. Perhaps when I get around to looking at the gamma code (the other major user of a future DRM_WAKEUP and friends) again I'll try to fix that up. Or Mach64. Was there a trunk merge to mach64 after the bsd-3-0-0 merge? I should be working on it very soon. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] patch radeon-20020923 hangs xfree4.2 on ati radeon M7
Charl == Charl P Botha [EMAIL PROTECTED] writes: I've just check snapshot radeon-20020924 and same situation. I can run programs except those which create new window. For example: xinit /usr/X11R6/bin/xeyes is fine, when: xinit /usr/X11R6/bin/xterm crashes X server with SIGSEGV. Charl Hi Pere! :) Charl Guys, please search the archives before posting: Charl http://sourceforge.net/mailarchive/forum.php?thread_id=1104106forum_id=7177 Charl -- Charl charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ I just wanted to say that just inserting the two Option strings into my Screen-section didn't solve the problem. I have leeched your binaries and have just copied libxaa.a over my previous one. And it works! Although the installation was a bit of a hassle, thank you all very much! Bye, Adam. -- Adam Duck ([EMAIL PROTECTED]) Bockenheimer Landstr. 135 / Zi. 211 60325 Frankfurt/Main __ A mouse is a device for focussing xterms. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] pageflipping
Alan, Others, I've been thinking again about pageflipping realized I can solve the remaining few problems if I can tweak the behaviour of the 2d driver slightly. At the moment, the 2d driver always draws to buffer zero (the old front buffer), and then at some point in the future, the dirty parts are blitted to buffer one (the old back buffer). However, this can be incorrect in a couple of circumstances, particularly when the dirty regions (or even the drawing itself) overlaps with the 3d window. I think all my problems can be solved if I do two things: 1) always have X draw to the *current* front buffer (buffer zero or buffer one, depending) 2) subtract the 3d window from the dirty regions before blitting to the current back buffer. I can probably figure out 2) without to much effort. For 1), I can adjust the accelerated functions fairly easily to get them to draw to buffer zero/one as appropriate. What about software fallbacks? What value do these use to get a pointer to the framebuffer, and how can I go about changing it? Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] patch radeon-20020923 hangsxfree4.2 on ati radeon M7
On Tue, 2002-09-24 at 11:56, Adam Duck wrote: Charl == Charl P Botha [EMAIL PROTECTED] writes: I've just check snapshot radeon-20020924 and same situation. I can run programs except those which create new window. For example: xinit /usr/X11R6/bin/xeyes is fine, when: xinit /usr/X11R6/bin/xterm crashes X server with SIGSEGV. Charl Hi Pere! :) Charl Guys, please search the archives before posting: Charl http://sourceforge.net/mailarchive/forum.php?thread_id=1104106forum_id=7177 I just wanted to say that just inserting the two Option strings into my Screen-section didn't solve the problem. I have leeched your binaries and have just copied libxaa.a over my previous one. And it works! Although the installation was a bit of a hassle, thank you all Hah clever! I wanted to suggest this as possible workaround, but thought it was too much hassle. So, in short: * install latest snapshot from dri.sf.net * get dri-resume snapshot from http://cpbotha.net/dri_resume.html and extract libxaa.a from it * copy libxaa.a into /usr/X11R6/lib/modules This is of course unless you just use my snapshot which is identical to DRI CVS except that it has some extra code for suspending/resuming that gets activated during switchVTs. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XAA versioning?
On Mon, 2002-09-23 at 19:35, Michel Dänzer wrote: On Mon, 2002-09-23 at 10:20, Alan Hourihane wrote: On Sun, Sep 22, 2002 at 10:33:15 +0200, Michel Dänzer wrote: Several people on IRC reported crashes in the 2D code with the current trunk snapshots. I realized they are due to the TwoPoint acceleration functions depending on XAA changes. How can we handle this, bump the XAA version and disable those functions if it's too old? Indeed. And the new fields need to be at the end of the XAA InfoRec of course. http://penguinppc.org/~daenzer/DRI/radeon-xaa-limits.diff How does this look? That doesn't work of course, trying something else. -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
On Die, 2002-09-24 at 13:11, Keith Whitwell wrote: I've been thinking again about pageflipping realized I can solve the remaining few problems if I can tweak the behaviour of the 2d driver slightly. At the moment, the 2d driver always draws to buffer zero (the old front buffer), and then at some point in the future, the dirty parts are blitted to buffer one (the old back buffer). However, this can be incorrect in a couple of circumstances, particularly when the dirty regions (or even the drawing itself) overlaps with the 3d window. I think all my problems can be solved if I do two things: 1) always have X draw to the *current* front buffer (buffer zero or buffer one, depending) 2) subtract the 3d window from the dirty regions before blitting to the current back buffer. I can probably figure out 2) without to much effort. For 1), I can adjust the accelerated functions fairly easily to get them to draw to buffer zero/one as appropriate. How do you deal with offscreen access? What about software fallbacks? What value do these use to get a pointer to the framebuffer, and how can I go about changing it? It's passed to xxxScreenInit(), and even if there's a single place where it's stored afterwards, I'm not sure relying on that is a good idea. Doesn't 2) alone work? -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Snapshots now being built with gcc 3.2
Hi guys. Yep, vacations ended. I've updated my workstation to the RedHat Linux 7.3.94 beta, which has gcc 3.2. So now forward the snapshots will be built with this version. AFAIK this shouldn't pose any problem to the users since the key issue is that the kernel modules are compiled with the same version of gcc that compiled the kernel, and that still holds true. Strangely, when testing the snapshots scripts with the new setup I noticed that only radeon and r200 drivers are being built on the HEAD (as there is no errors on the build log). Keith, I know you've been merging r200-0-2-branch, so do you know anything about this? The Mach64 development on my side is still on hold. Besides the hassle of returning from vacations, and have a lot of stuff to do, my laptop's hard drive is busted so I've been working at the univeristy were I don't have any Mach64 card near me. Hopefully I should receive a new drive shortly. Jose Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] install.sh bug
On Sat, Aug 31, 2002 at 09:01:16AM -0600, Jens Owen wrote: It looks like there is some type of problem when the GL subdirectory is empty. Here's what the script tries to do when it get's to an empty GL portion of the install. Ok. The problem is at: echo -nGL GLU libraries... cd GL for FILE in * do mv -f $XF86_GL_DIR/$FILE $XF86_GL_DIR/dri-old.$FILE $LOGFILE_TMP; cp -f $FILE $XF86_GL_DIR done The '*' wildcard isn't matched so it's copied verbatim into $FILE actually doing mv -f $XF86_GL_DIR/* $XF86_GL_DIR/dri-old.* $LOGFILE_TMP; Since I don't want to replace a bug for another, what should be the best thing to do in these cases? The alternatives I see are - replacing the * for `ls` - replacing the * for `find` Are there any caveats with any of these, or is there another way to do this? Jose Fonseca + echo -n ' GL GLU libraries...' + cd GL + mv -f /usr/X11R6/lib/libdps.a /usr/X11R6/lib/libdps.so /usr/X11R6/lib/libdps.so.1 /usr/X11R6/lib/libdps.so.1.0 /usr/X11R6/lib/libdpstk.a /usr/X11R6/lib/libdpstk.so /usr/X11R6/lib/libdpstk.so.1 /usr/X11R6/lib/libdpstk.so.1.0 /usr/X11R6/lib/libfntstubs.a /usr/X11R6/lib/libfontenc.a /usr/X11R6/lib/libFS.a /usr/X11R6/lib/libGL.a /usr/X11R6/lib/libGL.so /usr/X11R6/lib/libGL.so.1 /usr/X11R6/lib/libGL.so.1.2 /usr/X11R6/lib/libGLU.a /usr/X11R6/lib/libGLU.so /usr/X11R6/lib/libGLU.so.1 /usr/X11R6/lib/libGLU.so.1.3 /usr/X11R6/lib/libGLw.a /usr/X11R6/lib/libI810XvMC.a /usr/X11R6/lib/libICE.a /usr/X11R6/lib/libICE.so /usr/X11R6/lib/libICE.so.6 /usr/X11R6/lib/libICE.so.6.3 /usr/X11R6/lib/libMagick.a /usr/X11R6/lib/libMagick++.a /usr/X11R6/lib/libMagick.la /usr/X11R6/lib/libMagick++.la /usr/X11R6/lib/libMagick.so /usr/X11R6/lib/libMagick++.so /usr/X11R6/lib/libMagick.so.5 /usr/X11R6/lib/libMagick++.so.5 /usr/X11R6/lib/libMagick.so.5.0.43 /usr/X11R6/lib/libMagick++.so.5.0.43 /usr/X11R6/lib/libMrm.a /usr/X11R6/lib/libMrm.so /usr/X11R6/lib/libMrm.so.1 /usr/X11R6/lib/libMrm.so.1.0.2 /usr/X11R6/lib/libMrm.so.3 /usr/X11R6/lib/libMrm.so.3.0.1 /usr/X11R6/lib/liboldX.a /usr/X11R6/lib/libOSMesa.a /usr/X11R6/lib/libOSMesa.so /usr/X11R6/lib/libOSMesa.so.3 /usr/X11R6/lib/libOSMesa.so.3.3 /usr/X11R6/lib/libpsres.a /usr/X11R6/lib/libpsres.so /usr/X11R6/lib/libpsres.so.1 /usr/X11R6/lib/libpsres.so.1.0 /usr/X11R6/lib/libSM.a /usr/X11R6/lib/libSM.so /usr/X11R6/lib/libSM.so.6 /usr/X11R6/lib/libSM.so.6.0 /usr/X11R6/lib/libUil.a /usr/X11R6/lib/libUil.so /usr/X11R6/lib/libUil.so.1 /usr/X11R6/lib/libUil.so.1.0.2 /usr/X11R6/lib/libUil.so.3 /usr/X11R6/lib/libUil.so.3.0.1 /usr/X11R6/lib/libX11.a /usr/X11R6/lib/libX11.so /usr/X11R6/lib/libX11.so.6 /usr/X11R6/lib/libX11.so.6.2 /usr/X11R6/lib/libXau.a /usr/X11R6/lib/libXaw3d.a /usr/X11R6/lib/libXaw3d.so /usr/X11R6/lib/libXaw3d.so.6 /usr/X11R6/lib/libXaw3d.so.6.1 /usr/X11R6/lib/libXaw3d.so.7 /usr/X11R6/lib/libXaw3d.so.7.0 /usr/X11R6/lib/libXaw.a /usr/X11R6/lib/libXaw.so /usr/X11R6/lib/libXaw.so.6 /usr/X11R6/lib/libXaw.so.6.1 /usr/X11R6/lib/libXaw.so.7 /usr/X11R6/lib/libXaw.so.7.0 /usr/X11R6/lib/libXdmcp.a /usr/X11R6/lib/libXext.a /usr/X11R6/lib/libXext.so /usr/X11R6/lib/libXext.so.6 /usr/X11R6/lib/libXext.so.6.4 /usr/X11R6/lib/libxf86config.a /usr/X11R6/lib/libXfont.a /usr/X11R6/lib/libXfontcache.a /usr/X11R6/lib/libXfont.so /usr/X11R6/lib/libXfont.so.1 /usr/X11R6/lib/libXfont.so.1.4 /usr/X11R6/lib/libXft.a /usr/X11R6/lib/libXft.so /usr/X11R6/lib/libXft.so.1 /usr/X11R6/lib/libXft.so.1.1 /usr/X11R6/lib/libXi.a /usr/X11R6/lib/libXinerama.a /usr/X11R6/lib/libXi.so /usr/X11R6/lib/libXi.so.6 /usr/X11R6/lib/libXi.so.6.0 /usr/X11R6/lib/libxkbfile.a /usr/X11R6/lib/libxkbui.a /usr/X11R6/lib/libXm.a /usr/X11R6/lib/libXm.so /usr/X11R6/lib/libXm.so.1 /usr/X11R6/lib/libXm.so.1.0.2 /usr/X11R6/lib/libXm.so.3 /usr/X11R6/lib/libXm.so.3.0.1 /usr/X11R6/lib/libXmu.a /usr/X11R6/lib/libXmu.so /usr/X11R6/lib/libXmu.so.6 /usr/X11R6/lib/libXmu.so.6.2 /usr/X11R6/lib/libXmuu.a /usr/X11R6/lib/libXmuu.so /usr/X11R6/lib/libXmuu.so.1 /usr/X11R6/lib/libXmuu.so.1.0 /usr/X11R6/lib/libXp.a /usr/X11R6/lib/libXpm.a /usr/X11R6/lib/libXpm.so /usr/X11R6/lib/libXpm.so.4 /usr/X11R6/lib/libXpm.so.4.11 /usr/X11R6/lib/libXp.so /usr/X11R6/lib/libXp.so.6 /usr/X11R6/lib/libXp.so.6.2 /usr/X11R6/lib/libXrandr.a /usr/X11R6/lib/libXrandr.so /usr/X11R6/lib/libXrandr.so.1 /usr/X11R6/lib/libXrandr.so.1.0 /usr/X11R6/lib/libXrender.a /usr/X11R6/lib/libXrender.so /usr/X11R6/lib/libXrender.so.1 /usr/X11R6/lib/libXrender.so.1.1 /usr/X11R6/lib/libxrx.so /usr/X11R6/lib/libxrx.so.6 /usr/X11R6/lib/libxrx.so.6.3 /usr/X11R6/lib/libXss.a /usr/X11R6/lib/libXt.a /usr/X11R6/lib/libXTrap.a /usr/X11R6/lib/libXTrap.so /usr/X11R6/lib/libXTrap.so.6 /usr/X11R6/lib/libXTrap.so.6.4 /usr/X11R6/lib/libXt.so /usr/X11R6/lib/libXt.so.6 /usr/X11R6/lib/libXt.so.6.0 /usr/X11R6/lib/libXtst.a /usr/X11R6/lib/libXtst.so /usr/X11R6/lib/libXtst.so.6 /usr/X11R6/lib/libXtst.so.6.1
Re: [Dri-devel] pageflipping
On Tue, Sep 24, 2002 at 02:19:24 +0100, Keith Whitwell wrote:
Michel Dänzer wrote:
On Die, 2002-09-24 at 13:11, Keith Whitwell wrote:
I've been thinking again about pageflipping realized I can solve the
remaining few problems if I can tweak the behaviour of the 2d driver
slightly.
At the moment, the 2d driver always draws to buffer zero (the old front
buffer), and then at some point in the future, the dirty parts are
blitted to buffer one (the old back buffer).
However, this can be incorrect in a couple of circumstances, particularly
when the dirty regions (or even the drawing itself) overlaps with the 3d
window.
I think all my problems can be solved if I do two things:
1) always have X draw to the *current* front buffer (buffer zero or
buffer one, depending)
2) subtract the 3d window from the dirty regions before blitting to
the current back buffer.
I can probably figure out 2) without to much effort.
For 1), I can adjust the accelerated functions fairly easily to get them
to draw to buffer zero/one as appropriate.
How do you deal with offscreen access?
They should remain exactly as they are: I want to change the offset of the
front buffer - I would hope that the two are decoupled, maybe that's a
mistake on my behalf.
What about software fallbacks? What value do these use to get a pointer
to the framebuffer, and how can I go about changing it?
It's passed to xxxScreenInit(), and even if there's a single place where
it's stored afterwards, I'm not sure relying on that is a good idea.
Doesn't 2) alone work?
No, because you should be able to render to the same window with both X and
GL and see the results onscreen. If X always renders to buffer zero,
sometimes that won't work.
In theory,
this should work, but I've not tested it.
{
PixmapPtr pspix;
pspix = (*pScreen-GetScreenPixmap) (pScreen);
(*pScreen-ModifyPixmapHeader)(pspix, pScreen-width,
pScreen-height, pScreen-rootDepth,
BitsPerPixel(pScreen-rootDepth),
PixmapBytePad(pScrn-displayWidth, pScreen-rootDepth),
NEWFBPOINTER);
}
Basically fbScreenInit, passes the framebuffer pointer down to
miScreenInit, which ends up in miCreateScreenResources later where
the screen pixmap is setup. It essentially does the above too, to setup
this up.
Alan.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] R200 on trunk today
Keith, I'm looking to understand the behaviour I'm seeing since I installed the main branch today. With the default settings, and glxgears, I see: r200CreateScreen 1077 frames in 5.0 seconds = 215.400 FPS (Previously, I'd see around 300FPS for software rendering, and ~1500FPS for TCL) If I set R200_NO_USLEEPS, I see: r200CreateScreen 13368 frames in 5.0 seconds = 2673.600 FPS In q3, the difference (at 1280x1024, max settings) is around 9FPS... from 71FPS to 82FPS So, I'm looking to understand why the standard glxgears now renders slower than software fallbacks used to, and why now when I use R200_NO_RAST I only see 50FPS in glxgears Any ideas? Cheers, J. -- Jan Schmidt [EMAIL PROTECTED] Have you been half-asleep? Have you heard voices? I've heard them calling my name... -Kermit the Frog (Rainbow Connection) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 on trunk today
Jan Schmidt wrote: Keith, I'm looking to understand the behaviour I'm seeing since I installed the main branch today. With the default settings, and glxgears, I see: r200CreateScreen 1077 frames in 5.0 seconds = 215.400 FPS (Previously, I'd see around 300FPS for software rendering, and ~1500FPS for TCL) Why do you even care about software rasterization? In normal use the card basically never does this. If I set R200_NO_USLEEPS, I see: r200CreateScreen 13368 frames in 5.0 seconds = 2673.600 FPS For people who care about gears results, R200_NO_USLEEPS is what you should be doing. There is code in the newest r200 driver that uses irq's to do the same thing that the old busy waits used to, but (see yesterday's thread) there is a bug I had to disable it. When that bug is fixed, you should get good gears numbers *and* low cpu utilization without any env. vars. In q3, the difference (at 1280x1024, max settings) is around 9FPS... from 71FPS to 82FPS So, I'm looking to understand why the standard glxgears now renders slower than software fallbacks used to, and why now when I use R200_NO_RAST I only see 50FPS in glxgears Because the usleep takes up a longer time than it takes your cpu to draw a frame of gears via software rasterization. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
On Tue, Sep 24, 2002 at 02:49:37 +0100, Alan Hourihane wrote:
On Tue, Sep 24, 2002 at 02:19:24 +0100, Keith Whitwell wrote:
Michel Dänzer wrote:
On Die, 2002-09-24 at 13:11, Keith Whitwell wrote:
I've been thinking again about pageflipping realized I can solve the
remaining few problems if I can tweak the behaviour of the 2d driver
slightly.
At the moment, the 2d driver always draws to buffer zero (the old front
buffer), and then at some point in the future, the dirty parts are
blitted to buffer one (the old back buffer).
However, this can be incorrect in a couple of circumstances, particularly
when the dirty regions (or even the drawing itself) overlaps with the 3d
window.
I think all my problems can be solved if I do two things:
1) always have X draw to the *current* front buffer (buffer zero or
buffer one, depending)
2) subtract the 3d window from the dirty regions before blitting to
the current back buffer.
I can probably figure out 2) without to much effort.
For 1), I can adjust the accelerated functions fairly easily to get them
to draw to buffer zero/one as appropriate.
How do you deal with offscreen access?
They should remain exactly as they are: I want to change the offset of the
front buffer - I would hope that the two are decoupled, maybe that's a
mistake on my behalf.
What about software fallbacks? What value do these use to get a pointer
to the framebuffer, and how can I go about changing it?
It's passed to xxxScreenInit(), and even if there's a single place where
it's stored afterwards, I'm not sure relying on that is a good idea.
Doesn't 2) alone work?
No, because you should be able to render to the same window with both X and
GL and see the results onscreen. If X always renders to buffer zero,
sometimes that won't work.
In theory,
this should work, but I've not tested it.
{
PixmapPtr pspix;
pspix = (*pScreen-GetScreenPixmap) (pScreen);
(*pScreen-ModifyPixmapHeader)(pspix, pScreen-width,
pScreen-height, pScreen-rootDepth,
BitsPerPixel(pScreen-rootDepth),
PixmapBytePad(pScrn-displayWidth, pScreen-rootDepth),
NEWFBPOINTER);
}
Basically fbScreenInit, passes the framebuffer pointer down to
miScreenInit, which ends up in miCreateScreenResources later where
the screen pixmap is setup. It essentially does the above too, to setup
this up.
In fact, scratch that, looking furthur shows that the miCreateScreenResources
stores the Pixmap pointer in the devPrivate.
I'll do some digging.
Alan.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 on trunk today
quote who=Keith Whitwell Why do you even care about software rasterization? In normal use the card basically never does this. Only because I remember the numbers from when DRI has not been set up properly, and I get suspicious when DRI runs slower than the software rendering. There is code in the newest r200 driver that uses irq's to do the same thing that the old busy waits used to, but (see yesterday's thread) there is a bug I had to disable it. When that bug is fixed, you should get good gears numbers *and* low cpu utilization without any env. vars. I missed that thread, actually... are you talking about the r200WaitForFrameCompletion one, or somewhere else? So, I'm looking to understand why the standard glxgears now renders slower than software fallbacks used to, and why now when I use R200_NO_RAST I only see 50FPS in glxgears Because the usleep takes up a longer time than it takes your cpu to draw a frame of gears via software rasterization. OK, this makes sense for why it would be limited to 200FPS, but it doesn't explain why R200_NO_RAST now yields 50FPS, does it? I have got the right env var, havent I? (ie R200_NO_RAST makes it do no hardware accel?) J. -- Jan Schmidt [EMAIL PROTECTED] ENOSIG --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
On Die, 2002-09-24 at 15:19, Keith Whitwell wrote: Michel Dänzer wrote: On Die, 2002-09-24 at 13:11, Keith Whitwell wrote: I think all my problems can be solved if I do two things: 1) always have X draw to the *current* front buffer (buffer zero or buffer one, depending) 2) subtract the 3d window from the dirty regions before blitting to the current back buffer. I can probably figure out 2) without to much effort. For 1), I can adjust the accelerated functions fairly easily to get them to draw to buffer zero/one as appropriate. How do you deal with offscreen access? They should remain exactly as they are: I want to change the offset of the front buffer - I would hope that the two are decoupled, maybe that's a mistake on my behalf. You can't change the offset in the chip or offscreen access goes after whatever buffer is front. You'd have to use coordinate deltas, but only if the coordinates are within the virtual resolution, and even then I'm not sure that would always work. Try and see I guess. :) -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] XAA versioning should be solved
On Die, 2002-09-24 at 16:34, Michel Daenzer wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/xaa/ Changes by: mdaenzer@usw-pr-cvs1. 02/09/24 07:34:16 Log message: * bump XAA minor and move new fields at the end of XAAInfoRec * radeon driver can only accelerate TwoPoint lines with new XAA So hopefully the binary snapshots will no longer crash and burn without a new libxaa. :) Kevin, I've updated http://penguinppc.org/~daenzer/DRI/radeon-xaa-limits.diff to what I committed for your reference. Hmm, seems I need to add a couple of #ifdef XFree86LOADER yet... -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Snapshots now being built with gcc 3.2
Hi Jose I've updated my workstation to the RedHat Linux 7.3.94 beta, which has gcc 3.2. So now forward the snapshots will be built with this version. AFAIK this shouldn't pose any problem to the users since the key issue is that the kernel modules are compiled with the same version of gcc that compiled the kernel, and that still holds true. Is it your workstation which is used to built snapshots? I thought it was SF machnery... The Mach64 development on my side is still on hold. Besides the hassle of returning from vacations, and have a lot of stuff to do, my laptop's hard drive is busted so I've been working at the univeristy were I don't have any Mach64 card near me. Hopefully I should receive a new drive shortly. Sad. Really expected fast mach progress after your return. With security resolved and gatos merged (thanks to Leif again) it could go into XFree86 HEAD... Anyway, glad to hear from you again Sergey --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
You can't change the offset in the chip or offscreen access goes after whatever buffer is front. You'd have to use coordinate deltas, but only if the coordinates are within the virtual resolution, and even then I'm not sure that would always work. Try and see I guess. :) If so, it's a fundamental problem with xaa. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XAA versioning should be solved
On Tue, Sep 24, 2002 at 04:51:53PM +0200, Michel Dänzer wrote: On Die, 2002-09-24 at 16:34, Michel Daenzer wrote: CVSROOT:/cvsroot/dri Module name:xc Repository: xc/xc/programs/Xserver/hw/xfree86/xaa/ Changes by: mdaenzer@usw-pr-cvs1. 02/09/24 07:34:16 Log message: * bump XAA minor and move new fields at the end of XAAInfoRec * radeon driver can only accelerate TwoPoint lines with new XAA So hopefully the binary snapshots will no longer crash and burn without a new libxaa. :) Kevin, I've updated http://penguinppc.org/~daenzer/DRI/radeon-xaa-limits.diff to what I committed for your reference. Hmm, seems I need to add a couple of #ifdef XFree86LOADER yet... Okay, it's looking good. Let me know when you're finished with it. Thanks for catching and fixing this problem! Kevin --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
On Die, 2002-09-24 at 16:59, Keith Whitwell wrote: You can't change the offset in the chip or offscreen access goes after whatever buffer is front. You'd have to use coordinate deltas, but only if the coordinates are within the virtual resolution, and even then I'm not sure that would always work. Try and see I guess. :) If so, it's a fundamental problem with xaa. What exactly do you mean? -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XAA versioning should be solved
On Die, 2002-09-24 at 16:58, Kevin E Martin wrote: On Tue, Sep 24, 2002 at 04:51:53PM +0200, Michel Dänzer wrote: On Die, 2002-09-24 at 16:34, Michel Daenzer wrote: CVSROOT: /cvsroot/dri Module name: xc Repository: xc/xc/programs/Xserver/hw/xfree86/xaa/ Changes by: mdaenzer@usw-pr-cvs1. 02/09/24 07:34:16 Log message: * bump XAA minor and move new fields at the end of XAAInfoRec * radeon driver can only accelerate TwoPoint lines with new XAA So hopefully the binary snapshots will no longer crash and burn without a new libxaa. :) Kevin, I've updated http://penguinppc.org/~daenzer/DRI/radeon-xaa-limits.diff to what I committed for your reference. Hmm, seems I need to add a couple of #ifdef XFree86LOADER yet... Okay, it's looking good. Let me know when you're finished with it. Done, I hope the manual patch editing works, anyway you should get the idea. Thanks for catching and fixing this problem! Well, let's first see if it's actually fixed. I wonder if anyone would have noticed if it wasn't for the binary snapshots... :/ -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
Alan Hourihane wrote:
On Tue, Sep 24, 2002 at 02:49:37 +0100, Alan Hourihane wrote:
On Tue, Sep 24, 2002 at 02:19:24 +0100, Keith Whitwell wrote:
Michel Dänzer wrote:
On Die, 2002-09-24 at 13:11, Keith Whitwell wrote:
I've been thinking again about pageflipping realized I can solve the
remaining few problems if I can tweak the behaviour of the 2d driver
slightly.
At the moment, the 2d driver always draws to buffer zero (the old front
buffer), and then at some point in the future, the dirty parts are
blitted to buffer one (the old back buffer).
However, this can be incorrect in a couple of circumstances, particularly
when the dirty regions (or even the drawing itself) overlaps with the 3d
window.
I think all my problems can be solved if I do two things:
1) always have X draw to the *current* front buffer (buffer zero or
buffer one, depending)
2) subtract the 3d window from the dirty regions before blitting to
the current back buffer.
I can probably figure out 2) without to much effort.
For 1), I can adjust the accelerated functions fairly easily to get them
to draw to buffer zero/one as appropriate.
How do you deal with offscreen access?
They should remain exactly as they are: I want to change the offset of the
front buffer - I would hope that the two are decoupled, maybe that's a
mistake on my behalf.
What about software fallbacks? What value do these use to get a pointer
to the framebuffer, and how can I go about changing it?
It's passed to xxxScreenInit(), and even if there's a single place where
it's stored afterwards, I'm not sure relying on that is a good idea.
Doesn't 2) alone work?
No, because you should be able to render to the same window with both X and
GL and see the results onscreen. If X always renders to buffer zero,
sometimes that won't work.
In theory,
this should work, but I've not tested it.
{
PixmapPtr pspix;
pspix = (*pScreen-GetScreenPixmap) (pScreen);
(*pScreen-ModifyPixmapHeader)(pspix, pScreen-width,
pScreen-height, pScreen-rootDepth,
BitsPerPixel(pScreen-rootDepth),
PixmapBytePad(pScrn-displayWidth, pScreen-rootDepth),
NEWFBPOINTER);
}
Basically fbScreenInit, passes the framebuffer pointer down to
miScreenInit, which ends up in miCreateScreenResources later where
the screen pixmap is setup. It essentially does the above too, to setup
this up.
In fact, scratch that, looking furthur shows that the miCreateScreenResources
stores the Pixmap pointer in the devPrivate.
I'll do some digging.
It would be good to get Page Swapping working in the server. Not only
is this very valuable for 3D performance, but the X double buffer
extension should utilize this as well.
Perhaps we'll need to move this discussion to the xpert list, but first,
I'll ask here. Does anybody know of any applications that use DBE? If
not, we should remove it. If so, we need to fix it when the DRI is
enabled. The GLX spec clearly states:
All GLX rendering contexts share the same notion of which are front
buffers and which are back buffers for a given drawable. This notion is
also shared with the X double buffer extension (DBE).
Currently, DBE buffers are managed as X Pixmaps and DRI drivers have not
notion of DBE buffers. Any application that used OpenGL and DBE
together would be broken, but I haven't seen any bug reports along this
line. I have to conclude that no applications are using OpenGL and DBE
together.
Note: DBE and DRI cooperation has been broken for a long time. Keith's
work on page flipping is *not* the start of the problem, but it does
present an opportunity for us to fix DBE, or dump it.
--
/\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website
Speaking of the new web site, could someone please remove the section in the FAQ that says that various NDA'd documentation can be obtained by becoming an XFree86 Project member. Anyone who applies for XFree86 membership in order to obtain access to NDA'd documentation will be rejected. The XFree86 Project isn't an access point for restricted documentation. To be so would violate the spirit and/or the letter of most NDAs, and dilutes the Project's ability to obtain documentation access in the future. Formal XFree86 membership is intended for one audience only: active XFree86 developers. That intent needs to be backed up by some reasonable evidence when applying for membership. David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
Michel Dänzer wrote: On Die, 2002-09-24 at 16:59, Keith Whitwell wrote: You can't change the offset in the chip or offscreen access goes after whatever buffer is front. You'd have to use coordinate deltas, but only if the coordinates are within the virtual resolution, and even then I'm not sure that would always work. Try and see I guess. :) If so, it's a fundamental problem with xaa. What exactly do you mean? Michel, What exactly to *you* mean when you refer to offscreen? Offscreen XAA cache? Offscreen pixmaps? OpenGL back buffer? other OpenGL buffers? There's a lot in offscreen. Please clarify. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: XAA versioning?
On Sun, Sep 22, 2002 at 10:33:15PM +0200, Michel Dänzer wrote: Several people on IRC reported crashes in the 2D code with the current trunk snapshots. I realized they are due to the TwoPoint acceleration functions depending on XAA changes. How can we handle this, bump the XAA version and disable those functions if it's too old? Meanwhile, users should be able to work around the problem with Option XaaNoSolidTwoPointLine Option XaaNoDashedTwoPointLine Doesn't help on my system. After experimenting with xperf, I found that I need at least the following: Option XaaNoPixmapCache Option XaaNoSolidBresenhamLine and I tried less that 1/10th of all tests in xperf Stephane Chauveau --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
Keith,
This should do it.
{
PixmapPtr pspix;
pspix = (*pScreen-GetScreenPixmap) (pScreen);
(*pScreen-ModifyPixmapHeader)(pspix, 0, 0, 0, 0, 0,
info-FB + XXXOFFSETX );
}
Alan.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
Alan Hourihane wrote:
Keith,
This should do it.
{
PixmapPtr pspix;
pspix = (*pScreen-GetScreenPixmap) (pScreen);
(*pScreen-ModifyPixmapHeader)(pspix, 0, 0, 0, 0, 0,
info-FB + XXXOFFSETX );
}
Alan.
Alan, do you have a feel for how this will affect XAA and offscreen pixmaps,
pixmap caches, etc?
My guess is that it will break them, but I live in hope...
Keith
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
On Tue, Sep 24, 2002 at 05:06:13 +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
Keith,
This should do it.
{
PixmapPtr pspix;
pspix = (*pScreen-GetScreenPixmap) (pScreen);
(*pScreen-ModifyPixmapHeader)(pspix, 0, 0, 0, 0, 0,
info-FB + XXXOFFSETX );
}
Alan.
Alan, do you have a feel for how this will affect XAA and offscreen
pixmaps, pixmap caches, etc?
My guess is that it will break them, but I live in hope...
It might not break them, the pixmap cache gets cracked down via
the PutImage (or PutImage/CopyArea) path which gets passed
through to our ImageWrite/ScreenToScreen accelerator code.
Um, might have to remove that GXCOPY_ONLY flag on ImageWrites though.
But, the alternative path is...
If we code up 'WriteBitmap' and 'WritePixmap' which deals with
pixmap cache loading and hook these into our _accel.c functions,
then we should be able to remove the pixmap cache flag called
LINEAR_FRAMEBUFFER. This is a more direct path and might be
slightly faster. That should do the trick if the above doesn't.
Alan.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
On Die, 2002-09-24 at 18:37, Alan Hourihane wrote:
On Tue, Sep 24, 2002 at 05:06:13 +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
Keith,
This should do it.
{
PixmapPtr pspix;
pspix = (*pScreen-GetScreenPixmap) (pScreen);
(*pScreen-ModifyPixmapHeader)(pspix, 0, 0, 0, 0, 0,
info-FB + XXXOFFSETX );
}
Alan.
Alan, do you have a feel for how this will affect XAA and offscreen
pixmaps, pixmap caches, etc?
My guess is that it will break them, but I live in hope...
It might not break them, the pixmap cache gets cracked down via
the PutImage (or PutImage/CopyArea) path which gets passed
through to our ImageWrite/ScreenToScreen accelerator code.
But that's exactly the problem - XAA doesn't know about the different
buffers so the coordinates will be wrong when we render to the 'back'
buffer (the pixmap cache is always at a fixed location in the
framebuffer).
Um, might have to remove that GXCOPY_ONLY flag on ImageWrites though.
You mean NO_GXCOPY? That's only used in the MMIO code.
But, the alternative path is...
If we code up 'WriteBitmap' and 'WritePixmap' which deals with
pixmap cache loading and hook these into our _accel.c functions,
then we should be able to remove the pixmap cache flag called
LINEAR_FRAMEBUFFER. This is a more direct path and might be
slightly faster. That should do the trick if the above doesn't.
That sounds interesting.
But what about the source coordinates when XAA renders from the cache to
the screen?
--
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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
On Die, 2002-09-24 at 17:30, Jens Owen wrote: Michel Dänzer wrote: On Die, 2002-09-24 at 16:59, Keith Whitwell wrote: You can't change the offset in the chip or offscreen access goes after whatever buffer is front. You'd have to use coordinate deltas, but only if the coordinates are within the virtual resolution, and even then I'm not sure that would always work. Try and see I guess. :) If so, it's a fundamental problem with xaa. What exactly do you mean? Michel, What exactly to *you* mean when you refer to offscreen? Offscreen XAA cache? Offscreen pixmaps? OpenGL back buffer? other OpenGL buffers? There's a lot in offscreen. Please clarify. XAA offscreen. Good point about DBE, I also think we should discuss this with Mark et al., maybe he can tell us how they're dealing with this in the nvidia driver, or then again maybe not. :) -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: XAA versioning?
On Die, 2002-09-24 at 17:55, Stephane Chauveau wrote: On Sun, Sep 22, 2002 at 10:33:15PM +0200, Michel Dänzer wrote: Several people on IRC reported crashes in the 2D code with the current trunk snapshots. I realized they are due to the TwoPoint acceleration functions depending on XAA changes. How can we handle this, bump the XAA version and disable those functions if it's too old? Meanwhile, users should be able to work around the problem with Option XaaNoSolidTwoPointLine Option XaaNoDashedTwoPointLine Doesn't help on my system. After experimenting with xperf, I found that I need at least the following: Option XaaNoPixmapCache Option XaaNoSolidBresenhamLine and I tried less that 1/10th of all tests in xperf That workaround I advertised was naive. The layout of the XAAInfoRec structure had changed so anything that worked was basically luck. As of tomorrow's snapshots, this should be resolved; if not, let us know. -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
On Tue, Sep 24, 2002 at 06:43:32 +0200, Michel Dänzer wrote:
On Die, 2002-09-24 at 18:37, Alan Hourihane wrote:
On Tue, Sep 24, 2002 at 05:06:13 +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
Keith,
This should do it.
{
PixmapPtr pspix;
pspix = (*pScreen-GetScreenPixmap) (pScreen);
(*pScreen-ModifyPixmapHeader)(pspix, 0, 0, 0, 0, 0,
info-FB + XXXOFFSETX );
}
Alan.
Alan, do you have a feel for how this will affect XAA and offscreen
pixmaps, pixmap caches, etc?
My guess is that it will break them, but I live in hope...
It might not break them, the pixmap cache gets cracked down via
the PutImage (or PutImage/CopyArea) path which gets passed
through to our ImageWrite/ScreenToScreen accelerator code.
But that's exactly the problem - XAA doesn't know about the different
buffers so the coordinates will be wrong when we render to the 'back'
buffer (the pixmap cache is always at a fixed location in the
framebuffer).
Um, might have to remove that GXCOPY_ONLY flag on ImageWrites though.
You mean NO_GXCOPY? That's only used in the MMIO code.
Yes. Oops.
But, the alternative path is...
If we code up 'WriteBitmap' and 'WritePixmap' which deals with
pixmap cache loading and hook these into our _accel.c functions,
then we should be able to remove the pixmap cache flag called
LINEAR_FRAMEBUFFER. This is a more direct path and might be
slightly faster. That should do the trick if the above doesn't.
That sounds interesting.
But what about the source coordinates when XAA renders from the cache to
the screen?
We can adjust the coordinates when we know we are rendering to the backbuffer
or frontbuffer.
But a better approach here, is to write both WritePixmapToCache and
WriteBitmapToCache functions which will be specific to the pixmap
cache handling and we can deal with the issue of detecting front/back
buffers here nicely.
Alan.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
On Tue, Sep 24, 2002 at 05:06:13 +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
Keith,
This should do it.
{
PixmapPtr pspix;
pspix = (*pScreen-GetScreenPixmap) (pScreen);
(*pScreen-ModifyPixmapHeader)(pspix, 0, 0, 0, 0, 0,
info-FB + XXXOFFSETX );
}
Alan.
Alan, do you have a feel for how this will affect XAA and offscreen
pixmaps, pixmap caches, etc?
My guess is that it will break them, but I live in hope...
Having put some more thought into it, it would probably break them.
Although in the followup I sent Michel, we might be able to work
around the pixmap cache with the WriteBitmap/PixmapToCache code
replacements. Offscreen Pixmap support may need additional work.
Alan.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] APPLE_client_storage?
I noticed that some code from Mesa was recently folded into DRI to support APPLE_client_storage. What does it take to enable that in a driver? Is it like SGIS_generate_mipmaps in that the driver just needs to enable it? On a related note, some time ago (on an IRC meeting, I think) there was some discussion about directly mapping Mesa backing store into AGP space. At the time it seemed feasable, but there were still some issues. Has anyone given this any thought in the meantime? As the texture requirements for games explodes into the stratosphere, we'll be much better off if we can require fewer copies textures. :) Maybe someday one of us will get to hardware accelerating SGIS_generate_mipmaps... -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] pageflipping
On Die, 2002-09-24 at 19:10, Alan Hourihane wrote: On Tue, Sep 24, 2002 at 06:43:32 +0200, Michel Dänzer wrote: On Die, 2002-09-24 at 18:37, Alan Hourihane wrote: If we code up 'WriteBitmap' and 'WritePixmap' which deals with pixmap cache loading and hook these into our _accel.c functions, then we should be able to remove the pixmap cache flag called LINEAR_FRAMEBUFFER. This is a more direct path and might be slightly faster. That should do the trick if the above doesn't. That sounds interesting. But what about the source coordinates when XAA renders from the cache to the screen? We can adjust the coordinates when we know we are rendering to the backbuffer or frontbuffer. We need a bullet-proof way to distinguish between on-screen and off-screen coordinates for this... But a better approach here, is to write both WritePixmapToCache and WriteBitmapToCache functions which will be specific to the pixmap cache handling and we can deal with the issue of detecting front/back buffers here nicely. ... in which case we don't need this at all, or am I missing something? -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] APPLE_client_storage?
Ian Romanick wrote: I noticed that some code from Mesa was recently folded into DRI to support APPLE_client_storage. What does it take to enable that in a driver? Is it like SGIS_generate_mipmaps in that the driver just needs to enable it? On a related note, some time ago (on an IRC meeting, I think) there was some discussion about directly mapping Mesa backing store into AGP space. At the time it seemed feasable, but there were still some issues. Has anyone given this any thought in the meantime? As the texture requirements for games explodes into the stratosphere, we'll be much better off if we can require fewer copies textures. :) Maybe someday one of us will get to hardware accelerating SGIS_generate_mipmaps... The r200 driver has the allocator parts of GL_NV_vertex_array_range, and can do blit-uploads for texture images in agp space. Currently these require PACK_CLIENT_STORAGE (as uploads are normally lazy). We could do eager uploads when the pack parameter isn't present, I suppose. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Typo on DRI website.
Howzit Frank? Quite frankly (no pun intended) IRC logs are about the only thing out of place, and when I look at that page I wonder if I should remove them, however your idea to split documentation back out of help will draw attention back to them on that page meaning they can be safely removed. Ok, I would remove CVS and IRC Logs from that page. They should re-appear on the Contribute page. IRC is already gone, I'm leaving CVS there (for now at least) because you know who you are is working on scripts to pull CVs, compile etc I must disagree on this point (I need persuasion perhaps a really good example / implementation where it works well) because help status pages are the longest pages they could benefit from it the most (at all) but I like your other suggestions so much that they are about to become shorter and the colour banding makes it a dead simple after that. If you don't want to add it then that's ok. But I still feel it is hard to get an overview of what one can find on a page. Maybe put a more detailed site outline on the home page. (see below) Another way to give a better overview might be to change the font to something more crisp and readable. I really like Arial or Helvetica for reading stuff on the web. You could also try increasing the font size by one. Yeah I must have a look at that, the CSS is not behaving perfectly now that it is inserted via PHP, but this could just be me, the pages on my machine are obviously not rendered as they will be when they are being served up via the webserver so its difficult to guage the effects of changes. But heck it's one file to change cant be that hard. g It would also be good if the titles for items on a page were a bigger font size, in addition to being bold/underlined. That would make them stand out a lot better. As above. A few other things I can think of to change in the current site are: I think you misunderstood me, the points below apply to the current site, not your site update. They are just my ideas for what should change, but it appears you have already addressed a lot of them. I should have payed closer attention to your site update before writing them up. Understood. I'm sort of lost I understand the php header funcion and what it did / does but HTML headers? What I mean is that it should output the title for a page. On your site that would be the two horizontal bars with the title in between. So then the source for a page is basically: ? dri_header (Downloads); ? [ HTML content here ] ? dri_footer (); ? Then if you want to change the basic appearance of a page (title, header/footer) you can do it in those two functions. Also saves you from reusing the same header/footer HTML in every page over and over again. Did this already (guess what I was doing monday night instead of economics) There is no About DRI page. There is currently What is the DRI text on the home page already. Junk on the home page? Please be more specific, there is obviously some confusion here are we looking at the same page? Sorry, I ment the current site, not your site update. However, looking at yours I think you should remove the stuff below the Mailing Lists section. It shouldn't really be necessary to explain the different links, I just put that on the original page as a filler. Well actually this is similar in concept to your content navigation bar, or at least it could be extended to do this, comments? There is one downloads page already?? Although it does have IRC logs, and a CVS section (waiting on someone here). More confusion, same page? Yes, your Downloads page is good. I would remove CVS and IRC Logs. Also I would put the config files as the very last item, because I doubt many people downloads those. CVS stays for now (see above) IRC is long gone, will move config files. - remove the Report Problems stuff from the Help FAQ page since we don't use the SF.net bugtracker anyway. Will do, I read about this on the mailing list, but I'm not going to remove it just because I think nobody wants it. Thinking about this, a better idea might be to say that bugs should be reported on the dri-devel mailing list. If we do that and it results in too much traffic/crappy bug reports it can be removed later. But giving people some way to report bugs is probably a good idea. Must still add some text about report bugs to dri-devel. In the end this leaves us with these pages: 1. Home - with the About DRI text, a nice intro to the project I think this is how it is. 2. Status - the status of the hardware we support With 5 this is how it will be. 3. Downloads - downloads of drivers, kernel modules, and other files Pretty much identical already. 4. Documentation - all of our documentation for developers and end users This I like it was a dubious call to combine help faq documentation. 5. Contribute
Re: [Dri-devel] Re: Typo on DRI website.
Howzit Frank? Ok, I would remove CVS and IRC Logs from that page. They should re-appear on the Contribute page. IRC is already gone, I'm leaving CVS there (for now at least) because you know who you are is working on scripts to pull CVs, compile etc Why do you need to leave the CVS information there? It can be garnered from different sources :) I just started doing a code review of the r200 driver, hopefully I'll get around to writing some more scripts within the next few weeks. If not, I'll bug Thomasz and have him write something :} c. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website.
Ok, I would remove CVS and IRC Logs from that page. They should re-appear on the Contribute page. IRC is already gone, I'm leaving CVS there (for now at least) because you know who you are is working on scripts to pull CVs, compile etc Why do you need to leave the CVS information there? It can be garnered from different sources :) To get a response out of you g That's where'd I'd put a list of the scripts to d/l. I just started doing a code review of the r200 driver, hopefully I'll get around to writing some more scripts within the next few weeks. Well I think r200 is a wee bit more important than scripts, you are free to disagree and work on your scripts though. g If not, I'll bug Thomasz and have him write something :} Hello Thomas. cheers Liam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website - XFree86 NDA's
Speaking of the new web site, could someone please remove the section in the FAQ that says that various NDA'd documentation can be obtained by becoming an XFree86 Project member. I'm sure someone could do that, could you point out where this is, I'm certainly not about to read all the FAQ entries to find this. Just found it. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Typo on DRI website - XFree86 NDA's
Speaking of the new web site, could someone please remove the section in the FAQ that says that various NDA'd documentation can be obtained by becoming an XFree86 Project member. I'm sure someone could do that, could you point out where this is, I'm certainly not about to read all the FAQ entries to find this. Just found it. Development Issues 3. How can I obtain hardware documentation? Appears to be locked, don't think I can touch this. Liam it depends --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri-devel, Breaking News Alert
All our mailings are sent complying to the proposed H.R. 3113 Unsolicited Commercial Electronic Mail Act of 2000. Please see the bottom of this message for further information and removal instructions. PARENTS OF 15 - YEAR OLD - FIND $71,000 CASH HIDDEN IN HIS CLOSET! Does this headline look familiar? Of course it does. You most likely have just seen this story recently featured on a major nightly news program (USA). And reported elsewhere in the world (including my neck of the woods New Zealand). His mother was cleaning and putting laundry away when she came across a large brown paper bag that was suspiciously buried beneath some clothes and a skateboard in the back of her 15-year-old sons closet. Nothing could have prepared her for the shock she got when she opened the bag and found it was full of cash. Five-dollar bills, twenties, fifties and hundreds - all neatly rubber-banded in labelled piles. My first thought was that he had robbed a bank, says the 41-year-old woman, There was over $71,000 dollars in that bag -- that's more than my husband earns in a year. The woman immediately called her husband at the car-dealership where he worked to tell him what she had discovered.He came home right away and they drove together to the boys school and picked him up. Little did they suspect that where the money came from was more shocking than actually finding it in the closet. As it turns out, the boy had been sending out, via E-mail, a type of Report to E-mail addresses that he obtained off the Internet. Everyday after school for the past 2 months, he had been doing this right on his computer in his bedroom. I just got the E-mail one day and I figured what the heck, I put my name on it like the instructions said and I started sending it out, says the clever 15-year-old. The E-mail letter listed 5 addresses and contained instructions to send one $5 dollar bill to each person on the list, then delete the address at the top and move the others addresses Down , and finally to add your name to the top of the list. The letter goes on to state that you would receive several thousand dollars in five-dollar bills within 2 weeks if you sent out the letter with your name at the top of the 5-address list. I get junk E-mail all the time, and really did not think it was going to work, the boy continues. Within the first few days of sending out the E-mail, the Post Office Box that his parents had gotten him for his video-game magazine subscriptions began to fill up with not magazines, but envelopes containing $5 bills. About a week later I rode [my bike] down to the post office and my box had 1 magazine and about 300 envelops stuffed in it. There was also a yellow slip that said I had to go up to the [post office] counter. I thought I was in trouble or something (laughs). He goes on, I went up to the counter and they had a whole box of more mail for me. I had to ride back home and empty out my backpack because I could not carry it all. Over the next few weeks, the boy continued sending out the E-mail.The money just kept coming in and I just kept sorting it and stashing it in the closet, barely had time for my homework.He had also been riding his bike to several of the banks in his area and exchanging the $5 bills for twenties, fifties and hundreds. I didn't want the banks to get suspicious so I kept riding to different banks with like five thousand at a time in my backpack. I would usually tell the lady at the bank counter that my dad had sent me in to exchange the money] and he was outside waiting for me.One time the lady gave me a really strange look and told me that she would not be able to do it for me and my dad would have to come in and do it, but I just rode to the next bank down the street (laughs). Surprisingly, the boy did not have any reason to be afraid.The reporting news team examined and investigated the so-called chain-letter the boy was sending out and found that it was not a chain-letter at all.In fact, it was completely legal according to US Postal and Lottery Laws, Title 18, Section 1302 and 1341, or Title 18, Section 3005 in the US code, also in the code of federal regulations, Volume 16, Sections 255 and 436, which state a product or service must be exchanged for money received. Every five-dollar bill that he received contained a little note that read, Please send me report number XYX.This simple note made the letter legal because he was exchanging a service (A Report on how-to) for a five-dollar fee. [This is the end of the media release. If you would like to understand how the system works and get your $71,000 please continue reading. What appears below is what the 15 year old was sending out on the net - YOU CAN USE IT TOO - just follow the simple instructions]. ++ BE FINANCIALLY FREE LIKE OTHERS WITHIN A YEAR!!! Before you say Bull,
[Dri-devel] exclusion of (older) dri drivers
Hello Keith, your last r200 merge disabled the build of all other drivers. I think the problem cis in lib/GL/mesa/src/drv/Imakefile: #SUBDIRS = common DriDrivers SUBDIRS = common r200 radeon Greetings Marc -- Marc Dietrich Help yourself or Microsoft does! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri-devel, Breaking News Alert
Oh, now that's even more annoying than SPAM usually is! Here I was thinking that someone was going to announce that NVidia decided to support open source or that the texture compression pattent was going to be opened to the DRI group or *something* cool. *sigh* Cheers, David --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri-devel, Breaking News Alert
David Willmore wrote: Oh, now that's even more annoying than SPAM usually is! Here I was thinking that someone was going to announce that NVidia decided to support open source or that the texture compression pattent was going to be opened to the DRI group or *something* cool. *sigh* No such luck. FYI, Daniel Vogel asked S3 about texture compression again yesterday. No reply yet. We'll keep pinging them... -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga-stereo-patch
On Die, 2002-09-24 at 10:08, Eric Anholt wrote: On Mon, 2002-09-23 at 09:00, Michel Dänzer wrote: I've incorporated this and turned it into a template: http://penguinppc.org/~daenzer/DRI/drm-vblank-template.diff I've put a new one up at http://people.freebsd.org/~anholt/dri/files/framethrottle2.diff which includes MGA support. I'll work on r128 when I get some time again. I may have reversed the IRQ_ACTIVE - IRQ_NR change inadvertently, I/we can change that back. Sleep is my top priority right now. Yeah, let's iron this out and get it committed; I'll leave the BSD, mga, r200 and whatnot bits to you. :) BTW is there any reason why the mga stuff can't move to the shared DRM directory? What about using LIBGL_THROTTLE_REFRESH in all 3D drivers? I've updated my patch. The r200 client lib doesn't check for the irq number, but I couldn't figure out what exactly that was being checked for. To see if the IRQ is enabled. Oops, I hadn't realized that the ddx was doing the irq init. Would it be worthwhile to have the vblank-enabling done by clients and refcounted so the interrupts are only coming in when there was a need to track them? Well, I was registering 0.0 - 0.4% cpu utilization for interrupts, so maybe we don't care that much. I don't think we do, and this way it's very easy for other clients to use just this functionality. BTW I'm just experiencing IRQ timeouts as well. In fact, no interrupts occur at all, and the RADEON_GEN_INT_STATUS register seems to always contain 0x00080007; interestingly, bit 16 isn't documented. Maybe that's just a red herring though, and the IRQ is disabled in PCI config space or something? -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga-stereo-patch
On Tue, 2002-09-24 at 17:08, Michel Dänzer wrote: On Die, 2002-09-24 at 10:08, Eric Anholt wrote: On Mon, 2002-09-23 at 09:00, Michel Dänzer wrote: I've incorporated this and turned it into a template: http://penguinppc.org/~daenzer/DRI/drm-vblank-template.diff I've put a new one up at http://people.freebsd.org/~anholt/dri/files/framethrottle2.diff which includes MGA support. I'll work on r128 when I get some time again. I may have reversed the IRQ_ACTIVE - IRQ_NR change inadvertently, I/we can change that back. Sleep is my top priority right now. Yeah, let's iron this out and get it committed; I'll leave the BSD, mga, r200 and whatnot bits to you. :) BTW is there any reason why the mga stuff can't move to the shared DRM directory? Which mga stuff? MGA is shared about as much as the other drivers. One thing we should do is share drm.h between the two. What about using LIBGL_THROTTLE_REFRESH in all 3D drivers? I've updated my patch. Sounds good to me. BTW I'm just experiencing IRQ timeouts as well. In fact, no interrupts occur at all, and the RADEON_GEN_INT_STATUS register seems to always contain 0x00080007; interestingly, bit 16 isn't documented. Maybe that's just a red herring though, and the IRQ is disabled in PCI config space or something? How often do you get timeouts? Does it happen with any app? I haven't noticed any yet. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mga-stereo-patch
On Mit, 2002-09-25 at 03:52, Eric Anholt wrote: On Tue, 2002-09-24 at 17:08, Michel Dänzer wrote: BTW is there any reason why the mga stuff can't move to the shared DRM directory? Which mga stuff? MGA is shared about as much as the other drivers. Hmm, I think I confused mga and gamma in your patch. What about using LIBGL_THROTTLE_REFRESH in all 3D drivers? I've updated my patch. Sounds good to me. Cool, I'd commit it right now if it wasn't for the issue below... BTW I'm just experiencing IRQ timeouts as well. In fact, no interrupts occur at all, and the RADEON_GEN_INT_STATUS register seems to always contain 0x00080007; interestingly, bit 16 isn't documented. Maybe that's just a red herring though, and the IRQ is disabled in PCI config space or something? How often do you get timeouts? Does it happen with any app? I haven't noticed any yet. Neither did I until shortly before my last post, but now the CPU doesn't see any interrupts even though the chip seems to be generating them (that's why some bits in RADEON_GEN_INT_STATUS are set). Any idea what could be up and how to resolve it? I assume a reboot will be a way... A possibility to work around this problem would be polling the interrupt status register regularly and calling the interrupt service function if some bits are set? -- 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Investment Sample
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00D7_80C51D6A.A5835A82
