Re: New ioctl for surface allocation/deallocation
Dave Airlie wrote: Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback (both on the idea and the implementation) before I build anything upon it. I'm thinking this could be applicable to a number of devices, so maybe a generic ioctl might be a better idea with some card specific hooks.. Or is there something radeon specific about it I missed... This ties in directly to the idea of a generalized memory manager for the DRI drivers, something that I should be able to get some time to look into fairly shortly. It's not clear what is being allocated in the patch except for a unique number - what is the number used for after that? There's already the equivalent level of trust exported to the clients in the existing interfaces to allow them to manage a shared bitfield themselves in the SAREA shared area using the drm lock for serialization. The aspect missing from both your implementation and the SAREA-based bitflag is that there is no way to free bits in your bitflag which are held by contexts in processes which die without clearing their bits, eg. by segfault. Keith --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2010] depth and stencil readback are broken beyond x 1023
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2010 --- Additional Comments From [EMAIL PROTECTED] 2004-12-08 03:49 --- The 2047 limit is iirc the maximum size you can specify for a radeon cliprect, maybe other hardware limitations as well. The artificial mesa limits aren't artificial at all but are the result of limitations in interpolating values across large triangles in the software rasterizer. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1678] Direct Rendering problems on IGP 320M
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=1678 --- Additional Comments From [EMAIL PROTECTED] 2004-12-08 04:05 --- I am also affected by this bug on My AmiloA (details at http://rzr.online.fr/q/AmiloA ) btw I know dri works on this IGP320M on some HP Laptop . Now, this may be offtopic or not, Samuel Verschelde compared the IRQ assignement beetwin windows and linux... I also adeed those for HP laptop : http://rzr.online.fr/q/IRQ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New ioctl for surface allocation/deallocation
Michel Dnzer wrote:
+ // allocate the surface
+ for(i=0;i8;i++)
+ if (!(dev_priv-surfaces(1i)))
+ break;
+
+ if (i=8)
+ return DRM_ERR(ENOMEM);
+ else
+ dev_priv-surfaces=(1i);
+
+ if ( DRM_COPY_TO_USER( alloc.surface, i,
+ sizeof(int) ) ) {
+ DRM_ERROR( copy_to_user\n );
+ return DRM_ERR(EFAULT);
IMHO it should also manage the ranges (prevent overlapping, ...) and
parameters of the surfaces.
Ok, that was one of my doubts.
So if we go that route, it would manage the ranges, prevent overlapping,
and also try to spare the surfaces by merging adjacent ones with
similar properties.
+ DRM_COPY_FROM_USER_IOCTL( memfree, (drm_radeon_mem_free_t __user *)data,
+ sizeof(memfree) );
+
+ dev_priv-surfaces= (~(1memfree.surface));
It should definitely ensure that only the owner can free a surface
though. It would also need to free a client's surfaces if it dies, etc.
How do you know the owner ? I'm not sure the pid would be enough.
Stephane
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New ioctl for surface allocation/deallocation
Dave Airlie wrote: Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback (both on the idea and the implementation) before I build anything upon it. I'm thinking this could be applicable to a number of devices, so maybe a generic ioctl might be a better idea with some card specific hooks.. Or is there something radeon specific about it I missed... If we decide to manage the surface ranges too, there is something radeon-specific. Also what other things could be managed by such an ioctl ? Stephane --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New ioctl for surface allocation/deallocation
Keith Whitwell wrote: Dave Airlie wrote: Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback (both on the idea and the implementation) before I build anything upon it. I'm thinking this could be applicable to a number of devices, so maybe a generic ioctl might be a better idea with some card specific hooks.. Or is there something radeon specific about it I missed... This ties in directly to the idea of a generalized memory manager for the DRI drivers, something that I should be able to get some time to look into fairly shortly. It's not clear what is being allocated in the patch except for a unique number - what is the number used for after that? It's supposed to be the surface number : it gives you a surface between RADEON_SURFACE0* and RADEON_SURFACE7* and then allows you playing with LOWER/UPPER. There's already the equivalent level of trust exported to the clients in the existing interfaces to allow them to manage a shared bitfield themselves in the SAREA shared area using the drm lock for serialization. The aspect missing from both your implementation and the SAREA-based bitflag is that there is no way to free bits in your bitflag which are held by contexts in processes which die without clearing their bits, eg. by segfault. Hmm, I thought about this but wasn't sure if that was a problem. How can this be solved ? Stephane --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New ioctl for surface allocation/deallocation
Stephane Marchesin wrote: Keith Whitwell wrote: Dave Airlie wrote: Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback (both on the idea and the implementation) before I build anything upon it. I'm thinking this could be applicable to a number of devices, so maybe a generic ioctl might be a better idea with some card specific hooks.. Or is there something radeon specific about it I missed... This ties in directly to the idea of a generalized memory manager for the DRI drivers, something that I should be able to get some time to look into fairly shortly. It's not clear what is being allocated in the patch except for a unique number - what is the number used for after that? It's supposed to be the surface number : it gives you a surface between RADEON_SURFACE0* and RADEON_SURFACE7* and then allows you playing with LOWER/UPPER. There's already the equivalent level of trust exported to the clients in the existing interfaces to allow them to manage a shared bitfield themselves in the SAREA shared area using the drm lock for serialization. The aspect missing from both your implementation and the SAREA-based bitflag is that there is no way to free bits in your bitflag which are held by contexts in processes which die without clearing their bits, eg. by segfault. Hmm, I thought about this but wasn't sure if that was a problem. How can this be solved ? Associate the allocated resources with the filp of the connection which was granted them (note: NOT the pid), and when that connection closes, deallocate the resource. Keith --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New ioctl for surface allocation/deallocation
--- Stephane Marchesin [EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
+ // allocate the surface
+ for(i=0;i8;i++)
+ if (!(dev_priv-surfaces(1i)))
+ break;
+
+ if (i=8)
+ return DRM_ERR(ENOMEM);
+ else
+ dev_priv-surfaces=(1i);
+
+ if ( DRM_COPY_TO_USER( alloc.surface, i,
+ sizeof(int) ) ) {
+ DRM_ERROR( copy_to_user\n );
+ return DRM_ERR(EFAULT);
IMHO it should also manage the ranges (prevent overlapping, ...) and
parameters of the surfaces.
Ok, that was one of my doubts.
So if we go that route, it would manage the ranges, prevent overlapping,
and also try to spare the surfaces by merging adjacent ones with
similar properties.
+ DRM_COPY_FROM_USER_IOCTL( memfree, (drm_radeon_mem_free_t __user
*)data,
+ sizeof(memfree) );
+
+ dev_priv-surfaces= (~(1memfree.surface));
It should definitely ensure that only the owner can free a surface
though. It would also need to free a client's surfaces if it dies, etc.
How do you know the owner ? I'm not sure the pid would be enough.
I'm sure there is a better way, also keep inmind GLX-remote direct
rendering.
For now using the PID to get the UID and EUID would allow any process by
that user to dealloc the reasource(for threaded programs).
Stephane
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
__
Do you Yahoo!?
All your favorites on one personal page Try My Yahoo!
http://my.yahoo.com
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1501] libGL causes double free.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=1501 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #1013|approval_X11R6.8.x? |approval_X11R6.8.x+ Flag|| --- Additional Comments From [EMAIL PROTECTED] 2004-12-08 05:48 --- (From update of attachment 1013) Approved in the 2004-12-06 release-wranglers conference call. Please do not commit it yourself, I'll do that later today... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Why does radeon dri not allow page flipping?
The file radeon_dri.c sets several defaults in the radeon's private data. ctx-driverPrivate = (void *)info; info-gartFastWrite = RADEON_DEFAULT_AGP_FAST_WRITE; info-gartSize = RADEON_DEFAULT_AGP_SIZE; info-gartTexSize= RADEON_DEFAULT_AGP_TEX_SIZE; info-bufSize = RADEON_DEFAULT_BUFFER_SIZE; info-ringSize = RADEON_DEFAULT_RING_SIZE; info-page_flip_enable = RADEON_DEFAULT_PAGE_FLIP; There seems to be no way to configure my r200 to do page flipping! I've hacked the last line above to force page_flip_enable=1, and the page flipping seems to work with my tests, but this begs the question - Is there some other reason that page flipping is disabled (and cannot be re-enabled by configuration settings)? In other words, will the driver fail miserably under some conditions which I have not tried? I am using mesa linux-solo and radeonfb (miniglx). My application requires strict phase-locking with the video refresh rate. I can achieve this without page flipping, but the back-to-front buffer copy takes too long and I get a tear. Page flipping cleans this up nicely and my app happily marches in lockstep with the video refresh, no tears, just like the baby shampoo. I'd like to add a setting to miniglx.conf, enablePageFlip - something like I can put in my xorg.conf under my r200's Device section. I'd be glad to submit a patch if someone can give me a little guidance on the mechanics of creating the patch. Thanks, Dan --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Why does radeon dri not allow page flipping?
Daniel Sperka wrote: The file radeon_dri.c sets several defaults in the radeon's private data. ctx-driverPrivate = (void *)info; info-gartFastWrite = RADEON_DEFAULT_AGP_FAST_WRITE; info-gartSize = RADEON_DEFAULT_AGP_SIZE; info-gartTexSize= RADEON_DEFAULT_AGP_TEX_SIZE; info-bufSize = RADEON_DEFAULT_BUFFER_SIZE; info-ringSize = RADEON_DEFAULT_RING_SIZE; info-page_flip_enable = RADEON_DEFAULT_PAGE_FLIP; There seems to be no way to configure my r200 to do page flipping! I've hacked the last line above to force page_flip_enable=1, and the page flipping seems to work with my tests, but this begs the question - Is there some other reason that page flipping is disabled (and cannot be re-enabled by configuration settings)? In other words, will the driver fail miserably under some conditions which I have not tried? I am using mesa linux-solo and radeonfb (miniglx). My application requires strict phase-locking with the video refresh rate. I can achieve this without page flipping, but the back-to-front buffer copy takes too long and I get a tear. Page flipping cleans this up nicely and my app happily marches in lockstep with the video refresh, no tears, just like the baby shampoo. I'd like to add a setting to miniglx.conf, enablePageFlip - something like I can put in my xorg.conf under my r200's Device section. I'd be glad to submit a patch if someone can give me a little guidance on the mechanics of creating the patch. I think quite simply no-one's taken the time to pull the pageflipping code into mesa-solo and/or test it - so it looks like you get the honor... I'd like to see this controlled by an option in the config file rather than forcing one behaviour or another. I'd also like to know that multiple apps continue to play nicely together (as much as they ever did). To get a patch from your local tree, cvs diff -u should do the trick. Keith --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New ioctl for surface allocation/deallocation
Stephane Marchesin wrote: Michel Dnzer wrote: +DRM_COPY_FROM_USER_IOCTL( memfree, (drm_radeon_mem_free_t __user *)data, + sizeof(memfree) ); + +dev_priv-surfaces= (~(1memfree.surface)); It should definitely ensure that only the owner can free a surface though. It would also need to free a client's surfaces if it dies, etc. How do you know the owner ? I'm not sure the pid would be enough. The same way everything else in the DRM does: using the caller's file pointer (filp). --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Why does radeon dri not allow page flipping?
There seems to be no way to configure my r200 to do page flipping! I've hacked the last line above to force page_flip_enable=1, and the page flipping seems to work with my tests, but this begs the question - Is there some other reason that page flipping is disabled (and cannot be re-enabled by configuration settings)? In other words, will the driver fail miserably under some conditions which I have not tried? Well I was the one that disabled it by default about 6 months ago as on a Radeon 7500 it just didn't work without noisy effects on screen.. I forgot to add it to the config file, I'd like to add a setting to miniglx.conf, enablePageFlip - something like I can put in my xorg.conf under my r200's Device section. I'd be glad to submit a patch if someone can give me a little guidance on the mechanics of creating the patch. Take a look at my checkin that added agpmode support .. it should be something similiar or the PCI patch I checked in yesterday... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: new hyperz patch
Am Mittwoch, 8. Dezember 2004 00:27 schrieb Roland Scheidegger:
Dieter Nützel wrote:
True for DoomIII, but who can switch the lights ON, finally...?
;-)
That is some weird texcoord problem. (I actually have a one-line
workaround for that, which breaks submitting texgen and non-texgen
coordinates at the same time more or less completely).
Let me test.
Attached. I've also included the 2nd one-liner in this patch, don't know
if it changes anything with doom3 (but using swtcl fallback for
gl_sphere_map is very problematic at least in nwn).
Will try it later. Maybe in a few minutes ;-)
'Zooming' a 3D VTK prog from the upper left corner into a bigger
window in the desktop middle show missing z/buffer
clearing/redraw.
Was OK before.
Hmm, do you have a screenshot of that (or preferably more than one,
I'm interested what happens when you move the window from top-left
to top-right, bottom-left and bottom-right)?
No zoom, then nothing.
So if you only move the window, everything is ok? That's weird.
Yes.
Even after CVS merge.
After zoom only the lower, left part of the window would be redrawn
right. In all places.
See our domain ;-)
http://www.nuetzel-hh.de/public
Looks like if you zoom the window, someone forgets to tell the driver
the new window size. Are you sure this is caused by hyperz,
No.
But worked before.
Even with Mesa only.
Pageflip do not change it but gave good snapshot:
http://www.nuetzel-hh.de/public/VTK-TaskParallelism-zoom-middle-CVS.png
Normal desktop background and 3D stuff isn't cleared/wouldn't be redrawn.
But this one shows, that sometimes the most near 3D pixel will be drawn.
http://www.nuetzel-hh.de/public/VTK-TaskParallelism-zoom-middle-CVS1.png
i.e. if you
use hyperz=false it still is wrong?
Yes.
I'm wondering if it could be ddx-related (you're still using XFree86
4.3.99 something, right?)
Right.
Should I play with the clearmask, again?
No, not unless you're serious about implementing a real
hierarchical-z solution.
Maybe I'm somewhat unclear, here.
I mean this one:
--- radeon_state.c.orig 2004-11-11 22:08:37.0 +0100 +++
radeon_state.c.aktuell 2004-11-13 14:08:32.0 +0100 @@
-894,7 +894,8 @@ } else { /* FIXME : reverse engineer that for Rx00
cards */ - clearmask = (0xff22)|(0xff6)|
0x003f003f; + /* clearmask =
(0xff22)|(0xff6)| 0x003f003f; */ + clearmask = 0x0;
Well, with the new patch the clearmask used is always 0 (values other
than 0 make afaik only sense for hyperz).
I never had these pattern before.
[Bug 2010] New: depth and stencil readback are broken beyond x
1023 Fix do not show any changes. zreaddraw is corrupted even
with screen redraw.
Do you mean with hyperz?
Of course ;-)
With hyperz off, too.
http://www.nuetzel-hh.de/public/zreaddraw.png
http://www.nuetzel-hh.de/public/zreaddraw1.png
http://www.nuetzel-hh.de/public/zreaddraw-after-move-out-right.png
That's to be expected (at least for now). That bug 2010 depth
readback problem is meant for cases without hyperz.
I see.
It definitely is a problem, but for now it is an expected one :-).
Have a look into SPECViewperf 7.1.2/8.0.1 _ugs_, too. Depth is
mostly broken there, too.
Works perfect (though slow as always...) for me (7.1). Screenshot?
With and without hyperz. (maybe unrelated).
If it is also without hyperz then it most likely is unrelated.
Seems to be fixed, now.
The mask fix?
Depth and clear (?) is broken.
http://www.nuetzel-hh.de/public/ugs02QualityFull.png
I'm not quite sure what this picture should look like, I don't have one
with that name.
All with 7.1.1.
The whole list is long and big (size: 21,1 MB)...
ugs01-xxx to ugs08-xxx
...when it run without error ;-)
There is superimposed KDE mask.
But pageflip=false SOLVED it. (see below)
http://www.nuetzel-hh.de/public/ugs03Full.png
Looks somewhat wrong.
Wrong alpha?
I definitely get a different ugs03Full.png - or is
that a 8.0 pic?
No. 7.1.1
E.g. depth would be wrapped on 'big' desktops (1280x1024x24/32).
http://www.nuetzel-hh.de/public/ugs06Full-depth.png
That is indeed most certainly bug 2010 (i.e. it's only wrapped when read
back).
Solved. (see above)
With viewperf-smp I get mostly empty/black windows with ugsXXX.
btw are you using pageflip? I couldn't get correct screenshots with
viewperf with it enabled, though I haven't tried for a while.
dito
Superimposed KDE stuff is gone.
-Dieter
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
linux-solo-x86 r200 build broken
Just checked out Mesa from CVS and attempted a build. It fails in src/mesa/drivers/dri/r200 -- portion of build log below. It appears that there are two files named 'radeon.h' in the -I dirs for the build of r200_dri.c. One is the one we need, but the other is in the drm folders. The drm folder (../../../../../../drm/shared) appears first on the command line, hence it is picked up. Its not the right file, though, so the build fails (but there's no indication of a missing .h file). I had a CVS checkout from a couple weeks ago and there was a change in the Makefile in src/mesa/drivers/dri/r200. I tried to replace the 'suspect' Makefile with the Makefile from my old CVS, but that build fails with a different error -- which refers to a DRM_* macro. It would appear that BOTH 'radeon.h' files are required (somewhere) in this build, but only one gets picked up. What has changed? Dan -- Command line from build using today's CVS make linux-solo-x86 cut - gcc -c -I../../../../../src/glx/mini -I../../../../../../drm/shared -I../../../. ./../../drm/libdrm -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I. ./../../../../../drm/shared -I../../../../../../drm/linux -I../../../../../inclu de -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../ ../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../ ../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -I../radeon/server -DDRI_NEW_INTERFACE_ONLY -D_POSIX_SOURCE -D_SVID_SOURCE -D_BSD_SOURCE -D_POSIX_C _SOURCE=199309L -D_GNU_SOURCE -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_ SSE_ASM -DPTHREADS -Wmissing-prototypes -O3 -g -std=c99 -Wundef -fPIC -ffast-mat h -DGLX_DIRECT_RENDERING server/radeon_dri.c -o server/radeon_dri.o server/radeon_dri.c: In function `RADEONEngineRestore': server/radeon_dri.c:160: error: `RADEONInfoPtr' undeclared (first use in this fu nction) server/radeon_dri.c:160: error: (Each undeclared identifier is reported only onc e --- Command line from build using today's CVS (with older makefile src/mesa/drivers/dri/r200/Makefile) make linux-solo-x86 cut - gcc -c -I../../../../../src/glx/mini -I../../../../../../drm/shared -I../../../. ./../../drm/libdrm -I. -I../../../../../src/mesa/drivers/dri/common -Iserver -I. ./../../../../../drm/shared -I../../../../../../drm/linux -I../../../../../inclu de -I../../../../../include/GL/internal -I../../../../../src/mesa -I../../../../ ../src/mesa/main -I../../../../../src/mesa/glapi -I../../../../../src/mesa/math -I../../../../../src/mesa/transform -I../../../../../src/mesa/shader -I../../../ ../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup -DDRI_NEW_INTERFACE _ONLY -D_POSIX_SOURCE -D_SVID_SOURCE -D_BSD_SOURCE -D_POSIX_C_SOURCE=199309L -D_ GNU_SOURCE -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DPTHREADS -Wmissing-prototypes -O3 -g -std=c99 -Wundef -fPIC -ffast-math -DGLX_DIRECT_REND ERING server/radeon_dri.c -o server/radeon_dri.o server/radeon_dri.c: In function `RADEONDRIPciInit': server/radeon_dri.c:447: error: `DRM_PAGE_SIZE' undeclared (first use in this fu nction) --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: linux-solo-x86 r200 build broken
command line, hence it is picked up. Its not the right file, though, so the build fails (but there's no indication of a missing .h file). I had a CVS checkout from a couple weeks ago and there was a change in the Makefile in src/mesa/drivers/dri/r200. I tried to replace the 'suspect' Makefile with the Makefile from my old CVS, but that build fails with a different error -- which refers to a DRM_* macro. two bugs.. the PCI code wasnt completely uptodate with the changes to pagesize that Jon checked in, and Keiths Makefile changes messed up the include order (Keith I've reverted the change to the r200 Makefile you made as it stsops solo from building)... Should be okay now ... Dave. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon dynamic clocking with fb and X
Hardware: Mobility M7 7500 reference board from ATI on a PIII i815. Software: Mesa solo about 4mths old running on a 2.6.9 with voluntary preempt I'm running a single full screen 3D app and every so often my graphics cards locks up either hard or the CP craps out and locks out, now I'm thinking through various things that may cause these types of lockups and trying to rule them out... I notice in the Xorg dynamic clocks stuff the comment /* When DRI is enabled, setting DYN_STOP_LAT to zero can cause some R200 to lockup randomly, leave them as set by BIOS. */ Now my question is when the radeonfb sets the dynamic clocks does it do something similiar? or this workaround there already? I know my card ain't an r200 and all that but I'm grasping straws... it may also me my card overheating but I've got a good fan pointed across it at the moment... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
