Re: r300 + FreeBSD -CURRENT?
On Sunday 21 August 2005 07:55 pm, Vladimir Dergachev wrote: And so on, through /dev/dri/card254 Mind you, /dev/dri/card0 exists: [ [EMAIL PROTECTED] - ~ ]: ls -la /dev/dri total 1 dr-xr-xr-x 2 root wheel 512 Aug 21 18:37 . dr-xr-xr-x 5 root wheel 512 Dec 31 1969 .. crw-rw-rw- 1 root wheel0, 162 Aug 21 18:35 card0 Any ideas? Is the major ok ? On my (linux) system I get: crw-rw-rw- 1 root root 226, 0 Aug 21 19:07 card0 I would expect a difference, but, it might have changed.. FYI, FreeBSD -CURRENT does not use fixed major number any more. It's dynamically assigned when it's created. Jung-uk Kim Also, check that the DRM driver knows your PCI id. best Vladimir Dergachev Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + FreeBSD -CURRENT?
On Monday 22 August 2005 01:54 pm, Vladimir Dergachev wrote: I would expect a difference, but, it might have changed.. FYI, FreeBSD -CURRENT does not use fixed major number any more. It's dynamically assigned when it's created. Cool ! Is this more devfs style (with kernel space code) or udevd style (with userspace code) ? I don't know much about Linux, so I cannot say, but it's not user space code for sure. FreeBSD's devfs is responsible for (randomly) allocating major numbers. Jung-uk Kim best Vladimir Dergachev --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + FreeBSD -CURRENT?
On Monday 22 August 2005 02:49 pm, Adam K Kirchhoff wrote: Vladimir Dergachev wrote: And so on, through /dev/dri/card254 Mind you, /dev/dri/card0 exists: [ [EMAIL PROTECTED] - ~ ]: ls -la /dev/dri total 1 dr-xr-xr-x 2 root wheel 512 Aug 21 18:37 . dr-xr-xr-x 5 root wheel 512 Dec 31 1969 .. crw-rw-rw- 1 root wheel0, 162 Aug 21 18:35 card0 Any ideas? Is the major ok ? On my (linux) system I get: crw-rw-rw- 1 root root 226, 0 Aug 21 19:07 card0 I would expect a difference, but, it might have changed.. Also, check that the DRM driver knows your PCI id. best Vladimir Dergachev It's listed: shared/drm_pciids.txt:0x1002 0x4153 CHIP_RV350 ATI Radeon AS 9600 AS Would the kernel driver even attach to the device (as it appears to be doing) if it didn't know my PCI ID? Correct. AFAIK, if you built r300_dri.so from Mesa CVS, you need libGL.so and its friends from the Mesa CVS also. If you did it already, please set: sysctl hw.dri.0.debug=1 Start Xorg and do: grep drm /var/log/messages drm_debug.txt Please send us drm_debug.txt. Thanks, Jung-uk Kim Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + FreeBSD -CURRENT?
On Monday 22 August 2005 03:53 pm, Adam K Kirchhoff wrote: Jung-uk Kim wrote: On Monday 22 August 2005 02:49 pm, Adam K Kirchhoff wrote: Vladimir Dergachev wrote: And so on, through /dev/dri/card254 Mind you, /dev/dri/card0 exists: [ [EMAIL PROTECTED] - ~ ]: ls -la /dev/dri total 1 dr-xr-xr-x 2 root wheel 512 Aug 21 18:37 . dr-xr-xr-x 5 root wheel 512 Dec 31 1969 .. crw-rw-rw- 1 root wheel0, 162 Aug 21 18:35 card0 Any ideas? Is the major ok ? On my (linux) system I get: crw-rw-rw- 1 root root 226, 0 Aug 21 19:07 card0 I would expect a difference, but, it might have changed.. Also, check that the DRM driver knows your PCI id. best Vladimir Dergachev It's listed: shared/drm_pciids.txt:0x1002 0x4153 CHIP_RV350 ATI Radeon AS 9600 AS Would the kernel driver even attach to the device (as it appears to be doing) if it didn't know my PCI ID? Correct. AFAIK, if you built r300_dri.so from Mesa CVS, you need libGL.so and its friends from the Mesa CVS also. It's all from Mesa CVS. If you did it already, please set: sysctl hw.dri.0.debug=1 Start Xorg and do: grep drm /var/log/messages drm_debug.txt Please send us drm_debug.txt. Attached. Thanks! It seems you built DRM from DRI CVS, right? Can you try the following patch and do the test again? http://people.freebsd.org/~jkim/fbsd_vs_drm-20050818.diff Thanks, Jung-uk Kim Adam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + FreeBSD -CURRENT?
On Monday 22 August 2005 06:23 pm, Adam K Kirchhoff wrote: Jung-uk Kim wrote: It seems you built DRM from DRI CVS, right? Yep. Is that not the correct way to do it these days? :-) It IS the correct way. However DRI CVS is not always stable, at least for FreeBSD. More stable version goes to FreeBSD CVS. Can you try the following patch and do the test again? http://people.freebsd.org/~jkim/fbsd_vs_drm-20050818.diff That patched solved my problems. I now have DRI working on FreeBSD with my r300. Thanks! Thank you for testing the patch, Jung-uk Kim --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm 32/64 bit... Linux + BSD..
On Tuesday 16 August 2005 07:16 pm, Dave Airlie wrote:
Hi all.
I've just checked into CVS, a patch from Egbert and Paul that
allows us to change the drm_handle size to 32-bits however I'm not
sure what to do with the BSD people...
We want to change the handle to unsigned int Should we just
ifdef around it for BSD?
Thanks for committing the fix but you missed few things. Additional
fix is attached. I am not sure this is right thing to do but it
seems to work.
Thanks,
Jung-uk Kim
Dave.
Index: shared-core/mga_dma.c
===
RCS file: /cvs/dri/drm/shared-core/mga_dma.c,v
retrieving revision 1.31
diff -u -r1.31 mga_dma.c
--- shared-core/mga_dma.c 16 Aug 2005 12:51:57 - 1.31
+++ shared-core/mga_dma.c 17 Aug 2005 17:40:50 -
@@ -819,7 +819,9 @@
DRM_ERROR(failed to find primary dma region!\n);
return DRM_ERR(EINVAL);
}
+#if defined(__linux__)
dev-agp_buffer_token = init-buffers_offset;
+#endif
dev-agp_buffer_map = drm_core_findmap(dev, init-buffers_offset);
if (!dev-agp_buffer_map) {
DRM_ERROR(failed to find dma buffer region!\n);
Index: shared-core/r128_cce.c
===
RCS file: /cvs/dri/drm/shared-core/r128_cce.c,v
retrieving revision 1.26
diff -u -r1.26 r128_cce.c
--- shared-core/r128_cce.c 16 Aug 2005 12:51:57 - 1.26
+++ shared-core/r128_cce.c 17 Aug 2005 17:40:50 -
@@ -323,8 +323,12 @@
ring_start = dev_priv-cce_ring-offset - dev-agp-base;
else
#endif
+#if defined(__linux__)
ring_start = dev_priv-cce_ring-offset -
(unsigned long)dev-sg-virtual;
+#else
+ ring_start = dev_priv-cce_ring-offset - dev-sg-handle;
+#endif
R128_WRITE(R128_PM4_BUFFER_OFFSET, ring_start | R128_AGP_OFFSET);
@@ -485,7 +489,9 @@
r128_do_cleanup_cce(dev);
return DRM_ERR(EINVAL);
}
+#if defined(__linux__)
dev-agp_buffer_token = init-buffers_offset;
+#endif
dev-agp_buffer_map = drm_core_findmap(dev, init-buffers_offset);
if (!dev-agp_buffer_map) {
DRM_ERROR(could not find dma buffer region!\n);
@@ -537,7 +543,11 @@
dev_priv-cce_buffers_offset = dev-agp-base;
else
#endif
+#if defined(__linux__)
dev_priv-cce_buffers_offset = (unsigned long)dev-sg-virtual;
+#else
+ dev_priv-cce_buffers_offset = dev-sg-handle;
+#endif
dev_priv-ring.start = (u32 *) dev_priv-cce_ring-handle;
dev_priv-ring.end = ((u32 *) dev_priv-cce_ring-handle
Index: shared-core/radeon_cp.c
===
RCS file: /cvs/dri/drm/shared-core/radeon_cp.c,v
retrieving revision 1.62
diff -u -r1.62 radeon_cp.c
--- shared-core/radeon_cp.c 16 Aug 2005 12:51:57 - 1.62
+++ shared-core/radeon_cp.c 17 Aug 2005 17:40:51 -
@@ -1423,7 +1423,9 @@
radeon_do_cleanup_cp(dev);
return DRM_ERR(EINVAL);
}
+#if defined(__linux__)
dev-agp_buffer_token = init-buffers_offset;
+#endif
dev-agp_buffer_map = drm_core_findmap(dev, init-buffers_offset);
if (!dev-agp_buffer_map) {
DRM_ERROR(could not find dma buffer region!\n);
Re: R300 drm patch
On Saturday 16 July 2005 12:11 pm, Vladimir Dergachev wrote:
* the patch includes changes to BSD code as well - these
need to be checked by people familiar with the platform
You missed a trivial Makefile patch. Other than that, it looks good.
Thanks,
Jung-uk Kim
Index: bsd-core/radeon/Makefile
===
RCS file: /cvs/dri/drm/bsd-core/radeon/Makefile,v
retrieving revision 1.6
diff -u -r1.6 Makefile
--- bsd-core/radeon/Makefile 26 Apr 2005 15:27:58 - 1.6
+++ bsd-core/radeon/Makefile 18 Jul 2005 15:52:20 -
@@ -3,7 +3,8 @@
.PATH: ${.CURDIR}/..
KMOD = radeon
NO_MAN = YES
-SRCS= radeon_cp.c radeon_drv.c radeon_state.c radeon_irq.c radeon_mem.c
+SRCS = r300_cmdbuf.c radeon_cp.c radeon_drv.c \
+ radeon_irq.c radeon_mem.c radeon_state.c
SRCS += device_if.h bus_if.h pci_if.h opt_drm.h
CFLAGS += ${DEBUG_FLAGS} -I. -I..
Re: No luck with Ati Radeon X600 (PCI express)
On Monday 18 July 2005 12:16 pm, Markus Niemistö wrote: Hi, I tried open-source r300 driver with my X600 (RV370) but everything I got was a black or very dark purple screen and a locked computer. AFAIK PCI-Express support is very experimental. I have tried this many times before but it never worked. This time I installed r300-driver as shown in http://lists.freebsd.org/pipermail/freebsd-x11/2005-May/001903.html and I actually got my X-desktop up and running for about a second or two. But only once. I made an additional modification to the source: there is no implementation of drm_device_is_pcie() for FreeBSD so I just put dev_priv-flags |= CHIP_IS_PCIE into radeon_preinit(). I have tried both with and without this patch and only the pure, clean CVS but nothing works. You may want to try 'R300 drm patch' posted by Vladimir Dergachev [EMAIL PROTECTED] few days ago. You also need a trivial patch posted by me today to build on FreeBSD. ;-) Jung-uk Kim Any suggestions where to start debugging? My system is FreeBSD 6.0 on Athlon64 + nForce 4. Attached is dmesg and Xorg.0.log. Thanks, Markus --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: No luck with Ati Radeon X600 (PCI express)
On Monday 18 July 2005 02:37 pm, Markus Niemistö wrote: On Ma, 2005-07-18 at 12:40 -0400, Jung-uk Kim wrote: You may want to try 'R300 drm patch' posted by Vladimir Dergachev [EMAIL PROTECTED] few days ago. You also need a trivial patch posted by me today to build on FreeBSD. ;-) I tried the patch, tough it didn't apply cleanily so I had to do some manual merging. But it didn't work either. I tried with and without ACPI but it seemed not to make any difference. It was clean patch for me, at least until this morning. Are you sure you CVS up'd it from DRM, not from R300? ACPI won't make any difference, BTW. Jung-uk Kim --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 bsd drm?
On Thursday 23 June 2005 08:17 am, Adam K Kirchhoff wrote: Jung-uk Kim wrote: On Wednesday 22 June 2005 06:55 pm, Adam K Kirchhoff wrote: At one point in the not-too-distant past, the r300 drm would compile on FreeBSD 5.4. After bringing a Radeon 9550 home from work to test out and being really impressed with how well the driver works (without those pesky 9800 specific lockups), I decided to give it a whirl in FreeBSD. Unfortunately, the drm module wouldn't compile: c -O -pipe -I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I.. -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_set_pciegart': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:1246: warning: unsigned int format, dma_addr_t arg (arg 5) /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_do_init_cp': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:1533: error: too many arguments to function `drm_ati_pcigart_init' /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_preinit': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:2087: warning: implicit declaration of function `drm_device_is_pcie' /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:2087: warning: nested extern declaration of `drm_device_is_pcie' *** Error code 1 Any ideas? Recent preliminary PCI-Express support code commit broke *BSD. I have a quick-and-dirty fix for this. If you are interested, let me know. Jung-uk Kim Definitely pass it along when you a chance :-) Thanks! FreeBSD build fix is committed. Cheers, Jung-uk Kim Adam --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 bsd drm?
On Wednesday 22 June 2005 06:55 pm, Adam K Kirchhoff wrote: At one point in the not-too-distant past, the r300 drm would compile on FreeBSD 5.4. After bringing a Radeon 9550 home from work to test out and being really impressed with how well the driver works (without those pesky 9800 specific lockups), I decided to give it a whirl in FreeBSD. Unfortunately, the drm module wouldn't compile: c -O -pipe -I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I.. -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_set_pciegart': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:1246: warning: unsigned int format, dma_addr_t arg (arg 5) /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_do_init_cp': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:1533: error: too many arguments to function `drm_ati_pcigart_init' /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c: In function `radeon_preinit': /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:2087: warning: implicit declaration of function `drm_device_is_pcie' /home/adamk/saved/source/drm/bsd-core/radeon/../radeon_cp.c:2087: warning: nested extern declaration of `drm_device_is_pcie' *** Error code 1 Any ideas? Recent preliminary PCI-Express support code commit broke *BSD. I have a quick-and-dirty fix for this. If you are interested, let me know. Jung-uk Kim --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Tuesday 19 April 2005 10:49 am, jan kreuzer wrote: Hi the fix you provided let the module get compiled. However when starting an GL-Application i get the following: glxgears Using 8 maximum texture units.. sizeof(drm_r300_cmd_header_t)=4 sizeof(drm_radeon_cmd_buffer_t)=32 Allocating 284420 bytes command buffer (max state is 11140 bytes) *WARN_ONCE* File r300_state.c function r300Enable line 518 TODO - double side stencil ! *** *WARN_ONCE* File r300_state.c function r300Enable line 539 Don't know how to enable polygon offset point/line. Help me ! *** drmRadeonCmdBuffer: -22 (exiting) And the following in the dmesg: error: [drm:pid596:r300_emit_unchecked_state] *ERROR* Unrecognized register range: 1d98 6 error: [drm:pid596:r300_do_cp_cmdbuf] *ERROR* r300_emit_unchecked_state failed In fact, I made it working too. A little bit ugly kludge is attached. You don't have to comment out r300_check_range(). Jung-uk Kim Greetings Jan Index: drmP.h === RCS file: /cvsroot/r300/r300_driver/drm/bsd-core/drmP.h,v retrieving revision 1.2 diff -u -r1.2 drmP.h --- drmP.h 2 Mar 2005 03:54:19 - 1.2 +++ drmP.h 19 Apr 2005 16:07:02 - @@ -255,6 +255,10 @@ typedef u_int16_t u16; typedef u_int8_t u8; +/* XXX: Linuxism */ +#define __init +#define __initdata + /* DRM_READMEMORYBARRIER() prevents reordering of reads. * DRM_WRITEMEMORYBARRIER() prevents reordering of writes. * DRM_MEMORYBARRIER() prevents reordering of reads and writes. Index: radeon_drv.c === RCS file: /cvsroot/r300/r300_driver/drm/bsd-core/radeon_drv.c,v retrieving revision 1.2 diff -u -r1.2 radeon_drv.c --- radeon_drv.c2 Mar 2005 03:54:20 - 1.2 +++ radeon_drv.c19 Apr 2005 16:07:02 - @@ -91,6 +91,7 @@ bzero(dev, sizeof(drm_device_t)); radeon_configure(dev); + r300_init_reg_flags(); /* XXX: shouldn't be here */ return drm_attach(nbdev, radeon_pciidlist); }
Re: [r300] what about *BSD?
On Tuesday 19 April 2005 10:18 am, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 15:42:43 +0200
Jan Kreuzer [EMAIL PROTECTED] wrote:
$ make
=== drm
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/drm === i915
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/i915 === mach64
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mach64 === mga
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mga === r128
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/r128 === radeon
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon cc -O -pipe
-I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I.. -I. -I@
-I@/contrib/altq -I@/../include -finline-limit=8000 \ -fno-common
-mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2
-mno-mmx -mno-3dnow -msoft-float \
-fno-asynchronous-unwind-tables -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes \ -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -std=c99 -c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:131: error: syntax error before r300_init_reg_flags
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:134: error: syntax error before numeric constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:134: warning: type defaults to `int' in declaration of `memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:134: warning: function declaration isn't a prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:134: error: conflicting types for 'memset' @/sys/libkern.h:118:
error: previous definition of 'memset' was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:134: warning: data definition has no type or storage class
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbuf.
c:60: warning: 'r300_emit_cliprects' defined but not used ***
Error code 1
Stop in /usr/home/jan/dri/r300_driver/drm/bsd-core/radeon.
*** Error code 1
So it seems that r300 would work (as good as in linux), if the
drm-part of it would be updated to compile under freebsd. But
this is beyond my skills.
Try this:
--- r300_cmdbuf.c.orig Tue Apr 19 17:14:33 2005
+++ r300_cmdbuf.c Tue Apr 19 17:14:49 2005
@@ -125,13 +125,12 @@
return 0;
}
-unsigned char r300_reg_flags[0x12];
+unsigned char r300_reg_flags[0x12]={ 0 };
-void __init r300_init_reg_flags(void)
+void r300_init_reg_flags(void)
{
int i;
-memset(r300_reg_flags, 0, 0x12);
memset() is okay and it is better that way (at least for
FreeBSD/amd64):
http://lists.freebsd.org/pipermail/freebsd-amd64/2005-March/004058.html
My experiment shows GCC misoptimizes this type of initialization on
AMD64 where glibc is not used (i. e., *BSD).
Removing __init is enough, I believe. Please see my previous posting.
Thanks,
Jung-uk Kim
#define ADD_RANGE(reg, count)
for(i=(reg2);i(reg2)+count;i++)r300_reg_flags[i]|=1;
/* these match cmducs() command in
r300_driver/r300/r300_cmdbuf.c */
Greetings Jan
---
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Tuesday 19 April 2005 02:02 pm, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 12:26:36 -0400
Jung-uk Kim [EMAIL PROTECTED] wrote:
On Tuesday 19 April 2005 10:18 am, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 15:42:43 +0200
Jan Kreuzer [EMAIL PROTECTED] wrote:
$ make
=== drm
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/drm === i915
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/i915 === mach64
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mach64 === mga
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mga === r128
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/r128 === radeon
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon cc -O -pipe
-I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I.. -I.
-I@ -I@/contrib/altq -I@/../include -finline-limit=8000 \
-fno-common -mcmodel=kernel -mno-red-zone -mfpmath=387
-mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float \
-fno-asynchronous-unwind-tables -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes \ -Wpointer-arith -Winline -Wcast-qual
-fformat-extensions -std=c99 -c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
buf. c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
buf. c:131: error: syntax error before r300_init_reg_flags
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
buf. c:134: error: syntax error before numeric constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
buf. c:134: warning: type defaults to `int' in declaration of
`memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
buf. c:134: warning: function declaration isn't a prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
buf. c:134: error: conflicting types for 'memset'
@/sys/libkern.h:118: error: previous definition of 'memset'
was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
buf. c:134: warning: data definition has no type or storage
class
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
buf. c:60: warning: 'r300_emit_cliprects' defined but not used
*** Error code 1
Stop in /usr/home/jan/dri/r300_driver/drm/bsd-core/radeon.
*** Error code 1
So it seems that r300 would work (as good as in linux), if
the drm-part of it would be updated to compile under freebsd.
But this is beyond my skills.
Try this:
--- r300_cmdbuf.c.orig Tue Apr 19 17:14:33 2005
+++ r300_cmdbuf.c Tue Apr 19 17:14:49 2005
@@ -125,13 +125,12 @@
return 0;
}
-unsigned char r300_reg_flags[0x12];
+unsigned char r300_reg_flags[0x12]={ 0 };
-void __init r300_init_reg_flags(void)
+void r300_init_reg_flags(void)
{
int i;
-memset(r300_reg_flags, 0, 0x12);
memset() is okay and it is better that way (at least for
FreeBSD/amd64):
http://lists.freebsd.org/pipermail/freebsd-amd64/2005-March/00405
8.html
My experiment shows GCC misoptimizes this type of initialization
on AMD64 where glibc is not used (i. e., *BSD).
Jans compiler doesnt seem to like memseting arrays:
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbu
f.c:134: error: syntax error before numeric constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbu
f.c:134: warning: type defaults to `int' in declaration of
`memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbu
f.c:134: warning: function declaration isn't a prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbu
f.c:134: error: conflicting types for 'memset'
@/sys/libkern.h:118: error: previous definition of 'memset' was
here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmdbu
f.c:134: warning: data definition has no type or storage class
Maybe just loop it to zero?
No, the previous syntax error (i. e., __init) was causing the second
syntax error. If you remove it, all the syntax errors disappear. ;-)
I would stick r300_init_reg_flags call to radeon_preinit() since it
seems to be called on bsds and x86s.
I'll try that and let you know.
Thanks,
Jung-uk Kim
Removing __init is enough, I believe. Please see my previous
posting.
Thanks,
Jung-uk Kim
#define ADD_RANGE(reg, count)
for(i=(reg2);i(reg2)+count;i++)r300_reg_flags[i]|=1;
/* these match cmducs() command in
r300_driver/r300/r300_cmdbuf.c */
Greetings Jan
---
This SF.Net email is sponsored by: New Crystal
Re: [r300] what about *BSD?
On Tuesday 19 April 2005 02:14 pm, Jung-uk Kim wrote:
On Tuesday 19 April 2005 02:02 pm, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 12:26:36 -0400
Jung-uk Kim [EMAIL PROTECTED] wrote:
On Tuesday 19 April 2005 10:18 am, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 15:42:43 +0200
Jan Kreuzer [EMAIL PROTECTED] wrote:
$ make
=== drm
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/drm === i915
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/i915 === mach64
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mach64 === mga
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mga === r128
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/r128 === radeon
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon cc -O
-pipe -I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I- -I.
-I.. -I. -I@ -I@/contrib/altq -I@/../include
-finline-limit=8000 \ -fno-common -mcmodel=kernel
-mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx
-mno-3dnow -msoft-float \ -fno-asynchronous-unwind-tables
-ffreestanding -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes \ -Wpointer-arith
-Winline -Wcast-qual -fformat-extensions -std=c99 -c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:131: error: syntax error before
r300_init_reg_flags
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:134: error: syntax error before numeric constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:134: warning: type defaults to `int' in
declaration of `memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:134: warning: function declaration isn't a
prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:134: error: conflicting types for 'memset'
@/sys/libkern.h:118: error: previous definition of 'memset'
was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:134: warning: data definition has no type or
storage class
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_c
md buf. c:60: warning: 'r300_emit_cliprects' defined but not
used *** Error code 1
Stop in /usr/home/jan/dri/r300_driver/drm/bsd-core/radeon.
*** Error code 1
So it seems that r300 would work (as good as in linux), if
the drm-part of it would be updated to compile under
freebsd. But this is beyond my skills.
Try this:
--- r300_cmdbuf.c.orig Tue Apr 19 17:14:33 2005
+++ r300_cmdbuf.c Tue Apr 19 17:14:49 2005
@@ -125,13 +125,12 @@
return 0;
}
-unsigned char r300_reg_flags[0x12];
+unsigned char r300_reg_flags[0x12]={ 0 };
-void __init r300_init_reg_flags(void)
+void r300_init_reg_flags(void)
{
int i;
-memset(r300_reg_flags, 0, 0x12);
memset() is okay and it is better that way (at least for
FreeBSD/amd64):
http://lists.freebsd.org/pipermail/freebsd-amd64/2005-March/004
05 8.html
My experiment shows GCC misoptimizes this type of
initialization on AMD64 where glibc is not used (i. e., *BSD).
Jans compiler doesnt seem to like memseting arrays:
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
bu f.c:134: error: syntax error before numeric constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
bu f.c:134: warning: type defaults to `int' in declaration of
`memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
bu f.c:134: warning: function declaration isn't a prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
bu f.c:134: error: conflicting types for 'memset'
@/sys/libkern.h:118: error: previous definition of 'memset'
was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300_cmd
bu f.c:134: warning: data definition has no type or storage
class
Maybe just loop it to zero?
No, the previous syntax error (i. e., __init) was causing the
second syntax error. If you remove it, all the syntax errors
disappear. ;-)
I would stick r300_init_reg_flags call to radeon_preinit() since
it seems to be called on bsds and x86s.
I'll try that and let you know.
It doesn't seem to work. In fact, I tried it in many different places
but there's no good place to put in. :-( Any idea?
Thanks,
Jung-uk Kim
Thanks,
Jung-uk Kim
Removing __init is enough, I believe. Please see my previous
posting
Re: [r300] what about *BSD?
On Tuesday 19 April 2005 04:45 pm, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 16:09:45 -0400
Jung-uk Kim [EMAIL PROTECTED] wrote:
On Tuesday 19 April 2005 02:14 pm, Jung-uk Kim wrote:
On Tuesday 19 April 2005 02:02 pm, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 12:26:36 -0400
Jung-uk Kim [EMAIL PROTECTED] wrote:
On Tuesday 19 April 2005 10:18 am, Aapo Tahkola wrote:
On Tue, 19 Apr 2005 15:42:43 +0200
Jan Kreuzer [EMAIL PROTECTED] wrote:
$ make
=== drm
Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/drm ===
i915 Warning: Object directory not changed from
original
/usr/home/jan/dri/r300_driver/drm/bsd-core/i915 ===
mach64 Warning: Object directory not changed from
original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mach64 ===
mga Warning: Object directory not changed from original
/usr/home/jan/dri/r300_driver/drm/bsd-core/mga ===
r128 Warning: Object directory not changed from
original
/usr/home/jan/dri/r300_driver/drm/bsd-core/r128 ===
radeon Warning: Object directory not changed from
original
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon cc -O
-pipe -I. -I.. -D_KERNEL -DKLD_MODULE -nostdinc -I-
-I. -I.. -I. -I@ -I@/contrib/altq -I@/../include
-finline-limit=8000 \ -fno-common -mcmodel=kernel
-mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx
-mno-3dnow -msoft-float \
-fno-asynchronous-unwind-tables -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes \ -Wpointer-arith -Winline
-Wcast-qual -fformat-extensions -std=c99 -c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r3
00_c md buf. c
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r3
00_c md buf. c:131: error: syntax error before
r300_init_reg_flags
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r3
00_c md buf. c:134: error: syntax error before numeric
constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r3
00_c md buf. c:134: warning: type defaults to `int' in
declaration of `memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r3
00_c md buf. c:134: warning: function declaration isn't
a prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r3
00_c md buf. c:134: error: conflicting types for
'memset' @/sys/libkern.h:118: error: previous
definition of 'memset' was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r3
00_c md buf. c:134: warning: data definition has no type
or storage class
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r3
00_c md buf. c:60: warning: 'r300_emit_cliprects'
defined but not used *** Error code 1
Stop in
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon. ***
Error code 1
So it seems that r300 would work (as good as in linux),
if the drm-part of it would be updated to compile under
freebsd. But this is beyond my skills.
Try this:
--- r300_cmdbuf.c.orig Tue Apr 19 17:14:33 2005
+++ r300_cmdbuf.c Tue Apr 19 17:14:49 2005
@@ -125,13 +125,12 @@
return 0;
}
-unsigned char r300_reg_flags[0x12];
+unsigned char r300_reg_flags[0x12]={ 0 };
-void __init r300_init_reg_flags(void)
+void r300_init_reg_flags(void)
{
int i;
-memset(r300_reg_flags, 0, 0x12);
memset() is okay and it is better that way (at least for
FreeBSD/amd64):
http://lists.freebsd.org/pipermail/freebsd-amd64/2005-March
/004 05 8.html
My experiment shows GCC misoptimizes this type of
initialization on AMD64 where glibc is not used (i. e.,
*BSD).
Jans compiler doesnt seem to like memseting arrays:
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300
_cmd bu f.c:134: error: syntax error before numeric
constant
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300
_cmd bu f.c:134: warning: type defaults to `int' in
declaration of `memset'
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300
_cmd bu f.c:134: warning: function declaration isn't a
prototype
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300
_cmd bu f.c:134: error: conflicting types for 'memset'
@/sys/libkern.h:118: error: previous definition of
'memset' was here
/usr/home/jan/dri/r300_driver/drm/bsd-core/radeon/../r300
_cmd bu f.c:134: warning: data definition has no type or
storage class
Maybe just loop it to zero?
No, the previous syntax error (i. e., __init) was causing the
second syntax error. If you remove it, all
Re: [r300] what about *BSD?
On Wednesday 30 March 2005 01:52 am, Jerome Glisse wrote:
On Tue, 29 Mar 2005 13:20:01 -0500, Jung-uk Kim [EMAIL PROTECTED]
wrote:
On Monday 28 March 2005 03:22 pm, Jung-uk Kim wrote:
On Saturday 26 March 2005 07:03 am, Jerome Glisse wrote:
Wait, I have one thing that's not from CVS. I patched
system compiler from GCC 3.4.2 to GCC 3.4.4 snapshot
(20050318). I updated GCC because I found some nasty
optimization bugs for AMD64 in GCC 3.4.2. Can this be the
fix?
Maybe, weird things can happen... To tell the true have no
clue if this gcc upgrade have fix this...Anyway now it works
for you. Do you have any freeze now (try moving,resizing gl
window, or some glintensive app...) ?
Actually, I was excited too early. After I set
LIBGL_DEBUG=verbose, I found loading r300_dri.so failed
(because of Mesa's 3DLab shader language commits). :-( I was
fooled because it was quite faster than indirect rendering
(although I have no idea why). Any way, I just updated Mesa
again (which disabled mesa_slang thingy but not completely) and
now it's broken as before. It's flickering and stretched as
before and it's not just hung for a while but blanked display
completely (maybe because Mesa partially disabled 3dlabs
thingy?) and glxgears is hung on DRM_WAIT_ON() as before.
To make sure I am not doing anything stupid, I copied Xorg, Mesa,
and DRI binaries to my desktop with RV280 (Athlon 64, same
kernel, same DRM, etc.) and it worked perfectly fine. glxgears
yields close to 3,000 FPS. So I guess it's R300 issue. :-(
I guess there must things to do in the drm in order to make it work
with r300 on BSD. If you feel it, you can try see if you see any
things that is BSD specifique in r200 drm and see if you can adapt
it to r300 drm.
AFAIK, there's nothing r200 specific. In fact, r300 requires a magic
to start with:
static int
radeon_attach(device_t nbdev)
{
drm_device_t *dev = device_get_softc(nbdev);
bzero(dev, sizeof(drm_device_t));
radeon_configure(dev);
---r300_init_reg_flags();
return drm_attach(nbdev, radeon_pciidlist);
}
Inspired by this commit:
http://cvs.sourceforge.net/viewcvs.py/r300/r300_driver/drm/linux-core/radeon_drv.c?r1=1.2r2=1.3
BTW, can't this be moved to the end of radeon_configure() or
somewhere? Is it possible the different init path between the two
OSes breaks r300?
Thanks,
Jung-uk Kim
I will take a look at this if i get time (which will be difficult
:)).
best,
Jerome Glisse
---
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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Wednesday 30 March 2005 12:17 pm, Jung-uk Kim wrote:
On Wednesday 30 March 2005 01:52 am, Jerome Glisse wrote:
On Tue, 29 Mar 2005 13:20:01 -0500, Jung-uk Kim [EMAIL PROTECTED]
wrote:
On Monday 28 March 2005 03:22 pm, Jung-uk Kim wrote:
On Saturday 26 March 2005 07:03 am, Jerome Glisse wrote:
Wait, I have one thing that's not from CVS. I patched
system compiler from GCC 3.4.2 to GCC 3.4.4 snapshot
(20050318). I updated GCC because I found some nasty
optimization bugs for AMD64 in GCC 3.4.2. Can this be the
fix?
Maybe, weird things can happen... To tell the true have no
clue if this gcc upgrade have fix this...Anyway now it
works for you. Do you have any freeze now (try
moving,resizing gl window, or some glintensive app...) ?
Actually, I was excited too early. After I set
LIBGL_DEBUG=verbose, I found loading r300_dri.so failed
(because of Mesa's 3DLab shader language commits). :-( I was
fooled because it was quite faster than indirect rendering
(although I have no idea why). Any way, I just updated Mesa
again (which disabled mesa_slang thingy but not completely)
and now it's broken as before. It's flickering and stretched
as before and it's not just hung for a while but blanked
display completely (maybe because Mesa partially disabled
3dlabs thingy?) and glxgears is hung on DRM_WAIT_ON() as
before.
To make sure I am not doing anything stupid, I copied Xorg,
Mesa, and DRI binaries to my desktop with RV280 (Athlon 64,
same kernel, same DRM, etc.) and it worked perfectly fine.
glxgears yields close to 3,000 FPS. So I guess it's R300
issue. :-(
I guess there must things to do in the drm in order to make it
work with r300 on BSD. If you feel it, you can try see if you see
any things that is BSD specifique in r200 drm and see if you can
adapt it to r300 drm.
AFAIK, there's nothing r200 specific. In fact, r300 requires a
magic to start with:
static int
radeon_attach(device_t nbdev)
{
drm_device_t *dev = device_get_softc(nbdev);
bzero(dev, sizeof(drm_device_t));
radeon_configure(dev);
---r300_init_reg_flags();
return drm_attach(nbdev, radeon_pciidlist);
}
Inspired by this commit:
http://cvs.sourceforge.net/viewcvs.py/r300/r300_driver/drm/linux-co
re/radeon_drv.c?r1=1.2r2=1.3
BTW, can't this be moved to the end of radeon_configure() or
somewhere?
I meant some r300-specific init function. radeon_configure() is
BSD-specific.
Sorry for the confusion,
Jung-uk Kim
Is it possible the different init path between the two OSes breaks
r300?
Thanks,
Jung-uk Kim
I will take a look at this if i get time (which will be difficult
:)).
best,
Jerome Glisse
---
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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Monday 28 March 2005 03:22 pm, Jung-uk Kim wrote: On Saturday 26 March 2005 07:03 am, Jerome Glisse wrote: Wait, I have one thing that's not from CVS. I patched system compiler from GCC 3.4.2 to GCC 3.4.4 snapshot (20050318). I updated GCC because I found some nasty optimization bugs for AMD64 in GCC 3.4.2. Can this be the fix? Maybe, weird things can happen... To tell the true have no clue if this gcc upgrade have fix this...Anyway now it works for you. Do you have any freeze now (try moving,resizing gl window, or some glintensive app...) ? Actually, I was excited too early. After I set LIBGL_DEBUG=verbose, I found loading r300_dri.so failed (because of Mesa's 3DLab shader language commits). :-( I was fooled because it was quite faster than indirect rendering (although I have no idea why). Any way, I just updated Mesa again (which disabled mesa_slang thingy but not completely) and now it's broken as before. It's flickering and stretched as before and it's not just hung for a while but blanked display completely (maybe because Mesa partially disabled 3dlabs thingy?) and glxgears is hung on DRM_WAIT_ON() as before. To make sure I am not doing anything stupid, I copied Xorg, Mesa, and DRI binaries to my desktop with RV280 (Athlon 64, same kernel, same DRM, etc.) and it worked perfectly fine. glxgears yields close to 3,000 FPS. So I guess it's R300 issue. :-( Jung-uk Kim Sorry for the noise, Jung-uk Kim Jerome Glisse --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Saturday 26 March 2005 07:03 am, Jerome Glisse wrote: Wait, I have one thing that's not from CVS. I patched system compiler from GCC 3.4.2 to GCC 3.4.4 snapshot (20050318). I updated GCC because I found some nasty optimization bugs for AMD64 in GCC 3.4.2. Can this be the fix? Maybe, weird things can happen... To tell the true have no clue if this gcc upgrade have fix this...Anyway now it works for you. Do you have any freeze now (try moving,resizing gl window, or some glintensive app...) ? Actually, I was excited too early. After I set LIBGL_DEBUG=verbose, I found loading r300_dri.so failed (because of Mesa's 3DLab shader language commits). :-( I was fooled because it was quite faster than indirect rendering (although I have no idea why). Any way, I just updated Mesa again (which disabled mesa_slang thingy but not completely) and now it's broken as before. It's flickering and stretched as before and it's not just hung for a while but blanked display completely (maybe because Mesa partially disabled 3dlabs thingy?) and glxgears is hung on DRM_WAIT_ON() as before. Sorry for the noise, Jung-uk Kim Jerome Glisse --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 problem with CVS from today...
On Monday 28 March 2005 08:16 pm, Adam K Kirchhoff wrote: [ [EMAIL PROTECTED] - ~ ]: glxgears -info libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed (/usr/X11R6/lib/modules/dri/r200_dri.so: undefined symbol: _mesa_3dlabs_create_program_object) libGL error: unable to find driver: r200_dri.so http://sourceforge.net/mailarchive/forum.php?thread_id=6901710forum_id=5154 Jung-uk Kim I've never seen that one before :-) Adam --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Thursday 17 March 2005 01:02 pm, Jung-uk Kim wrote: On Thursday 17 March 2005 07:33 am, Jerome Glisse wrote: I rebuilt Xorg from CVS. It's actually ran glxgears this time! However in few seconds it just locked up OS (i. e., infinitely looping syscalls - 100% CPU load). Another interesting thing is the gears are twice bigger than normal size and it looks interlaced. r300_demo shows the same symptom. Any thought? There are issue with mouse try to run glxgears and don't do anymouse movement, it shouldn't lock, if it locks this likely due to others issues. I was wrong about 100% CPU load. In fact, it was almost 100% idle. I can move mouse but I cannot type. I see ~50 IRQs per second from drm. When I tries to kill Xorg, then CPU load goes up 100%. Funny thing is I waited about 5 minutes (while copying the debugging output), gears started turning again! I set RADEON_DEBUG=all and the last lines before few minute pause were: r300ResetHwState r300Flush r300FlushCmdBufLocked from r300Flush - 1 cliprects Syncing in r300FlushCmdBufLocked (from r300Flush) r300Enable( GL_DEPTH_TEST = GL_TRUE ) r300Enable( GL_STENCIL_TEST = GL_FALSE ) Enabling VB-ObjPtr Enabling VB-ColorPtr[0] RR[0] - sz=4, reg-0, fmt=1 -- st=4, of=0x RR[0] - sz=4, reg-1, fmt=3 -- st=4, of=0x Could you grab a screenshot of the interlaced effects ? I backed up my previous /usr/X11R6 directory and installed Xorg from CVS, so I cannot make glxgears' screenshot. The attachment is from r300_demo instead but you'll see what I mean. I have no idea who fixed it but I am able to run glxgears and tuxracer reliably now! glxgears yields ~840FPS on FreeBSD/amd64 6-CURRENT. It's slower than expected but that's a start. ;-) FYI, everything's checked out from CVS today, i. e., FreeBSD, r300, Xorg, and Mesa... Cheers, Jung-uk Kim Thanks, Jung-uk Kim Jerome Glisse --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Friday 25 March 2005 06:08 pm, Jung-uk Kim wrote: On Thursday 17 March 2005 01:02 pm, Jung-uk Kim wrote: On Thursday 17 March 2005 07:33 am, Jerome Glisse wrote: I rebuilt Xorg from CVS. It's actually ran glxgears this time! However in few seconds it just locked up OS (i. e., infinitely looping syscalls - 100% CPU load). Another interesting thing is the gears are twice bigger than normal size and it looks interlaced. r300_demo shows the same symptom. Any thought? There are issue with mouse try to run glxgears and don't do anymouse movement, it shouldn't lock, if it locks this likely due to others issues. I was wrong about 100% CPU load. In fact, it was almost 100% idle. I can move mouse but I cannot type. I see ~50 IRQs per second from drm. When I tries to kill Xorg, then CPU load goes up 100%. Funny thing is I waited about 5 minutes (while copying the debugging output), gears started turning again! I set RADEON_DEBUG=all and the last lines before few minute pause were: r300ResetHwState r300Flush r300FlushCmdBufLocked from r300Flush - 1 cliprects Syncing in r300FlushCmdBufLocked (from r300Flush) r300Enable( GL_DEPTH_TEST = GL_TRUE ) r300Enable( GL_STENCIL_TEST = GL_FALSE ) Enabling VB-ObjPtr Enabling VB-ColorPtr[0] RR[0] - sz=4, reg-0, fmt=1 -- st=4, of=0x RR[0] - sz=4, reg-1, fmt=3 -- st=4, of=0x Could you grab a screenshot of the interlaced effects ? I backed up my previous /usr/X11R6 directory and installed Xorg from CVS, so I cannot make glxgears' screenshot. The attachment is from r300_demo instead but you'll see what I mean. I have no idea who fixed it but I am able to run glxgears and tuxracer reliably now! glxgears yields ~840FPS on FreeBSD/amd64 6-CURRENT. It's slower than expected but that's a start. ;-) FYI, everything's checked out from CVS today, i. e., FreeBSD, r300, Xorg, and Mesa... Wait, I have one thing that's not from CVS. I patched system compiler from GCC 3.4.2 to GCC 3.4.4 snapshot (20050318). I updated GCC because I found some nasty optimization bugs for AMD64 in GCC 3.4.2. Can this be the fix? Thanks, Jung-uk Kim Cheers, Jung-uk Kim Thanks, Jung-uk Kim Jerome Glisse --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problems with DRI on FreeBSD 6.8.2
On Sunday 20 March 2005 10:29 am, Adam K Kirchhoff wrote: So I can't seem to get direct rendering enabled with 6.8.2 on my freebsd installation at the moment. This is what I'm seeing in the Xorg log file: (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 (EE) RADEON(0): [drm] Failed to map vertex/indirect buffers list (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc57fe000 at 0x283c7000 (II) RADEON(0): Render acceleration disabled (II) RADEON(0): Direct rendering disabled Any ideas? We need to know kernel version and chipset info. Jung-uk Kim --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Friday 18 March 2005 02:38 am, Jerome Glisse wrote: I backed up my previous /usr/X11R6 directory and installed Xorg from CVS, so I cannot make glxgears' screenshot. The attachment is from r300_demo instead but you'll see what I mean. Were you in 16bpp ? This could be that... No, it was 24bpp. Does it make a difference? Anyway r300 demo is really a card playing application... The point was the glxgears showed similar problems and flickering. Jung-uk Kim Jerome Glisse --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Wednesday 16 March 2005 08:46 am, Jerome Glisse wrote: On Tue, 15 Mar 2005 18:36:21 -0500, Jung-uk Kim [EMAIL PROTECTED] wrote: On Tuesday 15 March 2005 05:06 pm, Aapo Tahkola wrote: After reading all the promising success stories about the r300 project, I am wondering whether anybody successfully tried it on a *BSD. Some time ago I tried on DragonFly BSD and in Xorg.0.log I found a message that DRI was enabled, but glxinfo said direct rendering: No. DRMs BSD support was added blindfold without any testing so it might not work as expected. You might want to check out steps after Xorg says DRI is enabled from http://dri.freedesktop.org/wiki/DriTroubleshooting . I have sort of working drm but I always get this from drm when I run glxinfo or glxgears: drm0: ATI Radeon RV300 Mobility 9600 M10 port 0x2000-0x20ff mem 0xd010-0xd010,0xd800-0xdfff irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xe000 256MB info: [drm] Initialized radeon 1.15.0 20050208 on minor 0 info: [drm] Loading R300 Microcode error: [drm:pid12690:r300_do_cp_cmdbuf] *ERROR* bad cmd_type 255 at 0xffbaf800 and Using 8 maximum texture units.. sizeof(drm_r300_cmd_header_t)=4 sizeof(drm_radeon_cmd_buffer_t)=32 Allocating 284420 bytes command buffer (max state is 11140 bytes) *WARN_ONCE*** ** File r300_state.c function r300Enable line 516 Don't know how to enable polygon offset point/line. Help me ! * ** drmRadeonCmdBuffer: -22 (exiting) Any idea? BTW, it's FreeBSD/amd64 6-CURRENT with today's r300. Thanks, Jung-uk Kim Did you get lastest Xorg CVS, this likely due to the fact that you got a too old Xorg. I rebuilt Xorg from CVS. It's actually ran glxgears this time! However in few seconds it just locked up OS (i. e., infinitely looping syscalls - 100% CPU load). Another interesting thing is the gears are twice bigger than normal size and it looks interlaced. r300_demo shows the same symptom. Any thought? Thanks! Jung-uk Kim Jerome Glisse --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
On Tuesday 15 March 2005 05:06 pm, Aapo Tahkola wrote: After reading all the promising success stories about the r300 project, I am wondering whether anybody successfully tried it on a *BSD. Some time ago I tried on DragonFly BSD and in Xorg.0.log I found a message that DRI was enabled, but glxinfo said direct rendering: No. DRMs BSD support was added blindfold without any testing so it might not work as expected. You might want to check out steps after Xorg says DRI is enabled from http://dri.freedesktop.org/wiki/DriTroubleshooting . I have sort of working drm but I always get this from drm when I run glxinfo or glxgears: drm0: ATI Radeon RV300 Mobility 9600 M10 port 0x2000-0x20ff mem 0xd010-0xd010,0xd800-0xdfff irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xe000 256MB info: [drm] Initialized radeon 1.15.0 20050208 on minor 0 info: [drm] Loading R300 Microcode error: [drm:pid12690:r300_do_cp_cmdbuf] *ERROR* bad cmd_type 255 at 0xffbaf800 and Using 8 maximum texture units.. sizeof(drm_r300_cmd_header_t)=4 sizeof(drm_radeon_cmd_buffer_t)=32 Allocating 284420 bytes command buffer (max state is 11140 bytes) *WARN_ONCE* File r300_state.c function r300Enable line 516 Don't know how to enable polygon offset point/line. Help me ! *** drmRadeonCmdBuffer: -22 (exiting) Any idea? BTW, it's FreeBSD/amd64 6-CURRENT with today's r300. Thanks, Jung-uk Kim Thanks, Johannes --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
