Re: current DRM CVS
If I get a chance this evening or over the weekend, I think we need to split 2.4 and 2.6, they can pretty much share everything that isn't drm_stub.h and drm_drv.h from what I can see... I think linknig over files into a 2.4 build might help a lot... Jon most of the 2.6 specific stuff is in these files (or is it spreading out amoing the rest?)... Dave. On Thu, 23 Sep 2004, Jon Smirl wrote: I just fixed DRM CVS so that it compiles again on 2.4 but it doesn't work. I'm open to clean solutions for making DRM(probe) in drm_stub.h work on 2.4. 2.4 is missing all of the register_chrdev_region, cdev_init, cdev_add, kobject stuff. This is too complicated for stubbing things out with inlines to work. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: current DRM CVS
Dave Airlie wrote: If I get a chance this evening or over the weekend, I think we need to split 2.4 and 2.6, they can pretty much share everything that isn't drm_stub.h and drm_drv.h from what I can see... I think linknig over files into a 2.4 build might help a lot... Jon most of the 2.6 specific stuff is in these files (or is it spreading out amoing the rest?)... I was going to suggest something similar - it looks like a split will help both 2.6 development and 2.4 stability. Keith --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Question about FRONT BUFFER?
Hi, Note, that what I'm writing is based on radeon driver. I haven't investigated other drivers much. W licie z czw, 23-09-2004, godz. 01:13, Amir Bukhari pisze: Is the frontbuffer shared between all contexts, or for each Context there will be a different frontbuffer? Yes, frontbuffer is shared between all context and X server. In direct rendering I understand that frontbuffer point to the visible framebuffer of the card (write to screen). Using at the end the position of the window and its clips mask you will write to the frontbuffer (framebuffer), correct me if I am wrong please! Correct. Note that backbuffer is also shared by all contexts, but drawables may have different clip rects for front and back because we don't have 2d windows in backbuffer. Your goal is to redirect output of GLcore (indirect software renderer) to pixmap, right? From my latest investigations of GLcore it seems that it can use both windows and pixmaps as it's frontbuffer. I haven't tried the latter but I think it'll work (I hope). I think You just need to allocate pixmap and tell mesa to render to it. You don't have to worry about backbuffer as it is always allocated in host's memory and not used outside GLcore. BTW: I'm working on forcing GLcore to render into other parts of card's memory than front buffer (specifically front right buffer). Maybe this may be helpful. If I'll come up with workable solution I'll let You know. Any pointers? best, -- Jacek Rosik [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: latest Mesa radeon crashing out...
Hmmm. This is interesting. If you back up to two days ago, does it
still happen? And after a clean rebuild of today?
I think I tracked it down, after 5 hours or so with Eric on IRC, of course
ten mins after Eric goes to bed I find it ... it seems to fix ipers and my
own application .. Dieter can you check if you can crash with the latest
CVS...
I've committed the following patch:
Index: r200_cmdbuf.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_cmdbuf.c,v
retrieving revision 1.8
diff -u -r1.8 r200_cmdbuf.c
--- r200_cmdbuf.c 22 Sep 2004 06:27:02 - 1.8
+++ r200_cmdbuf.c 23 Sep 2004 08:04:44 -
@@ -127,6 +127,9 @@
dest = rmesa-store.cmd_buf + rmesa-store.cmd_used;
r200EnsureCmdBufSpace( rmesa, rmesa-hw.max_state_size );
+ /* we need to recalculate dest after EnsureCmdBufSpace
+ as we may flush the buffer - airlied */
+ dest = rmesa-store.cmd_buf + rmesa-store.cmd_used;
if (R200_DEBUG DEBUG_STATE) {
foreach( atom, rmesa-hw.atomlist ) {
if ( atom-dirty || rmesa-hw.all_dirty ) {
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
At the time the code was written (fall 1999?) the only way Gareth found that he could reliably determine that SSE was fully supported (by CPU and kernel) was to try executing an SSE instruction and catching the exception if it failed. If there's a better way of doing that nowadays, we could update Mesa. A work-around might be for Phillip to set the MESA_NO_SSE env var. Does that mean that software Mesa doesn't use SSE? The problem occurs only with the r200 driver, not with software rendering. Philipp --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: current DRM CVS
drm_sysfs.h and radeon_i2c.c are also 2.6 specific. drm_stub.h works on 2.4 except for the register_chrdev/cdev stuff. I would keep stub as is for 2.4 and just revert that part. The proposed 2.6 VGA sharing code will make 90% of drm_drv/drm_stub useless on 2.6 when it shows up. Alternatively I could just pull out the register_chrdev/cdev stuff since that was preparing for VGA sharing. I was going to let VGA share device majors with DRM but if that isn't going to happen we don't need the code. Removing that code removes a major point of 2.4 breakage. Another idea would be to split 2.6 off and make drm_core. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
Philipp Klaus Krause wrote: Does that mean that software Mesa doesn't use SSE? The problem occurs only with the r200 driver, not with software rendering. Okay, then the SSE test can't be the problem. The exact same code gets executed in both the R200 driver and software Mesa. Actually, do you mean software Mesa (i.e., the libGL.so built by doing 'make linux-x86' in the Mesa tree) or GLX indirect-rendering? In this particular case they are quite different as the former executes in the application's address space, but the later does not. Is there any way you can figure out where the jvm is terminating? This is so weird... --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
On Mer, 2004-09-22 at 22:14, Eric Anholt wrote: 2.2 kernels and kernels not properly configured for Pentium3 CPUs. So, what's the right way on a 2.4 or a 2.6 kernel to determine if an app can use SSE? What about BSD? On FreeBSD we just use a convenient little sysctl to pull out whether there's SSE and the kernel supports it. Ask the processor or ask the kernel (cpuid or /proc/cpuinfo). All modern kernels support SSE so the exception case should only occur for 2.2 (ie unsupported). Alan --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
Ian Romanick schrieb: Philipp Klaus Krause wrote: Does that mean that software Mesa doesn't use SSE? The problem occurs only with the r200 driver, not with software rendering. Okay, then the SSE test can't be the problem. The exact same code gets executed in both the R200 driver and software Mesa. Actually, do you mean software Mesa (i.e., the libGL.so built by doing 'make linux-x86' in the Mesa tree) or GLX indirect-rendering? In this particular case they are quite different as the former executes in the application's address space, but the later does not. I just moved r200_dri.so away. Is there any way you can figure out where the jvm is terminating? This is so weird... Sorry for confusing people on this list, upon closer examination it seems it isn't the SIGFPE that caused the problem but a signal SIGSEGV raised in a glCallList(). If someone else wants to test: I use the glxgears port to jogl that is in the jogl-demos.jar from the jogl Java OpenGL binding (the one that was created by SUN and SGI). This is part of the error message: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4D4E5A16 Function=(null)+0x4D4E5A16 Library=/usr/X11R6/lib/modules-dri-trunk/dri/r200_dri.so NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at net.java.games.jogl.impl.x11.X11GLImpl.glCallList(Native Method) at demos.gears.Gears$GearRenderer.display(Gears.java:134) at net.java.games.jogl.impl.GLDrawableHelper.display(GLDrawableHelper.java:74) at net.java.games.jogl.GLCanvas$DisplayAction.run(GLCanvas.java:221) at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:290) - locked 0x447898b0 (a net.java.games.jogl.impl.x11.X11OnscreenGLContext) at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:208) at net.java.games.jogl.GLCanvas.display(GLCanvas.java:75) at net.java.games.jogl.Animator$1.run(Animator.java:107) at java.lang.Thread.run(Thread.java:536) Just a small note on why I suspected it was the SIGFPE first even though the above log is rather clear: When debugging my C++ applications using OpenGL, gdb halts on a SIGFPE in _mesa_test_os_sse_exception ehen I use the r200 driver, but doesn't with software rendering, so I just noticed that the java program had a problem with a signal that went away when using software instead of the r200 driver, so I though it was the same. Philipp --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
Alan Cox wrote: On Mer, 2004-09-22 at 22:14, Eric Anholt wrote: 2.2 kernels and kernels not properly configured for Pentium3 CPUs. So, what's the right way on a 2.4 or a 2.6 kernel to determine if an app can use SSE? What about BSD? On FreeBSD we just use a convenient little sysctl to pull out whether there's SSE and the kernel supports it. Ask the processor or ask the kernel (cpuid or /proc/cpuinfo). All modern kernels support SSE so the exception case should only occur for 2.2 (ie unsupported). The folks on #freedesktop suggested parsing cpuinfo, and I wrote some simple code to do that. Are you saying that, if CPUID returns the SSE bit set and we're on a 2.4 or later kernel, we're good to go? That would make me very happy because we already test the CPUID bit, and DRI isn't supported on 2.2. :) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: UT2004 freeze when shooting with Shock Rifle
On Sun, 19 Sep 2004 11:10:43 +0200, Marcello Maggioni [EMAIL PROTECTED] wrote: On Sun, 19 Sep 2004 10:59:25 +0200, Marcello Maggioni [EMAIL PROTECTED] wrote: I've finally done it :) It was quite difficult , the rendering speed was too slow and I couldn't reproduce the freeze with that speed (the game took hours to load into a stage ) . So I had to enable NMI_WATCHDOG then redirect the output of R200_DEBUG=san into /dev/shm (the memory is much faster than the HD! ) and then access by SSH into the system and copy the log file into a real filesystem before rebooting . Anyway now I have the log file , but the problem is that are 210 MB (6MB compressed) :O What should I do? posting it to the ML or not?? Bye Marcello Ehm, I quote myself :P I've put it on my webspace, if you want to download it the URL is : http://www.webalice.it/hayarms/ut2004lock.log.bz2 I hope that this can help :) If you need some testing I'm here ... :) Bye Marcello Up :) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
On Iau, 2004-09-23 at 17:22, Ian Romanick wrote: The folks on #freedesktop suggested parsing cpuinfo, and I wrote some simple code to do that. Are you saying that, if CPUID returns the SSE bit set and we're on a 2.4 or later kernel, we're good to go? That would make me very happy because we already test the CPUID bit, and DRI isn't supported on 2.2. :) Should do. There is a corner case of SMP with only one CPU having SSE but thats already broken in Mesa and many other packages. The more thorough case is you use /dev/cpu/%d/cpuid to check the CPUid on each processor but I'm not sure thats neccessary in reality --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: XComposite and GLX
now it is two days as I began study GLX, GLcore. to see how to redirect indirect Software rendering at the end I find the following: when GLX bind a window with context it assign the frontbuffer to the window. this window will be rendered to it. As we redirect this window with Composite its pixmap (normaly Screen pixmap) is replaced with offscreen pixmap. thus GLcore when rendered to window it use this offscreen and not directly access the framebuffer of the card. I could redirect glxgears to offscreen and also a simple example of GLX. my simple exmaple is redirect without problem. glxgears has some problem, I don't know, because I have redirected during it was mapped! when redirecting glxgears first the frame of the window manager go a way and secondly the the window of the main (glxgears) is moved to the top left corner and it always white until I kill it or kill my simple composite manager. if the above problem is not releated to Composite I think. Redirection of Server Side GLX rendering is already supported. On Tue, 2004-09-21 at 15:54, Amir Bukhari wrote: I have began to study the GLX code, to see the best way of getting Composite extension to support redirection of GLX. I will concentrate at first on server side code (software rendering). this will be a key to go afterwards to support DRI. I would like to know if there is someone has began this before or plan to work in it, so that we could share ideas! please use this thread to discuss this issue. --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: current DRM CVS
I removed the 2.6 specific code that allowed the DRM major device number to be shared. We can add it back later if needed. I built and checked DRM on both 2.6 and 2.4. It builds and runs without problem. Now would probably be a good time to do the 2.6/2.4 split. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
Alan Cox wrote: Should do. There is a corner case of SMP with only one CPU having SSE but thats already broken in Mesa and many other packages. The more thorough case is you use /dev/cpu/%d/cpuid to check the CPUid on each processor but I'm not sure thats neccessary in reality I had that issue in the back of my mind as well. I ran into this problem while working at Sequent when we got the first quads with MMX capable CPUs. There was no way in ptx to find out which CPUs supported which features. That was particularly annoying to me because we ended up with some engineering development servers that had PentiumPro, Pentium II Xeon, and Pentium III Xeon quads. Anyway, those days are almost as long gone as my Amiga days... ;) --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: latest Mesa radeon crashing out...
Of course my patch is a bit of overkill, we don't need to calculate dest
before calling EnsureCmdBufSpace, I'll fix it later unless Eric gets to it
first
Dave.
I think I tracked it down, after 5 hours or so with Eric on IRC, of course
ten mins after Eric goes to bed I find it ... it seems to fix ipers and my
own application .. Dieter can you check if you can crash with the latest
CVS...
I've committed the following patch:
Index: r200_cmdbuf.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_cmdbuf.c,v
retrieving revision 1.8
diff -u -r1.8 r200_cmdbuf.c
--- r200_cmdbuf.c 22 Sep 2004 06:27:02 - 1.8
+++ r200_cmdbuf.c 23 Sep 2004 08:04:44 -
@@ -127,6 +127,9 @@
dest = rmesa-store.cmd_buf + rmesa-store.cmd_used;
r200EnsureCmdBufSpace( rmesa, rmesa-hw.max_state_size );
+ /* we need to recalculate dest after EnsureCmdBufSpace
+ as we may flush the buffer - airlied */
+ dest = rmesa-store.cmd_buf + rmesa-store.cmd_used;
if (R200_DEBUG DEBUG_STATE) {
foreach( atom, rmesa-hw.atomlist ) {
if ( atom-dirty || rmesa-hw.all_dirty ) {
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb / Linux DECstation / Linux VAX / ILUG person
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
On Iau, 2004-09-23 at 17:21, Philipp Klaus Krause wrote: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4D4E5A16 Function=(null)+0x4D4E5A16 Looks like a buffer overrun or memory corruption. Are you trying to use mesa very threaded ?[at least 0x4D4E5A16 looks like text...] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
pbuffers/superbuffers
Ian, what's the status of the pbuffers/superbuffers work in mesa? How's the new allocator coming along? I've just about got DRM to the point where I can add mode setting to it and integrate printk drawing. With that and superbuffers mesa solo will have it's main features implemented. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Software fallback fixes and R300 driver work
Hi,
apparently I'm the first to use a full software fallback for glClear(), as I
ran into a few problems that the attached patch should fix:
- spantmp.h doesn't check for NULL masks
- add a WriteMonoDepthSpan function to the swrast to driver interface
- use this function to clear the depth buffer in swrast when available
(swrast depth buffer clearing completely ignores driver functions right
now)
I decided to take it to the next level and actually start hacking on a DRI
driver for the R300. So far I modified the R200 driver to recognize the
R300 family and use 100% software fallbacks in this case. I will put source
up as soon as some rasterization is actually hardware accelerated.
One thing I noticed in the process: r200Flush() unconditionally calls
r200EmitState(). Is this really necessary? I was assuming that glFlush()
could be a noop when it's not preceded by any rendering commands.
cu,
Nicolai
Index: drivers/dri/common/depthtmp.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/depthtmp.h,v
retrieving revision 1.2
diff -u -p -r1.2 depthtmp.h
--- drivers/dri/common/depthtmp.h 6 Aug 2003 18:12:22 - 1.2
+++ drivers/dri/common/depthtmp.h 23 Sep 2004 23:27:25 -
@@ -64,6 +64,42 @@ static void TAG(WriteDepthSpan)( GLconte
HW_WRITE_UNLOCK();
}
+static void TAG(WriteMonoDepthSpan)( GLcontext *ctx,
+ GLuint n, GLint x, GLint y,
+ const GLdepth depth,
+ const GLubyte mask[] )
+{
+ HW_WRITE_LOCK()
+ {
+ GLint x1;
+ GLint n1;
+ LOCAL_DEPTH_VARS;
+
+ y = Y_FLIP( y );
+
+ HW_CLIPLOOP()
+ {
+ GLint i = 0;
+ CLIPSPAN( x, y, n, x1, n1, i );
+
+ if ( DBG ) fprintf( stderr, %s %d..%d (x1 %d) = %u\n,
+ __FUNCTION__, (int)i, (int)n1, (int)x1, (uint)depth );
+
+ if ( mask ) {
+ for ( ; i n1 ; i++, x1++ ) {
+ if ( mask[i] ) WRITE_DEPTH( x1, y, depth );
+ }
+ } else {
+ for ( ; i n1 ; i++, x1++ ) {
+ WRITE_DEPTH( x1, y, depth );
+ }
+ }
+ }
+ HW_ENDCLIPLOOP();
+ }
+ HW_WRITE_UNLOCK();
+}
+
static void TAG(WriteDepthPixels)( GLcontext *ctx,
GLuint n,
const GLint x[],
Index: drivers/dri/common/spantmp.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/spantmp.h,v
retrieving revision 1.2
diff -u -p -r1.2 spantmp.h
--- drivers/dri/common/spantmp.h 6 Aug 2003 18:12:22 - 1.2
+++ drivers/dri/common/spantmp.h 23 Sep 2004 23:27:25 -
@@ -123,15 +123,29 @@ static void TAG(WriteRGBAPixels)( const
HW_WRITE_CLIPLOOP()
{
- for (i=0;in;i++)
+ if (mask)
{
- if (mask[i]) {
+ for (i=0;in;i++)
+ {
+ if (mask[i]) {
+ const int fy = Y_FLIP(y[i]);
+ if (CLIPPIXEL(x[i],fy))
+ WRITE_RGBA( x[i], fy,
+ rgba[i][0], rgba[i][1],
+ rgba[i][2], rgba[i][3] );
+ }
+ }
+ }
+ else
+ {
+ for (i=0;in;i++)
+ {
const int fy = Y_FLIP(y[i]);
if (CLIPPIXEL(x[i],fy))
WRITE_RGBA( x[i], fy,
rgba[i][0], rgba[i][1],
rgba[i][2], rgba[i][3] );
- }
+ }
}
}
HW_ENDCLIPLOOP();
@@ -160,9 +174,17 @@ static void TAG(WriteMonoRGBASpan)( cons
{
GLint i = 0;
CLIPSPAN(x,y,n,x1,n1,i);
- for (;n10;i++,x1++,n1--)
- if (mask[i])
+ if (mask)
+ {
+ for (;n10;i++,x1++,n1--)
+ if (mask[i])
+ WRITE_PIXEL( x1, y, p );
+ }
+ else
+ {
+ for (;n10;i++,x1++,n1--)
WRITE_PIXEL( x1, y, p );
+ }
}
HW_ENDCLIPLOOP();
}
@@ -186,12 +208,23 @@ static void TAG(WriteMonoRGBAPixels)( co
HW_WRITE_CLIPLOOP()
{
- for (i=0;in;i++)
- if (mask[i]) {
+ if (mask)
+ {
+ for (i=0;in;i++)
+ if (mask[i]) {
+ int fy = Y_FLIP(y[i]);
+ if (CLIPPIXEL( x[i], fy ))
+ WRITE_PIXEL( x[i], fy, p );
+ }
+ }
+ else
+ {
+ for (i=0;in;i++) {
int fy = Y_FLIP(y[i]);
if (CLIPPIXEL( x[i], fy ))
WRITE_PIXEL( x[i], fy, p );
}
+ }
}
HW_ENDCLIPLOOP();
}
@@ -238,12 +271,23 @@ static void TAG(ReadRGBAPixels)( const G
HW_READ_CLIPLOOP()
{
- for (i=0;in;i++)
- if (mask[i]) {
+ if (mask)
+ {
+ for (i=0;in;i++)
+ if (mask[i]) {
+ int fy = Y_FLIP( y[i] );
+ if (CLIPPIXEL( x[i], fy ))
+ READ_RGBA( rgba[i], x[i], fy );
+ }
+ }
+ else
+ {
+ for (i=0;in;i++) {
int fy = Y_FLIP( y[i] );
if (CLIPPIXEL( x[i], fy ))
READ_RGBA( rgba[i], x[i], fy );
}
+ }
}
HW_ENDCLIPLOOP();
}
Index: swrast/s_depth.c
===
RCS file:
Re: Software fallback fixes and R300 driver work
On Thu, 2004-09-23 at 18:15, Nicolai Haehnle wrote: One thing I noticed in the process: r200Flush() unconditionally calls r200EmitState(). Is this really necessary? I was assuming that glFlush() could be a noop when it's not preceded by any rendering commands. While I suspect this would be legal, note that r200Flush is called from FIREVERTICES, so that emit state that's happening is probably necessary. I had noted this with r200Clear, which depends on state being (semi-?) current at the time of the clear ioctl, and FIREVERTICES and the racefixes should guarantee that. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
R100 state-backup
Same thing as for r200, but for r100. Effects are even better,
according to ipers. Anyone want to do some testing before I commit?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
Index: radeon_compat.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_compat.c,v
retrieving revision 1.3
diff -u -r1.3 radeon_compat.c
--- radeon_compat.c 11 Mar 2004 20:35:41 - 1.3
+++ radeon_compat.c 24 Sep 2004 01:49:57 -
@@ -202,30 +202,28 @@
static void radeonCompatEmitStateLocked( radeonContextPtr rmesa )
{
- struct radeon_state_atom *state, *tmp;
+ struct radeon_state_atom *atom;
if (RADEON_DEBUG (DEBUG_STATE|DEBUG_PRIMS))
fprintf(stderr, %s\n, __FUNCTION__);
- if (rmesa-lost_context) {
- if (RADEON_DEBUG (DEBUG_STATE|DEBUG_PRIMS|DEBUG_IOCTL))
- fprintf(stderr, %s - lost context\n, __FUNCTION__);
+ if (!rmesa-hw.is_dirty !rmesa-hw.all_dirty)
+ return;
- foreach_s( state, tmp, (rmesa-hw.clean) )
- move_to_tail((rmesa-hw.dirty), state );
-
- rmesa-lost_context = 0;
- }
-
- foreach_s( state, tmp, (rmesa-hw.dirty) ) {
- if (!state-is_tcl)
- radeonCompatEmitPacket( rmesa, state );
- move_to_head( (rmesa-hw.clean), state );
+ foreach( atom, rmesa-hw.atomlist ) {
+ if ( rmesa-hw.all_dirty )
+ atom-dirty = GL_TRUE;
+ if ( atom-is_tcl )
+ atom-dirty = GL_FALSE;
+ if ( atom-dirty )
+ radeonCompatEmitPacket( rmesa, atom );
}
+
+ rmesa-hw.is_dirty = GL_FALSE;
+ rmesa-hw.all_dirty = GL_FALSE;
}
-
static void radeonCompatEmitPrimitiveLocked( radeonContextPtr rmesa,
GLuint hw_primitive,
GLuint nverts,
Index: radeon_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_context.c,v
retrieving revision 1.22
diff -u -r1.22 radeon_context.c
--- radeon_context.c 4 Jul 2004 20:33:50 - 1.22
+++ radeon_context.c 24 Sep 2004 01:49:57 -
@@ -306,7 +306,7 @@
DRI_CONF_TEXTURE_DEPTH_32 : DRI_CONF_TEXTURE_DEPTH_16;
rmesa-swtcl.RenderIndex = ~0;
- rmesa-lost_context = 1;
+ rmesa-hw.all_dirty = GL_TRUE;
/* Set the maximum texture size small enough that we can guarentee that
* all texture units can bind a maximal texture and have them both in
Index: radeon_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_context.h,v
retrieving revision 1.15
diff -u -r1.15 radeon_context.h
--- radeon_context.h 17 Aug 2004 01:41:29 - 1.15
+++ radeon_context.h 24 Sep 2004 01:49:57 -
@@ -185,6 +185,7 @@
GLuint is_tcl;
int *cmd; /* one or more cmd's */
int *lastcmd; /* one or more cmd's */
+ int *savedcmd; /* one or more cmd's */
GLboolean dirty; /* dirty-mark in emit_state_list */
GLboolean (*check)( GLcontext * );/* is this state active? */
};
@@ -398,14 +399,11 @@
struct radeon_hw_state {
- /* All state should be on one of these lists:
-*/
- struct radeon_state_atom dirty; /* dirty list head placeholder */
- struct radeon_state_atom clean; /* clean list head placeholder */
+ /* Head of the linked list of state atoms. */
+ struct radeon_state_atom atomlist;
/* Hardware state, stored as cmdbuf commands:
* -- Need to doublebuffer for
-* - reviving state after loss of context
* - eliding noop statechange loops? (except line stipple count)
*/
struct radeon_state_atom ctx;
@@ -428,6 +426,7 @@
struct radeon_state_atom txr[2]; /* for NPOT */
int max_state_size; /* Number of bytes necessary for a full state emit. */
+ GLboolean is_dirty, all_dirty;
};
struct radeon_state {
@@ -733,6 +732,7 @@
drm_clip_rect_t *pClipRects;
unsigned int lastStamp;
GLboolean lost_context;
+ GLboolean save_on_next_unlock;
radeonScreenPtr radeonScreen; /* Screen private DRI data */
drm_radeon_sarea_t *sarea; /* Private SAREA data */
Index: radeon_ioctl.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_ioctl.c,v
retrieving revision 1.13
diff -u -r1.13 radeon_ioctl.c
--- radeon_ioctl.c 17 Aug 2004 20:10:29 - 1.13
+++ radeon_ioctl.c 24 Sep 2004 01:59:47 -
@@ -59,6 +59,65 @@
static void radeonWaitForIdle( radeonContextPtr rmesa );
+static int radeonFlushCmdBufLocked( radeonContextPtr rmesa,
+const char * caller );
+
+void radeonSaveHwState( radeonContextPtr rmesa )
+{
+ struct radeon_state_atom *atom;
+
+ foreach( atom, rmesa-hw.atomlist )
+ memcpy(atom-savedcmd, atom-cmd, atom-cmd_size * 4);
+}
+
+static void radeonSwapHwState( radeonContextPtr rmesa )
+{
+ int *temp;
+ struct radeon_state_atom *atom;
+
+
Re: Software fallback fixes and R300 driver work
On Fri, 24 Sep 2004 03:15:01 +0200, Nicolai Haehnle [EMAIL PROTECTED] wrote: Hi, apparently I'm the first to use a full software fallback for glClear(), as I ran into a few problems that the attached patch should fix: - spantmp.h doesn't check for NULL masks - add a WriteMonoDepthSpan function to the swrast to driver interface - use this function to clear the depth buffer in swrast when available (swrast depth buffer clearing completely ignores driver functions right now) I decided to take it to the next level and actually start hacking on a DRI driver for the R300. So far I modified the R200 driver to recognize the R300 family and use 100% software fallbacks in this case. I will put source up as soon as some rasterization is actually hardware accelerated. If you have a 100% software driver that works that might be a good starting point for a software DRI driver to ween ourselves off GLcore and eventually allow for accelerated indirect rendering. Alex One thing I noticed in the process: r200Flush() unconditionally calls r200EmitState(). Is this really necessary? I was assuming that glFlush() could be a noop when it's not preceded by any rendering commands. cu, Nicolai --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
