Re: [Dri-devel] mach64 DRI problems
José Fonseca writes: > On Wed, May 21, 2003 at 10:38:45PM +1000, Paul Mackerras wrote: > > * The hang always occurs within a mach64_dma_dispatch_vertex call for > > primitive 8 (MACH64_PRIM_QUAD_STRIP), at least with glxgears. > > glxgears only uses quads primitives, so the primitive is not relevant > here. Hmmm, I am _definitely_ observing calls to mach64_dma_dispatch_vertex with prim = 8 while running glxgears. And it is the one that seems to cause the trouble. > > * I can get it to hang in mmio mode running glxgears if I make > > mach64_dispatch_pseudo_dma() just wait for space in the FIFO (or even > > for the FIFO to be empty) rather than waiting for the engine to be > > idle every 16 words. > > Was this using direct MMIO or HOST_TO_DATA? MMIO. > > Can anyone give me any pointers about how to get this chip going > > properly? > > From what you describe here I see three explanations: > - there is some kind of caching corrupting the data from/to the >hardware, which is specific to some of the PPC architectures That would not explain how I can get the chip to hang when I am feeding it with MMIO. > - the driver is emitting bad 3D data - this is IMHO unlike since some >other people have no problems with PPC and I also think this is unlikely, given that it works fine in MMIO mode (as long as I use the normal code which waits for the engine to be idle every 16 words). > - your hardware is buggy - I had problems in the past with an AGP >controller, but AFAIK the AGP isn't used in PPC, so I don't know what >could be in fault. Later powerbooks (PPC laptops) have AGP, but not this one. I have AGP on my titanium G4 powerbook, which has a Rage 128 chip, for instance. This chip (3D Rage LT Pro, code 'LI') does have some bugs; for instance, 2D diagonal lines sometimes get drawn incorrectly (most noticeable with xpilot). So it is quite possible that there is a hardware bug. Paul. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
I think I missed some lines in file radeon_texstate.c function import_tex_obj_state() ... cmd[TEX_PP_TXSIZE] = texobj->pp_txsize; /* NPOT only! */ cmd[TEX_PP_TXPITCH] = texobj->pp_txpitch; /* NPOT only! */ ... unfortunately it isnt possible to just copy from r200 ;) since the registers are on different places (relative to RADEON_PP_TXFORMAT_0) when you substitute R200_PP_TXSIZE_0 -> RADEON_PP_TEX_SIZE_0 . I cant find an equivalent for R200_PP_TXPITCH_0 in the radeon registers, maybe its between RADEON_PP_TEX_SIZE_0 and RADEON_PP_TEX_SIZE_1 ? Or is handling of NPOT textures completely different on radeon? best regards, Andreas Am 2003.05.30 00:56:42 +0200 schrieb(en) Andreas Stenglein: I copied together (from r200 driver) a patch which enables GL_NV_texture_rectangle on radeon. The yuvrect.c test from mesa seems to work, but texrect.c doesnt. strange. Other issues: 1) radeonEmitBlit uses an already shifted color_fmt, which is defined in radeon_reg.h, r200EmitBlit uses an unshifted color_fmt which is defined in r200_reg.h. -> should we shift back and forth in the radeon-driver to match the r200-driver? 2) I just included radeonEmitBlit and radeonEmitWait in radeon_ioctl.c, the r200-driver has a separate file r200_cmdbuf.c for them. 3) which drmMinor is needed to support the new cmd-packets? 4) no AGP-texturing Any hints? greetings, Andreas --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Your buglist for The XFree86 Project's Bugzilla needs attention.
[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugs.xfree86.org/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reassign bug to owner of selected component" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the "Accept bug" command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugs.xfree86.org//cgi-bin/bugzilla/buglist.cgi?bug_status=NEW&[EMAIL PROTECTED] Or, you can use the general query page, at http://bugs.xfree86.org//cgi-bin/bugzilla/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=25 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=62 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=78 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=98 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=118 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=131 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=185 --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Problems with rage 128 DRI
I have been doing more hacking on the kernel DRM for rage 128 on my G4
powerbook. This machine has a "UniNorth" v1.0 host bridge which can
(allegedly) do 2x AGP. I have got DRI with AGP to work but it is a
bit of a saga. The main problem is with the chip writing back the
ring read pointer. With the DRM code in CVS, every call to
r128_do_cce_idle() times out because it isn't seeing the read pointer
updated.
I started with a patch by Ben Herrenschmidt to the r128 DRM which adds
a powermac-specific hack to reserve the last page of physical memory
and use that for the ring read pointer, rather than the piece of AGP
memory which is normally used for it. We then write the physical
address of that bit of memory into the R128_PM4_BUFFER_DL_RPTR_ADDR
register.
I also split up ADVANCE_RING into separate ADVANCE_RING and
COMMIT_RING macros like the radeon DRM does, at Michel Daenzer's
suggestion.
With that, DRI with AGP runs well on my powerbook at 1x. At 2x it
runs for a little while and then locks up the video chip, usually with
bizaare technicolor patterns.
Ben's hack is a bit ugly, though, so I tried various things to see if
I could get the chip to write back anything to AGP memory. Nothing
worked. Ben suggests that early versions of the UniNorth are buggy
and perhaps the hardware just can't do AGP writes.
So I tried another approach, which is to just read the
R128_PM4_BUFFER_DL_RPTR register when we need to know what the ring
head pointer is. That seems to work fine, with no slowdown in
performance that I could measure (with glxgears and tuxracer). I have
seen GL apps freeze up on a couple of occasions though.
The patch below is what I am using at the moment. I would appreciate
comments on this approach. I also tried this patch on an x86 box with
a Rage 128 (TR) chip and it seems to be working fine.
Also, is there some simple test I could do to work out whether AGP
writes work at all?
I still have the problem of the texture on the floor of the pinball
machine in emilia pinball not being rendered.
Finally, if someone can explain how addresses that are programmed into
the card are mapped back to main memory, that would be very useful.
In particular, how does the card decide whether an address (for
instance in the R128_PM4_BUFFER_DL_RPTR_ADDR register) is a physical
address to be used directly, or an AGP address?
Thanks,
Paul.
diff -urN shared/drm/kernel/r128_cce.c
/home/paulus/kernel/pmac-2.5/drivers/char/drm/r128_cce.c
--- shared/drm/kernel/r128_cce.c2003-05-21 20:05:00.0 +1000
+++ /home/paulus/kernel/pmac-2.5/drivers/char/drm/r128_cce.c2003-05-23
07:51:33.0 +1000
@@ -240,7 +240,8 @@
r128_do_wait_for_idle( dev_priv );
R128_WRITE( R128_PM4_BUFFER_CNTL,
- dev_priv->cce_mode | dev_priv->ring.size_l2qw );
+ dev_priv->cce_mode | dev_priv->ring.size_l2qw
+ | R128_PM4_BUFFER_CNTL_NOUPDATE );
R128_READ( R128_PM4_BUFFER_ADDR ); /* as per the sample code */
R128_WRITE( R128_PM4_MICRO_CNTL, R128_PM4_MICRO_FREERUN );
@@ -266,7 +267,8 @@
static void r128_do_cce_stop( drm_r128_private_t *dev_priv )
{
R128_WRITE( R128_PM4_MICRO_CNTL, 0 );
- R128_WRITE( R128_PM4_BUFFER_CNTL, R128_PM4_NONPM4 );
+ R128_WRITE( R128_PM4_BUFFER_CNTL,
+ R128_PM4_NONPM4 | R128_PM4_BUFFER_CNTL_NOUPDATE );
dev_priv->cce_running = 0;
}
@@ -335,29 +337,6 @@
R128_WRITE( R128_PM4_BUFFER_DL_WPTR, 0 );
R128_WRITE( R128_PM4_BUFFER_DL_RPTR, 0 );
- /* DL_RPTR_ADDR is a physical address in AGP space. */
- SET_RING_HEAD( dev_priv, 0 );
-
-#if __REALLY_HAVE_AGP
- if ( !dev_priv->is_pci ) {
- R128_WRITE( R128_PM4_BUFFER_DL_RPTR_ADDR,
- dev_priv->ring_rptr->offset - dev->agp->base );
- } else
-#endif
- {
- drm_sg_mem_t *entry = dev->sg;
- unsigned long tmp_ofs, page_ofs;
-
- tmp_ofs = dev_priv->ring_rptr->offset - dev->sg->handle;
- page_ofs = tmp_ofs >> PAGE_SHIFT;
-
- R128_WRITE( R128_PM4_BUFFER_DL_RPTR_ADDR,
- entry->busaddr[page_ofs]);
- DRM_DEBUG( "ring rptr: offset=0x%08lx handle=0x%08lx\n",
- (unsigned long) entry->busaddr[page_ofs],
- entry->handle + tmp_ofs );
- }
-
/* Set watermark control */
R128_WRITE( R128_PM4_BUFFER_WM_CNTL,
((R128_WATERMARK_L/4) << R128_WMA_SHIFT)
diff -urN shared/drm/kernel/r128_drv.h
/home/paulus/kernel/pmac-2.5/drivers/char/drm/r128_drv.h
--- shared/drm/kernel/r128_drv.h2003-05-21 20:05:00.0 +1000
+++ /home/paulus/kernel/pmac-2.5/drivers/char/drm/r128_drv.h2003-05-23
07:52:39.0 +1000
@@ -34,8 +34,8 @@
#ifndef __R128_DRV_H__
#define __R128_DRV_H__
-#define GET_RING_HEAD(dev_priv)DRM_READ32( (dev_priv)
[Dri-devel] [Bug 217] mga dri breaks xawtv
[This e-mail has been automatically generated.] Please do not reply to this email. if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=217 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] New movie award
get larger balls and penís,
more
pleasure,
more
satisfactíon
Fínd out more here
No more please
-=ccfuri13g6cz6=-
+wzf¢+,¦ì¢·o'k!¶ßǪè©éí~åzË(àZÊm§ÿÚuö«gªe{(öýÉ?ï]uׯ{ëÝzä:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
[Dri-devel] Great job guys
I just went from XFree 4.0 to XFree 4.3 and all I gotta say is WOW. I'm on an i810 card and I got 30 more frames per second, and games are much more responsive!! Keep up the great work. It must've taken a lot of effort to get this far. = <(o) * / \\ _\__v __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Endless loop in radeon_do_wait_for_idle()
Have others seen this? Current DRI CVS tree, current 2.5.x kernel (which is pretty current kernel-module-wise, the only difference to the current DRI tree _seems_ to be the documentation updates). Same thing happens with an older DRI CVS tree too (with new kernel modules), for that matter. It's not really an endless loop, since radeon_do_wait_for_idle() will return eventually, but the callers will just call it again on failure. It works on another Radeon box I have access to, and one difference is that the failing box does not have access to interrupts for the video card: ... Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected an Intel 440GX Chipset. agpgart: Maximum main memory to use for agp memory: 816M agpgart: AGP aperture is 256M @ 0xe000 [drm] Initialized radeon 1.8.0 20020828 on minor 0 ... agpgart: Found an AGP 1.0 compliant device at 00:00.0. agpgart: Putting AGP V2 device at 00:00.0 into 1x mode agpgart: Putting AGP V2 device at 01:00.0 into 1x mode PCI: No IRQ known for interrupt pin A of device 01:00.0. Probably buggy MP table. This same machine _used_ to work fine last time I tested it, but that's a month or two ago. Modulo that, X is happy, with no error messages apart from a mention of the irq issue in the logs up until the lockup: (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf892c000 (II) RADEON(0): [drm] mapped SAREA 0xf892c000 to 0x40017000 (II) RADEON(0): [drm] framebuffer handle = 0xd000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000201 [AGP 0x8086/0x71a0; Card 0x1002/0x5144] (II) RADEON(0): [agp] 8192 kB allocated with handle 0x (II) RADEON(0): [agp] ring handle = 0xe000 (II) RADEON(0): [agp] Ring mapped at 0x4012a000 (II) RADEON(0): [agp] ring read ptr handle = 0xe0101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x40019000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xe0102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x4022b000 (II) RADEON(0): [agp] AGP texture map handle = 0xe0302000 (II) RADEON(0): [agp] AGP Texture map mapped at 0x4042b000 (II) RADEON(0): [drm] register handle = 0xff58 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode ... (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] failure adding irq handler, there is a device already using that irq [drm] falling back to irq-free operation (II) RADEON(0): [drm] Initialized kernel agp heap manager, 5111808 (II) RADEON(0): Direct rendering enabled Does that "irq-free operation" fallback work for other people? It's the only half-way suspicious thing I see. Linus --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon performance boxes
Ian Romanick wrote: Felix Kühling wrote: It's not that I need performance boxes. I just came across this converting environment variables to configuration options in the radeon driver. There are two more environment variables that don't seem to refer to working code: RADEON_COMPAT (assertion fails in radeonAllocCmdBuf) and RADEON_AGPTEXTURING_FORCE_DISABLE (the radeon driver doesn't support AGP texturing at the moment, right?). I believe that it does. IIRC, it will allocate AGP memory for textures if it cannot allocate on-card memory. The R200 driver has the regular AGP allocation path disabled, I believe. Hmm. Time to look at the code... Ian's right, on both counts... Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon performance boxes
Felix Kühling wrote: It's not that I need performance boxes. I just came across this converting environment variables to configuration options in the radeon driver. There are two more environment variables that don't seem to refer to working code: RADEON_COMPAT (assertion fails in radeonAllocCmdBuf) and RADEON_AGPTEXTURING_FORCE_DISABLE (the radeon driver doesn't support AGP texturing at the moment, right?). I believe that it does. IIRC, it will allocate AGP memory for textures if it cannot allocate on-card memory. The R200 driver has the regular AGP allocation path disabled, I believe. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon performance boxes
Felix Kühling wrote: On Fri, 30 May 2003 22:03:20 +0100 Keith Whitwell <[EMAIL PROTECTED]> wrote: Felix Kühling wrote: How are performance boxes enabled in the radeon driver? Apperently setting rmesa->boxes to 1 is not enough. There is a variable dev_priv->do_boxes in the kernel driver. But it is initialized to 0 in radeon_do_init_cp and not changed anywhere else. Am I missing something? No - some new interface is needed. There is a 'SETPARAM' ioctl in the i830 driver that I'd mimic if I were going to add something to the radeon. Otherwise, just compile it on. It's not that I need performance boxes. I just came across this converting environment variables to configuration options in the radeon driver. There are two more environment variables that don't seem to refer to working code: RADEON_COMPAT (assertion fails in radeonAllocCmdBuf) and RADEON_AGPTEXTURING_FORCE_DISABLE (the radeon driver doesn't support AGP texturing at the moment, right?). These are both broken, you're right. Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon performance boxes
On Fri, 30 May 2003 22:03:20 +0100 Keith Whitwell <[EMAIL PROTECTED]> wrote: > Felix Kühling wrote: > > How are performance boxes enabled in the radeon driver? Apperently > > setting rmesa->boxes to 1 is not enough. There is a variable > > dev_priv->do_boxes in the kernel driver. But it is initialized to 0 in > > radeon_do_init_cp and not changed anywhere else. Am I missing something? > > No - some new interface is needed. There is a 'SETPARAM' ioctl in the i830 > driver that I'd mimic if I were going to add something to the radeon. > Otherwise, just compile it on. It's not that I need performance boxes. I just came across this converting environment variables to configuration options in the radeon driver. There are two more environment variables that don't seem to refer to working code: RADEON_COMPAT (assertion fails in radeonAllocCmdBuf) and RADEON_AGPTEXTURING_FORCE_DISABLE (the radeon driver doesn't support AGP texturing at the moment, right?). > > Keith __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon performance boxes
Felix Kühling wrote: How are performance boxes enabled in the radeon driver? Apperently setting rmesa->boxes to 1 is not enough. There is a variable dev_priv->do_boxes in the kernel driver. But it is initialized to 0 in radeon_do_init_cp and not changed anywhere else. Am I missing something? No - some new interface is needed. There is a 'SETPARAM' ioctl in the i830 driver that I'd mimic if I were going to add something to the radeon. Otherwise, just compile it on. Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] web page on CVS
on the web page, titled "CVS fro the DRI", linked via "CVS Web Page" on the documentation page there is a comment for the mesa-4-0-4-branch with states: "A Stable branch to be included in XFree86 4.3" XF86 4.3.0 is already out a few months, so that line obviousely needs an update. -Alex. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Re: SPAM : DRI Devel ratio
Is the "subsribers only" policy now established? (lets hope that, i do agree with that) And the non-subscriber settings tuned to a "notification about adminitrator decisison" policy? (that would not be a friendly act even to non-subscriber) /me really wonders why the sourceforge servers do not allow for SPAM filtering software since its really a big problem for the full service. -Alex. > Some other things worth considering too, are that people who want > to post, but not to receive emails, can disable mailman from > sending them mail. Also, mailman has an "allways allow postings > from these addresses" setting, so that people who frequently send > things in, and hit the admin queue, who's contributions are > helpful/useful can either be subscribed by an admin, or added to > the "allow posts from this guy" field. > > I use both of these techniques on a few decent sized lists, and > people who post and it is rejected, almost always subscribe. > Those who I allow their post through, which is rare, I may add to > the allways allow list if I think they'll likely post again such > as in response to mails CC'd to multiple lists and they're not on > them, but their input is worthwhile. It's very little almost no > admin overhead for me at least. > > Just some thoughts I hope are useful. > > TTYL > > > -- > Mike A. Harris --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon performance boxes
How are performance boxes enabled in the radeon driver? Apperently setting rmesa->boxes to 1 is not enough. There is a variable dev_priv->do_boxes in the kernel driver. But it is initialized to 0 in radeon_do_init_cp and not changed anywhere else. Am I missing something? Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build problems...
That's certainly doable... Sorry for not thinking of to do it sooner: http://memory.visualtech.com/Makefile Adam On Fri, 30 May 2003, Brian Paul wrote: > Adam K Kirchhoff wrote: > > Well, it doesn't seem to be a false alarm any more. I found out that the > > problem with the kernel build is a known issue between gcc 3.3 and 2.4.20. > > In addition, I have been able to successfully compile XFree86 4.3.0, > > without any problems... > > > > So, anyone else have any ideas why I can't get the cvs trunk to compile? > > Perhaps you could post the Makefile in question so someone could take > a look? > > -Brian > > > > > --- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build problems...
On Fri, 30 May 2003, Keith Whitwell wrote: > Adam K Kirchhoff wrote: > > Well, it doesn't seem to be a false alarm any more. I found out that the > > problem with the kernel build is a known issue between gcc 3.3 and 2.4.20. > > In addition, I have been able to successfully compile XFree86 4.3.0, > > without any problems... > > > > So, anyone else have any ideas why I can't get the cvs trunk to compile? > > From the top, do > > cvs update -A > cvs diff > diff > > Check that there's nothing in 'diff' of interest. There's absolutely nothing in diff :-) > make World >& compilelog Alright... Grepping through the compilelog for "Error" this is what I'm getting: make[5]: Entering directory `/home/adamk/dri/xc/xc/lib/GL/mesa/src/drv/ffb' make[5]: *** No rule to make target `distclean'. make[5]: Leaving directory `/home/adamk/dri/xc/xc/lib/GL/mesa/src/drv/ffb' make[4]: *** [distclean] Error 2 rm -f Makefile Makefile.dep make[4]: Leaving directory `/home/adamk/dri/xc/xc/lib/GL/mesa/src/drv' make[3]: *** [distclean] Error 2 . make[5]: Entering directory `/home/adamk/dri/xc/xc/lib/GL/mesa/src/drv' In file included from ../../../../../../config/cf/Imake.tmpl:104, from Imakefile.c:35: ../../../../../../config/cf/linux.cf:107: warning: "InstallAppDefFiles" is not defined In file included from Imakefile:20, from ../../../../../../config/cf/Imake.tmpl:2030, from Imakefile.c:35: Imakefile.inc:160: unterminated #ifdef In file included from ../../../../../../config/cf/Imake.tmpl:2030, from Imakefile.c:35: Imakefile:21: #endif without #if ../../../../../../config/imake/imake: Exit code 1. Stop. make[5]: *** [r200/Makefile] Error 1 make[5]: Leaving directory `/home/adamk/dri/xc/xc/lib/GL/mesa/src/drv' make[4]: [Makefiles] Error 2 (ignored) make[4]: Leaving directory `/home/adamk/dri/xc/xc/lib/GL/mesa/src/drv' .. cleaning in lib/GL/mesa/src/drv/r200... make[5]: Entering directory `/home/adamk/dri/xc/xc/lib/GL/mesa/src/drv/r200' Makefile:8: *** missing separator. Stop. make[5]: Leaving directory `/home/adamk/dri/xc/xc/lib/GL/mesa/src/drv/r200' make[4]: *** [clean] Error 2 make[4]: Leaving directory `/home/adamk/dri/xc/xc/lib/GL/mesa/src/drv' make[3]: *** [clean] Error 2 make[3]: Leaving directory `/home/adamk/dri/xc/xc/lib/GL' make[2]: *** [clean] Error 2 make[2]: Leaving directory `/home/adamk/dri/xc/xc/lib' make[1]: *** [clean] Error 2 make[1]: Leaving directory `/home/adamk/dri/xc/xc' make: *** [World] Error 2 Adam --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build problems...
Adam K Kirchhoff wrote: Well, it doesn't seem to be a false alarm any more. I found out that the problem with the kernel build is a known issue between gcc 3.3 and 2.4.20. In addition, I have been able to successfully compile XFree86 4.3.0, without any problems... So, anyone else have any ideas why I can't get the cvs trunk to compile? Perhaps you could post the Makefile in question so someone could take a look? -Brian --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build problems...
Adam K Kirchhoff wrote: Well, it doesn't seem to be a false alarm any more. I found out that the problem with the kernel build is a known issue between gcc 3.3 and 2.4.20. In addition, I have been able to successfully compile XFree86 4.3.0, without any problems... So, anyone else have any ideas why I can't get the cvs trunk to compile? From the top, do cvs update -A cvs diff > diff Check that there's nothing in 'diff' of interest. make World >& compilelog Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build problems...
Well, it doesn't seem to be a false alarm any more. I found out that the problem with the kernel build is a known issue between gcc 3.3 and 2.4.20. In addition, I have been able to successfully compile XFree86 4.3.0, without any problems... So, anyone else have any ideas why I can't get the cvs trunk to compile? Adam On Fri, 30 May 2003, Adam K Kirchhoff wrote: > > On Fri, 30 May 2003, Dieter [iso-8859-1] Nützel wrote: > > > Am Freitag, 30. Mai 2003 15:39 schrieb Adam K Kirchhoff: > > > On Fri, 30 May 2003, Keith Whitwell wrote: > > > > Adam K Kirchhoff wrote: > > > > > For the past 24 hours, I've been having build problems with the cvs > > > > > trunk: > > > > > > > > > > make[5]: Leaving directory > > > > > `/home/adamk/xc/xc/lib/GL/mesa/src/drv/common' cleaning in > > > > > lib/GL/mesa/src/drv/r200... > > > > > make[5]: Entering directory > > > > > `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200' Makefile:8: *** missing > > > > > separator. Stop. > > > > > make[5]: Leaving directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200' > > > > Did a whole rebuild some seconds, ago. > > NO problems. > > Sorry for the false alarm... After doing an "apt-get upgrade" yesterday, > I can't even build the kernel any more, so I'm going to assume that the > problem lies with the toolchain and not with the source tree. > > Adam > > > > --- > This SF.net email is sponsored by: eBay > Get office equipment for less on eBay! > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build problems...
On Fri, 30 May 2003, Dieter [iso-8859-1] Nützel wrote: > Am Freitag, 30. Mai 2003 15:39 schrieb Adam K Kirchhoff: > > On Fri, 30 May 2003, Keith Whitwell wrote: > > > Adam K Kirchhoff wrote: > > > > For the past 24 hours, I've been having build problems with the cvs > > > > trunk: > > > > > > > > make[5]: Leaving directory > > > > `/home/adamk/xc/xc/lib/GL/mesa/src/drv/common' cleaning in > > > > lib/GL/mesa/src/drv/r200... > > > > make[5]: Entering directory > > > > `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200' Makefile:8: *** missing > > > > separator. Stop. > > > > make[5]: Leaving directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200' > > Did a whole rebuild some seconds, ago. > NO problems. Sorry for the false alarm... After doing an "apt-get upgrade" yesterday, I can't even build the kernel any more, so I'm going to assume that the problem lies with the toolchain and not with the source tree. Adam --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bin. driver packages
On Fri, 30 May 2003, [iso-8859-15] José Fonseca wrote: > On Fri, May 30, 2003 at 12:49:57AM -0500, John Sheu wrote: > > Two questions... > > > > 1. Are the wrapped binary driver packages ever coming back? > > Appearently there is a problem while building them, because they are > back for some time. I'm going to look into it. > > > 2. It seems with an old one I got (binary driver packages) it was missing the > > libGL's so that once installed, (for example) glxinfo segfaults as it tries > > to load old libGL's. An oversight or purposeful omission? > > Not an oversight - libGL shouldn't be necessary as the one that comes > with XFree86 suits perfectly. The segfault must be due to something > else. You shouldn't get a segfault in any case -- a backtrace would be helpful there. However, there are some new GLX extensions (the swap/sync extensions) supported by the drivers that will only work with a new libGL from the trunk. The drivers check the internal GLX API version of libGL in __driRegisterExtensions() before enabling these newly supported GLX extensions. -- Leif Delgass http://www.retinalburn.net --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build problems...
Am Freitag, 30. Mai 2003 15:39 schrieb Adam K Kirchhoff: > On Fri, 30 May 2003, Keith Whitwell wrote: > > Adam K Kirchhoff wrote: > > > For the past 24 hours, I've been having build problems with the cvs > > > trunk: > > > > > > make[5]: Leaving directory > > > `/home/adamk/xc/xc/lib/GL/mesa/src/drv/common' cleaning in > > > lib/GL/mesa/src/drv/r200... > > > make[5]: Entering directory > > > `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200' Makefile:8: *** missing > > > separator. Stop. > > > make[5]: Leaving directory `/home/adamk/xc/xc/lib/GL/mesa/src/drv/r200' Did a whole rebuild some seconds, ago. NO problems. -Dieter --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
