Re: [Dri-devel] Annouce: Major update of the FAQ
José Fonseca wrote: > I've just updated the FAQ. Besides of including the new section > about binary compatibility from Jens Owen I also added a new top > section focusing on the implementation details, including new > material covering topics such as texture management, Mesa's graphics > pipeline and clipping. > > Now the DRI website also has the FAQ in other formats, available on > http://dri.sourceforge.net/doc/faq/other-formats/. > Hello I just noticed that the link in section 5.1.3 to the ATI AGP faq points to a 'page not found' :-( Maybe it have moved but maybe it has been simply removed. BTW, a copy of the 'testgart' program is on my web page, and the FAQ points to it (which is fine to me), but it may be a neat idea to have it also in the 'resources' of the DRI page, just to avoid the painful search to find a copy when I needed it... a+ -- Nicolas Aspert Signal Processing Institute (ITS) Swiss Federal Institute of Technology (EPFL) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Joining efforts
Every time I refer to Utah-GLX code I can't avoid to think about the enormous amount of duplication that would be to maintain a completely different set of OpenGL drivers. Regardless of the OS the code in libGL (meaning the Mesa driver) should be about 99% the same. I know that main reason for resuming the development of Utah-GLX was the difficulties involved in porting the DRM to others OS, such as Solaris. But why not reuse the DRI's Mesa and DXX drivers code and port and/or remake a stripped-down DRM, i.e., without the security enforcement and with the same requirements in Utah-GLX of root and single fullscreen operation? This would allow the Solaris to benefit from all the DRI code and its updates, and the DRI project would benefit of the sinergy of the Utah-GLX developers. This would also be step forward to have full support of Solaris in DRI. I would really like to see this happens as I believe it would benefit us all. Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Annouce: Major update of the FAQ
On Mon, 2002-04-15 at 11:33, Nicolas Aspert wrote: > ... > > Hello > > I just noticed that the link in section 5.1.3 to the ATI AGP faq points > to a 'page not found' :-( Maybe it have moved but maybe it has been > simply removed. It seems that ATI has redesigned its developer relation contents. I'll see if I can find that page and either update or remove the link. > BTW, a copy of the 'testgart' program is on my web page, and the FAQ > points to it (which is fine to me), but it may be a neat idea to have it > also in the 'resources' of the DRI page, just to avoid the painful > search to find a copy when I needed it... I also have a copy myself, but it's a good idea to have it on the DRI website. > > a+ > -- > Nicolas Aspert Signal Processing Institute (ITS) > Swiss Federal Institute of Technology (EPFL) > Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 PCI support added to 2D driver
"José Fonseca" wrote: > On 2002.04.13 04:36 Leif Delgass wrote: > > On Thu, 11 Apr 2002, José Fonseca wrote: > > > > Do we know for sure that pci gart is supported on mach64? The rage 128 > > and radeon drivers both write to PCI GART registers, but I don't see > > anything analogous in the Rage PRO docs. My understanding is that to use > > the scatter/gather memory, the card has to implement it's own address > > translation table. Your checkin adds allocation of scatter/gather > > memory, but can PCI mach64 use this memory? > > FINALLY dri/mach64 runs on my sony PCG-C1VP (no AGP guaranteed :-) This is a major step forward for me ... Do you need any info Just tell me and I send it to you. THANKS /Tony Some info anyway (it always crashed in the output before, now it run out of the box): Apr 15 14:58:17 localhost kernel: [drm] Initialized mach64 1.0.0 20010107 on minor 0 Apr 15 14:59:10 localhost kernel: [drm] SRC_CNTL = 0x Apr 15 14:59:10 localhost kernel: [drm] Apr 15 14:59:10 localhost kernel: [drm] data = 0x002ec000 Apr 15 14:59:10 localhost kernel: [drm] table = 0x4000 Apr 15 14:59:10 localhost kernel: [drm] starting DMA transfer... Apr 15 14:59:10 localhost kernel: [drm] starting DMA transfer... done. Apr 15 14:59:10 localhost kernel: [drm] waiting for idle [locked_after_dma??]...Apr 15 14:59:10 localhost kernel: [drm] (After DMA Transfer) PAT_REG0 = 0x Apr 15 14:59:10 localhost kernel: [drm] freeing memory. Apr 15 14:59:10 localhost kernel: [drm] returning ... ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 PCI support added to 2D driver
On Mon, 2002-04-15 at 14:19, Tony Rogvall wrote: > "José Fonseca" wrote: > > > On 2002.04.13 04:36 Leif Delgass wrote: > > > On Thu, 11 Apr 2002, José Fonseca wrote: > > > > > > Do we know for sure that pci gart is supported on mach64? The rage 128 > > > and radeon drivers both write to PCI GART registers, but I don't see > > > anything analogous in the Rage PRO docs. My understanding is that to use > > > the scatter/gather memory, the card has to implement it's own address > > > translation table. Your checkin adds allocation of scatter/gather > > > memory, but can PCI mach64 use this memory? > > > > > FINALLY > > dri/mach64 runs on my sony PCG-C1VP (no AGP guaranteed :-) > This is a major step forward for me ... > > Do you need any info Just tell me and I send it to you. > No. To know that it worked fine is enough! I makes it worth that I stayed awake until 2:00 AM last night debugging all this. > THANKS > You're welcome. You have yourself to thank for too because if it wasn't your shown interest and your keen debugging of that kernel issue this day would happen much later! > /Tony > Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new Radeon DRI driver binaries not compatible with SuSE
Martin Spott wrote: > > > If you can ssh in, can you run the program from gdb from a ssh session? > > Just to prevent you from thinking I overlooked this posting > I did a few tries with gdb yesterday but I didn't see the expected result. > This is to say, 'gdb' was pretty quiet at all, so I might have made some > mistake. I'll tell you the results as soon as I have acommodated with 'gdb', Martin, If you're wrestling with a timing related bug--then it can disappear with simple changes in the system. Running a debugable version can add enough overhead to make the problem go away. If it's timing related, and you can't reliably reproduce the problem with a debugable binary, or with gdb. Then try attaching gdb to the process after the hang. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [utah-glx-dev] Joining efforts
On Mon, Apr 15, 2002 at 12:35:41PM +0100, Jose Fonseca wrote: > I know that main reason for resuming the development of Utah-GLX was the > difficulties involved in porting the DRM to others OS, such as Solaris. > > But why not reuse the DRI's Mesa and DXX drivers code and port and/or > remake a stripped-down DRM, Mesa is not part of DRI. When Utah-GLX moves to Mesa 4.x, it will be using the same Mesa code as DRI. I'd love to SEE a solaris port of DRM. However, I'm not willing to do it. You can count the number of people who are Solaris driver-writing "free agents" on one hand. Now try to find one of the other four(3?), and try to convince them to put in the amount of time and hassle required to port the DRI kernel stuff. DRI does not lend itself easily to being ported. Nor do I want to try swimming upstream to make a port happen. DRI is way too linux-centric right now. When and if DRI was rearchitectured to be more platform-netral (Just one example would be: identifying and moving common routines into an actual common area, rather than hacks like the BSD "driver" linking from ../linux) then I or one of the other solaris developers would be more inclined to do the port. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [utah-glx-dev] Joining efforts
On Mon, 2002-04-15 at 17:46, Philip Brown wrote: > On Mon, Apr 15, 2002 at 12:35:41PM +0100, Jose Fonseca wrote: > > I know that main reason for resuming the development of Utah-GLX was the > > difficulties involved in porting the DRM to others OS, such as Solaris. > > But why not reuse the DRI's Mesa and DXX drivers code and port and/or > > remake a stripped-down DRM, > > Mesa is not part of DRI. I'm aware of that. I didn't meant Mesa itself, but the Mesa _drivers_ (the "drivers" in the above sentence applied to both "Mesa" and "DDX"), such as mach64_dri.so, r128_dri.so, tdfx_dri.so, etc... which are part of DRI. > When Utah-GLX moves to Mesa 4.x, it will be using the same Mesa code as > DRI. > Again, are you referring to Mesa's code or its drivers? > I'd love to SEE a solaris port of DRM. > However, I'm not willing to do it. > You can count the number of people who are Solaris driver-writing > "free agents" on one hand. Now try to find one of the other four(3?), > and try to convince them to put in the amount of time and hassle required > to port the DRI kernel stuff. > Well, considering all the amount of time and hassle required to maintain a different set of Mesa drivers, I thought it would be worth it... > DRI does not lend itself easily to being ported. > Nor do I want to try swimming upstream to make a port happen. > DRI is way too linux-centric right now. > When and if DRI was rearchitectured to be more platform-netral > (Just one example would be: > identifying and moving common routines into an actual > common area, rather than hacks like the BSD "driver" linking > from ../linux) > then I or one of the other solaris developers would be more inclined to do > the port. > Again, I was thinking of just an shorthand DRM that would allow to use the *_dri.so and the *_drv.o in Solaris, and not a full featured port... I still don't understand how it's not worth to work on this but have separate equivalent code is. Well, it was just my two cents... Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] A question for tonight...
I have been looking into the DRM's DMA/CCE/CP initialization subroutines
(those named *_do_init{dma,cce,cp} ) of the current DRI drivers, and I
still don't know how they protect themselves from making faults due to
bad initialization parameters. Since I this is a little complicated to
put over IRC I'm sending this email to prepare you for tonight...
The first question is why the dev->dev_private initializition is delayed
until the last moment of exiting these subroutines. Taking the Radeon
code as example, why is radeon_do_init_cp (radeon_cp.c:668) full of
statements like
dev->dev_private = (void *)dev_priv;
instead of a single on right after dev_priv allocation (as done before)?
Is this subroutine reentrant? Even if it is, how does this solve the
problem?
The other thing is in r128_do_cleanup_cce. This subroutine is called by
r128_do_init_cce in case of failure as in
DRM_FIND_MAP( dev_priv->buffers, init->buffers_offset );
if(!dev_priv->buffers) {
DRM_ERROR("could not find dma buffer region!\n");
dev->dev_private = (void *)dev_priv;
r128_do_cleanup_cce( dev );
return -EINVAL;
}
but if indeed dev_priv->buffers is NULL, won't the following code in
128_do_cleanup_cce generate a segfault?
if ( !dev_priv->is_pci ) {
DRM_IOREMAPFREE( dev_priv->cce_ring );
DRM_IOREMAPFREE( dev_priv->ring_rptr );
DRM_IOREMAPFREE( dev_priv->buffers );
} else {
since as said in a previous email of mine DRM_IOREMAPFREE doesn't check
if its argument is NULL, on the contrary it references it before passing
it to ioremapfree:
#define DRM_IOREMAPFREE(map) \
do { \
if ( (map)->handle && (map)->size )\
DRM(ioremapfree)( (map)->handle, (map)->size );\
} while (0)
So isn't there a bug here as well or I'm missing something?
Just in case you may be thinking that this can be fairly uncommon this
situation occurs when the init structure changes. So everytime there is
a versioning problem in the DRM, libdrm.a or DDX which involves a change
on the init structure this will most likely to occur and, at least on my
systems, it locks mach64.o on the kernel, and only a reset can allow
normal operation again.
Jose Fonseca
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM causes video lock on virtual console switching
On Mon, 2002-04-15 at 00:15, Allen H. Ibara wrote: > > Hmm. Can you try without AGP? You'll have to rebuild the DRM kernel > > module and the 2D driver with the #define PCIGART_ENABLED active for > > that to work, and apparently there are other instabilities without AGP > > on i386, so it might be hard to make any conclusions, but I think it's > > worth a try. > > Ok, I finally got an X server and radeon modules built (from dri cvs trunk > pulled this morning) with PCIGART_ENABLED defined in 'radeon_dri.c' and > 'radeon_cp.c', and the agpgart kernel module disabled and removed. > > Unfortunately it dies (hangs with no warning) quickly after startup, before I > can tell it to switch VTs, and thus can't actually tell if disabling AGP > prevented the problem or not. After X hangs, I can SIGKILL XFree86, > but eventually have to reboot in order get the console back. Does it hang before anything is drawn or afterwards? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Bug in gamma DRM
When I found what I believe to be a bug in gamma DRM which could lead to a
kernel oops on PCI cards.
The line is gamma_dma.c:669:
DRM_IOREMAPFREE( dev_priv->buffers );
but dev_priv->buffers has a non-NULL value only if it's not a PCI card, as
seen in gamma_dma.c:625:
if (init->pcimode) {
...
} else {
DRM_FIND_MAP( dev_priv->buffers, init->buffers_offset );
DRM_IOREMAP( dev_priv->buffers );
...
(remember that the dev_priv structure is set to 0 in the beginning)
and the definition of DRM_IOREMAPFREE is
#define DRM_IOREMAPFREE(map)\
do {\
if ( (map)->handle && (map)->size ) \
DRM(ioremapfree)( (map)->handle, (map)->size ); \
} while (0)
so it will attempt to reference a NULL pointer (as it did on my system
with the mach64).
The code at gamma_dma.c:669 should be instead
if( dev_priv->buffers ) {
DRM_IOREMAPFREE( dev_priv->buffers );
}
José Fonseca
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bug in gamma DRM
Thanks for finding that. You can apply the patch.
Although the cleanup_dma function isn't used at all in the gamma
driver yet (it should be - I know), but the AGP code hasn't been
tested a whole lot either.
Alan.
On Sun, Apr 14, 2002 at 11:00:02 +0100, Jos Fonseca wrote:
> When I found what I believe to be a bug in gamma DRM which could lead to a
> kernel oops on PCI cards.
>
> The line is gamma_dma.c:669:
>
> DRM_IOREMAPFREE( dev_priv->buffers );
>
> but dev_priv->buffers has a non-NULL value only if it's not a PCI card, as
> seen in gamma_dma.c:625:
>
> if (init->pcimode) {
>
> ...
>
> } else {
> DRM_FIND_MAP( dev_priv->buffers, init->buffers_offset );
>
> DRM_IOREMAP( dev_priv->buffers );
>
> ...
>
> (remember that the dev_priv structure is set to 0 in the beginning)
>
> and the definition of DRM_IOREMAPFREE is
>
> #define DRM_IOREMAPFREE(map)\
> do {\
> if ( (map)->handle && (map)->size ) \
> DRM(ioremapfree)( (map)->handle, (map)->size ); \
> } while (0)
>
>
> so it will attempt to reference a NULL pointer (as it did on my system
> with the mach64).
>
> The code at gamma_dma.c:669 should be instead
>
> if( dev_priv->buffers ) {
> DRM_IOREMAPFREE( dev_priv->buffers );
> }
>
> Jos Fonseca
>
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRM causes video lock on virtual console switching
> > I reported a problem to the gatos list a long while back that > > I think may be related. (I thought it was strictly a gatos > > thing, but have no idea, so I'll share it now). > > I'm running X from cvs (old, but post 4.2.0) on my radeon 64mb. > > Once I've run _any_ gl app, if I attempt to run xawtv, or use > > mtv, it hangs the entire system. I just recently noticed that > > the same thing occurs after switching to a vt and back--attempts > > to watch video cause a system hang. > > Exiting X entirely and restarting it at least makes it possible > > to watch video after having used a gl app. > >=20 > > So now I wonder if it's just X related and not gatos or dri > > specific. > > Have you tried this with non-GATOS drivers? Not yet. I may have time this weekend. I've been waiting for the t&l code to stabilize before updating. Also, it always takes me a while to figure out again how to merge the latest dri cvs with the gatos code--iow I'm timid at this point to begin again, but it is about time, so...I'll see what happens this weekend. Nick ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] can't make tonight's meeting
Too tired after riding, must sleep... If I'm still up I'll look in briefly... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: DRM causes video lock on virtual console switching
On Mon, 2002-04-15 at 07:14, Nicholas Leippe wrote: > > We have massive reports of VT switching hangs in XFree86 4.2.0 > > with almost all Radeon hardware, but with other hardware as well. > > This problem has occured aparently since the prereleases 4.1.99.* > > and up through to the final release of 4.2.0. The kernel version > > doesn't seem to make any difference. As I understand, the Radeon > > is not being initialized properly or restored properly, however > > it occurs on other hardware as well. > > > > The problem seems common enough that I'm surprised it has not > > been determined yet, althought it seems that it is not one > > problem, but is more likely individual problems in different > > drivers, and the kernel isn't ruled out either. > > > > I've tried debugging it myself but have yet to determine the > > problem or a solution. > > I reported a problem to the gatos list a long while back that > I think may be related. (I thought it was strictly a gatos > thing, but have no idea, so I'll share it now). > I'm running X from cvs (old, but post 4.2.0) on my radeon 64mb. > Once I've run _any_ gl app, if I attempt to run xawtv, or use > mtv, it hangs the entire system. I just recently noticed that > the same thing occurs after switching to a vt and back--attempts > to watch video cause a system hang. > Exiting X entirely and restarting it at least makes it possible > to watch video after having used a gl app. > > So now I wonder if it's just X related and not gatos or dri > specific. Have you tried this with non-GATOS drivers? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] A question for tonight...
The chat is on now. Looks like my earlier message hasn't gone through yet. Trying again... -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] IRC today
#dri-devel on irc.openprojects.net 4:00pm EST (2100 UTC) -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64-0-0-3-branch does not build
I just cvs updated my mach64-0-0-3-branch. make ran without problems without problems. But make install gave me the following errors: make[5]: Entering directory `/var/local/src/mach64003/build/xc/lib/GL/mesa/src/drv/mach64' rm -f mach64_screen.o gcc -c -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g -I../../../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../../extras/Mesa/src -I../../../../../../lib/GL/mesa/src/drv/common -I../../../../../../lib/GL/mesa/src/drv/mach64 -I../../../../../../lib/GL/dri -I../../../../../../lib/GL/glx -I../../../../../../exports/include -I../../../../../../exports/include/GL -I../../../../../../programs/Xserver/GL/dri -I../../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../../programs/Xserver/hw/xfree86/drivers/ati -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../lib/GL/dri/drm -I../../../../../../lib/GL/include -I../../../../../.. -I../../../../../../exports/include -I/usr/X11R6-mach64003/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM mach64_screen.c In file included from mach64_screen.c:32: ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/mach64_dri.h:43: parse error before `Bool' ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/mach64_dri.h:43: warning: no semicolon at end of struct or union ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/mach64_dri.h:66: parse error before `}' ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/mach64_dri.h:66: warning: type defaults to `int' in declaration of `ATIDRIServerInfoRec' ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/mach64_dri.h:66: warning: type defaults to `int' in declaration of `ATIDRIServerInfoPtr' ../../../../../../programs/Xserver/hw/xfree86/drivers/ati/mach64_dri.h:66: warning: data definition has no type or storage class In file included from ../../../../../../lib/GL/glx/glxclient.h:51, from ../../../../../../lib/GL/dri/dri_util.h:43, from mach64_context.h:39, from mach64_screen.c:34: ../../../../../../exports/include/GL/glx.h:112: warning: function declaration isn't a prototype make[5]: *** [mach64_screen.o] Fehler 1 Then I also tried a clean make World; make install, with the same result. I checked the logfile of make World, there are really no errors there. I find it strange that mach64_screen.o is rebuilt during install since my World log file contained the following: rm -f mach64_screen.o gcc -c -O2 -march=i686 -malign-functions=4 -ffast-math -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g -I../../../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../../extras/Mesa/src -I../../../../../../lib/GL/mesa/src/drv/common -I../../../../../../lib/GL/mesa/src/drv/mach64 -I../../../../../../lib/GL/dri -I../../../../../../lib/GL/glx -I../../../../../../exports/include -I../../../../../../exports/include/GL -I../../../../../../programs/Xserver/GL/dri -I../../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../../programs/Xserver/hw/xfree86/drivers/ati -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../lib/GL/dri/drm -I../../../../../../lib/GL/include -I../../../../../.. -I../../../../../../exports/include -I/usr/X11R6-mach64003/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM mach64_screen.c without any error messages. When I think about it I'm even surprised that mach64_screen.o builds without errors here, since I couldn't find any include file of mach64_dri.h which defines Bool. The only thing that is different in the two cases is the gcc command line, so I diffed them and found that the one from make install uses the standard -O2 optimisation while the one from make World uses my custom optimisations. But this seems quite unrelated to the problem anyway. Regards,
Re: [Dri-devel] mach64-0-0-3-branch does not build
On 2002.04.15 23:32 Felix Kühling wrote: > I just cvs updated my mach64-0-0-3-branch. make ran without problems > without problems. But make install gave me the following errors: > > ... > > Then I also tried a clean make World; make install, with the same > result. I checked the logfile of make World, there are really no errors > there. I find it strange that mach64_screen.o is rebuilt during install > since my World log file contained the following: > > ... > > without any error messages. When I think about it I'm even surprised > that mach64_screen.o builds without errors here, since I couldn't find > any include file of mach64_dri.h which defines Bool. > > The only thing that is different in the two cases is the gcc command > line, so I diffed them and found that the one from make install uses the > standard -O2 optimisation while the one from make World uses my custom > optimisations. But this seems quite unrelated to the problem anyway. > > Regards, >Felix > These kind of problems happen when there some deep changes in headers (such as the branch as suffered lately) and you're building on a previous built tree. In these cases is better to remove completely the 'build' and 'lndir' it again. If you do 'make World' from the top dir almost everything is rebuilt anyway so there isn't much difference of time, in fact this is how the snapshots are made. BTW, the mach64 binary snapshots have been having some problems too in the last days, but I pretty sure that it's unrelated. I'm revamping the scripts anyway, to be used in SF compiler farm. José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Something to test for Radeon VT switching lockups
Those affected by the lockups please test this patch against the DRI
trunk. It puts the DRI block in RADEONEnterVT() back first, where it was
in XFree86 4.1, which I understand didn't exhibit this problem (right?).
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Index: radeon_driver.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v
retrieving revision 1.20
diff -u -r1.20 radeon_driver.c
--- radeon_driver.c 9 Apr 2002 21:54:52 - 1.20
+++ radeon_driver.c 15 Apr 2002 23:05:44 -
@@ -4407,6 +4417,13 @@
RADEONTRACE(("RADEONEnterVT\n"));
+#ifdef XF86DRI
+if (RADEONPTR(pScrn)->directRenderingEnabled) {
+ RADEONCP_START(pScrn, info);
+ DRIUnlock(pScrn->pScreen);
+}
+#endif
+
if (info->FBDev) {
unsigned char *RADEONMMIO = info->MMIO;
if (!fbdevHWEnterVT(scrnIndex,flags)) return FALSE;
@@ -4418,14 +4435,7 @@
if (info->accelOn)
RADEONEngineRestore(pScrn);
-#ifdef XF86DRI
-if (RADEONPTR(pScrn)->directRenderingEnabled) {
- RADEONCP_START(pScrn, info);
- DRIUnlock(pScrn->pScreen);
-}
-#endif
-
-RADEONAdjustFrame(scrnIndex, pScrn->frameX0, pScrn->frameY0, 0);
+pScrn->AdjustFrame(scrnIndex, pScrn->frameX0, pScrn->frameY0, 0);
return TRUE;
}
Re: [Dri-devel] mach64-0-0-3-branch does not build
Sorry, I forgot to redirect standard error to my world.log :(. In fact the build of mach64_screen.o failed here, too with the same error messages. > These kind of problems happen when there some deep changes in headers > (such as the branch as suffered lately) and you're building on a > previous built tree. In these cases is better to remove completely > the 'build' and 'lndir' it again. If you do 'make World' from the top > dir almost everything is rebuilt anyway so there isn't much > difference of time, in fact this is how the snapshots are made. Ok, I tried it again with a new build tree. And it still doesn't work. Maybe I should try a fresh checkout? The problem seems to be that Bool is not defined in mach64_dri.h. I recently had a similar problem with another programme I tried to compile and the solution was to include Xlib.h. But since I'm compiling an X-Server here I should probably not include client include files. Any other ideas? > José Fonseca Felix Kühling __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-3-branch does not build
On 2002.04.16 00:39 Felix Kühling wrote: > Sorry, I forgot to redirect standard error to my world.log :(. In fact > the build of mach64_screen.o failed here, too with the same error > messages. > >> These kind of problems happen when there some deep changes in headers >> (such as the branch as suffered lately) and you're building on a >> previous built tree. In these cases is better to remove completely the >> 'build' and 'lndir' it again. If you do 'make World' from the top dir >> almost everything is rebuilt anyway so there isn't much difference of >> time, in fact this is how the snapshots are made. > > Ok, I tried it again with a new build tree. And it still doesn't work. > Maybe I should try a fresh checkout? > No. I have the problem too. It's a new structure member that I added to the 2D driver, which compiles fine. I didn't noticed before the effect in the 3D driver as well. The R128 has this same structure member (which was from where I took it), so it's really a matter of a missing include somewhere. > The problem seems to be that Bool is not defined in mach64_dri.h. I > recently had a similar problem with another programme I tried to compile > and the solution was to include Xlib.h. But since I'm compiling an > X-Server here I should probably not include client include files. Any > other ideas? For the time being just change it to 'int' to get it to compile while we don't find which include is missing here. > > Felix Kühling > __\|/_____ ___ ___ José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-3-branch does not build
On Tue, 16 Apr 2002, José Fonseca wrote: > On 2002.04.16 00:39 Felix Kühling wrote: > > Sorry, I forgot to redirect standard error to my world.log :(. In fact > > the build of mach64_screen.o failed here, too with the same error > > messages. > > > >> These kind of problems happen when there some deep changes in headers > >> (such as the branch as suffered lately) and you're building on a > >> previous built tree. In these cases is better to remove completely the > >> 'build' and 'lndir' it again. If you do 'make World' from the top dir > >> almost everything is rebuilt anyway so there isn't much difference of > >> time, in fact this is how the snapshots are made. > > > > Ok, I tried it again with a new build tree. And it still doesn't work. > > Maybe I should try a fresh checkout? > > > > No. I have the problem too. It's a new structure member that I added to > the 2D driver, which compiles fine. I didn't noticed before the effect in > the 3D driver as well. The R128 has this same structure member (which was > from where I took it), so it's really a matter of a missing include > somewhere. > BTW, I have this in my tree, but since you're working on this... We should add IsPCI and AGPMode fields to ATIDRIRec in mach64_dri.h and initialize them in ATIDRIFinishScreenInit (atidri.c) from the ATIDRIServerInfoPtr values. These will be needed for the Mesa driver (AGPMode is just for informational output in the renderer string). I started adding some of the code to the Mesa driver to support AGP textures, and it needs these fields which will also need to be added to mach64_screen.h in the Mesa driver. After this, we'll need to add some additional structure fields here and there for the AGP texture region, but this would be a good start, if you'd like to do the DDX side. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-3-branch does not build
On 2002.04.16 01:38 Leif Delgass wrote: > On Tue, 16 Apr 2002, José Fonseca wrote: > > ... > > > > No. I have the problem too. It's a new structure member that I added to > > the 2D driver, which compiles fine. I didn't noticed before the effect > in > > the 3D driver as well. The R128 has this same structure member (which > was > > from where I took it), so it's really a matter of a missing include > > somewhere. > > > > BTW, I have this in my tree, but since you're working on this... We I wont't be able to do much about this in the next 20h. (I'm getting sleepy and it's gonna be a full day tomorrow). > should add IsPCI and AGPMode fields to ATIDRIRec in mach64_dri.h and > initialize them in ATIDRIFinishScreenInit (atidri.c) from the > ATIDRIServerInfoPtr values. These will be needed for the Mesa driver > (AGPMode is just for informational output in the renderer string). I Yes. I know. I didn't do this yet because I already get burned once with these shared headers updates. So I'm doing very small and secure steps at a time. But go ahead. I don't plan to mess more with this issue (besides finding the missing include) as I have other things on my sight. > started adding some of the code to the Mesa driver to support AGP > textures, and it needs these fields which will also need to be added to > mach64_screen.h in the Mesa driver. After this, we'll need to add some > additional structure fields here and there for the AGP texture region, > but this would be a good start, if you'd like to do the DDX side. As you think is best. AGP texture are very interesting indeed. I'll help in whatever I can. > > -- > Leif Delgass > http://www.retinalburn.net > José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-3-branch does not build
On Mon, 15 Apr 2002, Leif Delgass wrote: > On Tue, 16 Apr 2002, José Fonseca wrote: > > > On 2002.04.16 00:39 Felix Kühling wrote: > > > Sorry, I forgot to redirect standard error to my world.log :(. In fact > > > the build of mach64_screen.o failed here, too with the same error > > > messages. > > > > > >> These kind of problems happen when there some deep changes in headers > > >> (such as the branch as suffered lately) and you're building on a > > >> previous built tree. In these cases is better to remove completely the > > >> 'build' and 'lndir' it again. If you do 'make World' from the top dir > > >> almost everything is rebuilt anyway so there isn't much difference of > > >> time, in fact this is how the snapshots are made. > > > > > > Ok, I tried it again with a new build tree. And it still doesn't work. > > > Maybe I should try a fresh checkout? > > > > > > > No. I have the problem too. It's a new structure member that I added to > > the 2D driver, which compiles fine. I didn't noticed before the effect in > > the 3D driver as well. The R128 has this same structure member (which was > > from where I took it), so it's really a matter of a missing include > > somewhere. > > > > BTW, I have this in my tree, but since you're working on this... We > should add IsPCI and AGPMode fields to ATIDRIRec in mach64_dri.h and > initialize them in ATIDRIFinishScreenInit (atidri.c) from the > ATIDRIServerInfoPtr values. These will be needed for the Mesa driver > (AGPMode is just for informational output in the renderer string). I > started adding some of the code to the Mesa driver to support AGP > textures, and it needs these fields which will also need to be added to > mach64_screen.h in the Mesa driver. After this, we'll need to add some > additional structure fields here and there for the AGP texture region, but > this would be a good start, if you'd like to do the DDX side. > The problem may be this: r128_dri.h uses int for IsPCI, but r128.h uses Bool. Also, the ATIDRIRec for mach64 is different from r128 as it's really part of the DDX driver structure, but it's pulled out into mach64_dri.h. -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Something to test for Radeon VT switching lockups
On 16 Apr 2002, Michel [ISO-8859-1] Dänzer wrote: > > Those affected by the lockups please test this patch against the DRI > trunk. It puts the DRI block in RADEONEnterVT() back first, where it was > in XFree86 4.1, which I understand didn't exhibit this problem (right?). > > > -- > Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer > XFree86 and DRI project member / CS student, Free Software enthusiast > I tried the patch you provided this afternoon, with no positive results. The lockup occured just as before. If I remember correctly, this bug was present in XFree86 4.1, which is the earliest version I have run on this box. Keep the patches coming. I'll crash this box as much as it takes. --Kalen ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [utah-glx-dev] Joining efforts
Jose Fonseca wrote: > I still don't understand how it's not worth to work on this but have > separate equivalent code is. Well, it was just my two cents... Jose, I think you're asking the right questions. Personally, if I were supporting an entire OS, I would prefer to maintain only a varient of the DRM drivers, rather than a completely different 3D infrastructure and driver suites. However, I have to point out--that whomever is doing the work get's their way; and since I don't have the bandwidth to support the solaris DRM drivers--that's all I'm going to say, except: If the current DRI/DRM architecture doesn't meet the needs of the Solaris user and developer community, I am willing to work on broadening our infrastructure to address those needs. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] A question for tonight...
Jose,
Was your concern addressed in today's chat?
Jose Fonseca wrote:
>
> I have been looking into the DRM's DMA/CCE/CP initialization subroutines
> (those named *_do_init{dma,cce,cp} ) of the current DRI drivers, and I
> still don't know how they protect themselves from making faults due to
> bad initialization parameters. Since I this is a little complicated to
> put over IRC I'm sending this email to prepare you for tonight...
>
> The first question is why the dev->dev_private initializition is delayed
> until the last moment of exiting these subroutines. Taking the Radeon
> code as example, why is radeon_do_init_cp (radeon_cp.c:668) full of
> statements like
>
> dev->dev_private = (void *)dev_priv;
>
> instead of a single on right after dev_priv allocation (as done before)?
> Is this subroutine reentrant? Even if it is, how does this solve the
> problem?
>
> The other thing is in r128_do_cleanup_cce. This subroutine is called by
> r128_do_init_cce in case of failure as in
>
> DRM_FIND_MAP( dev_priv->buffers, init->buffers_offset );
> if(!dev_priv->buffers) {
> DRM_ERROR("could not find dma buffer region!\n");
> dev->dev_private = (void *)dev_priv;
> r128_do_cleanup_cce( dev );
> return -EINVAL;
> }
>
> but if indeed dev_priv->buffers is NULL, won't the following code in
> 128_do_cleanup_cce generate a segfault?
>
> if ( !dev_priv->is_pci ) {
> DRM_IOREMAPFREE( dev_priv->cce_ring );
> DRM_IOREMAPFREE( dev_priv->ring_rptr );
> DRM_IOREMAPFREE( dev_priv->buffers );
> } else {
>
> since as said in a previous email of mine DRM_IOREMAPFREE doesn't check
> if its argument is NULL, on the contrary it references it before passing
> it to ioremapfree:
>
> #define DRM_IOREMAPFREE(map) \
> do { \
> if ( (map)->handle && (map)->size )\
> DRM(ioremapfree)( (map)->handle, (map)->size );\
> } while (0)
>
> So isn't there a bug here as well or I'm missing something?
>
> Just in case you may be thinking that this can be fairly uncommon this
> situation occurs when the init structure changes. So everytime there is
> a versioning problem in the DRM, libdrm.a or DDX which involves a change
> on the init structure this will most likely to occur and, at least on my
> systems, it locks mach64.o on the kernel, and only a reset can allow
> normal operation again.
>
> Jose Fonseca
>
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
-- /\
Jens Owen/ \/\ _
[EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [utah-glx-dev] Joining efforts
Philip Brown wrote: > > On Mon, Apr 15, 2002 at 09:19:35PM -0600, Jens Owen wrote: > > However, I have to point out--that whomever is doing > > the work get's their way; and since I don't have the bandwidth to > > support the solaris DRM drivers--that's all I'm going to say, except: > > If the current DRI/DRM architecture doesn't meet the needs of the > > Solaris user and developer community, I am willing to work on broadening > > our infrastructure to address those needs. > > nice to hear. What did you have in mind when you say > "broaden our infrastructure" ? Making changes to the DRI and DRM interfaces is time consuming. Changing to the drmCommand semantics was a rather straight forward infrastructure change, but changing all the drivers the currently work under both Linux and FreeBSD to work with the new semantics was the time consuming part. That said, when I understand where and how the current infrastructure is limiting your ability to support Solaris, I'm willing to work on the infrastructure and resulting Linux changes required to keep a single code base working on multiple OS's. In the end, the extra work will be less than maintaining two separate infrastructures. So, let me turn the question around. What is it you need from the current DRI/DRM infrastructure that you are not getting today? I got the impression from your previous e-mails that you were looking for a solution that did not require kernel level support. If security and multiple direct rendering contexts are not a concern, and won't ever be for Solaris; then we should talk about taking Utah-GLX like shortcuts under the DRI. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Joining efforts
[Setting Cc to just the dri-devel list; this doesnt seem appropriate to the utah-glx list. (particularly since I'm the only solaris developer on it ;-)] [Note also that I'm not subscribed to dri-devel, though] On Mon, Apr 15, 2002 at 09:44:39PM -0600, Jens Owen wrote: > Philip Brown wrote: > > nice to hear. What did you have in mind when you say > > "broaden our infrastructure" ? > .. > That said, when I understand where and how the current infrastructure is > limiting your ability to support Solaris, I'm willing to work on the > infrastructure and resulting Linux changes required to keep a single > code base working on multiple OS's. In the end, the extra work will be > less than maintaining two separate infrastructures. > > So, let me turn the question around. What is it you need from the > current DRI/DRM infrastructure that you are not getting today? Okay, long email, in two section: "Solaris limitations", and "ease-of-porting issues". Neither of which strictly require changes to the drm API, but most of which require changes to underlying code. - SOLARIS LIMITATIONS -- Well, the biggie is that you cannot bind a custom driver to the video card: there is already a solaris video driver, and it has no exported bit-twiddle interfaces for other drivers. So, no using video card interrupts, and no tweaking the registers from driver level. (I think. There might be a way to do register twiddles, but I dont know how to do it.) The good news is that /dev/xsvc still works for register fiddling. So you can take the IO register mapping that the Xserver does, and use the mmaped regs at user level still. You CAN (in theory) use /dev/agpgart, seeing as how it is a separate device that solaris does not normally bind to. I wrote a theoretical solaris version of the agpgart API, that is actually (in theory) completed. But I have had no working graphics progs to test it at this point. It would be best to get something working without AGP support, and then cautiously see how badly things blow up once you turn it on. - EASE OF PORTING issues -- I think there are some card drivers under dri that "require" agp to work. This has got to be fixed. For every card, there should be a "fall back to using on-board video memory" mode. Similarly, a "fall back to no DMA" mode. Similarly, I believe that there is a check for custom card-specific kenel-level extensions, and if they are not there, DRI does not install itself for that card. That needs to be optional, not a drop-dead issue. Then of course there's the nasty bsd linking hack that I mentioned. If code is shared between OSs, it belongs in the 'shared' directory. Both so that porters know they probably want to use the code, and also that people working on it for existing platforms are aware that they cannot make some funky os-specific tweak in the code. > ... I got > the impression from your previous e-mails that you were looking for a > solution that did not require kernel level support. If security and > multiple direct rendering contexts are not a concern, and won't ever be > for Solaris; then we should talk about taking Utah-GLX like shortcuts > under the DRI. That would be good enough for me. Long-term, maybe others would be interested in fleshing out the other bits, but its not something I care to tackle. Heck, I dont technically even care about "direct" rendering. I'm perfectly happy to go through Xserver communication pipes, and thus solve the "security" issues by letting the Xserver handle it. I can play quake2 just fine with indirect rendering on my old TNT card and Utah-GLX. Contrariwise... maybe use /dev/xsvc "directly", for direct mapping. Solaris has /etc/logindevperm that can be tweaked to automatically adjust ownership of /dev/xsvc to the person logged in on console. Perhaps that is the best way to go. Anyways if the aforementioned limitations and needs were accomodated (for Matrox G400 suport, initally, anyways, since thats the card I have now), then I would be interested in looking at taking on the solaris port again. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM causes video lock on virtual console switching
On Monday 15 April 2002 12:46 pm, you wrote: > On Mon, 2002-04-15 at 00:15, Allen H. Ibara wrote: > > > Hmm. Can you try without AGP? You'll have to rebuild the DRM kernel > > > module and the 2D driver with the #define PCIGART_ENABLED active for > > > that to work, and apparently there are other instabilities without AGP > > > on i386, so it might be hard to make any conclusions, but I think it's > > > worth a try. > > > > Ok, I finally got an X server and radeon modules built (from dri cvs > > trunk pulled this morning) with PCIGART_ENABLED defined in 'radeon_dri.c' > > and 'radeon_cp.c', and the agpgart kernel module disabled and removed. > > > > Unfortunately it dies (hangs with no warning) quickly after startup, > > before I can tell it to switch VTs, and thus can't actually tell if > > disabling AGP prevented the problem or not. After X hangs, I can SIGKILL > > XFree86, but eventually have to reboot in order get the console back. > > Does it hang before anything is drawn or afterwards? It was afterward. In the xawtv video window, it would first draw garble (like it always does--then fade in), but it would just freeze w/the first snapshot of garble, and was frozen from that point on. No remote access, nothing. However, I do believe I rebooted w/magic sysrq combo. Nick ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
