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[0x1>>2];
> > > > > > +unsigned char r300_reg_flags[0x1>>2]={ 0 };
> > > > > >
> > > > > >
> > > > > > -void __init r300_init_reg_flags(void)
> > > > > > +void r300_init_reg_flags(void)
> > > > > > {
> > > > > > int i;
> > > > > > -memset(r300_reg_flags, 0, 0x1>>2);
> > > > >
> > > > > 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 defaul
Re: [r300] what about *BSD?
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/../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[0x1>>2];
> > > > > +unsigned char r300_reg_flags[0x1>>2]={ 0 };
> > > > >
> > > > >
> > > > > -void __init r300_init_reg_flags(void)
> > > > > +void r300_init_reg_flags(void)
> > > > > {
> > > > > int i;
> > > > > -memset(r300_reg_flags, 0, 0x1>>2);
> > > >
> > > > 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
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[0x1>>2];
> > > > +unsigned char r300_reg_flags[0x1>>2]={ 0 };
> > > >
> > > >
> > > > -void __init r300_init_reg_flags(void)
> > > > +void r300_init_reg_flags(void)
> > > > {
> > > > int i;
> > > > -memset(r300_reg_flags, 0, 0x1>>2);
> > >
> > > 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 causi
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 > Thanks your patch works also fine for me. In fact with my previous approach (Aapos patch and the uncommenting of r300_check_range by myside) some GL-Apps i could test worked (eg neverball, glxgears, xscreensaver-modules), whereas other just produced an segfault (celestia). Now even celestia runs. Thanks for your time and work both Aapo and Jung-uk Greetings Jan -- +++ NEU: GMX DSL_Flatrate! Schon ab 14,99 EUR/Monat! +++ GMX Garantie: Surfen ohne Tempo-Limit! http://www.gmx.net/de/go/dsl --- 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[0x1>>2];
> > > +unsigned char r300_reg_flags[0x1>>2]={ 0 };
> > >
> > >
> > > -void __init r300_init_reg_flags(void)
> > > +void r300_init_reg_flags(void)
> > > {
> > > int i;
> > > -memset(r300_reg_flags, 0, 0x1>>2);
> >
> > 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 se
Re: [r300] what about *BSD?
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_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[0x1>>2];
> > +unsigned char r300_reg_flags[0x1>>2]={ 0 };
> >
> >
> > -void __init r300_init_reg_flags(void)
> > +void r300_init_reg_flags(void)
> > {
> > int i;
> > -memset(r300_reg_flags, 0, 0x1>>2);
>
> 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).
Jans compiler doesnt seem to like memseting arrays:
>>> /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
Maybe just loop it to zero?
I would stick r300_init_reg_flags call to radeon_preinit() since it seems to be
called on bsds and x86s.
>
> Removing __init is enough, I believe. Please see my previous posting.
>
> Thanks,
>
> Jung-uk Kim
>
> > #define ADD_RANGE(reg, count)
> > for(i=(reg>>2);i<(reg>>2)+count;i++)r300_reg_flags[i]|=1;
> >
> > /* these match cmducs() command in
> > r300_driver/r300/r300_cmdbuf.c */
> >
> > > Greetings Jan
--
Aapo Tahkola
---
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
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[0x1>>2];
> +unsigned char r300_reg_flags[0x1>>2]={ 0 };
>
>
> -void __init r300_init_reg_flags(void)
> +void r300_init_reg_flags(void)
> {
> int i;
> -memset(r300_reg_flags, 0, 0x1>>2);
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=(reg>>2);i<(reg>>2)+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 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?
Ok after i commented the r300_check_range function (line 256 in r300_cmdbuf.c) glxgears and xscreensaver work. No i am compiling some GL-Progs under FreeBSD and see if they work also. Greetings Jan -- +++ GMX - Die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail --- 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?
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 Greetings Jan -- +++ GMX - Die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail --- 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 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[0x1>>2];
+unsigned char r300_reg_flags[0x1>>2]={ 0 };
-void __init r300_init_reg_flags(void)
+void r300_init_reg_flags(void)
{
int i;
-memset(r300_reg_flags, 0, 0x1>>2);
#define ADD_RANGE(reg, count)
for(i=(reg>>2);i<(reg>>2)+count;i++)r300_reg_flags[i]|=1;
/* these match cmducs() command in r300_driver/r300/r300_cmdbuf.c */
>
> Greetings Jan
>
--
Aapo Tahkola
---
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 Tue, 15 Mar 2005 18:36:21 -0500, Jung-uk Kim <[EMAIL PROTECTED]> wrote: > I have sort of working drm but I always get this from drm when I run > glxinfo or glxgears: > > drm0: 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 Hi i just installed freebsd-5.3 and did cvsup to stable (RELENG_5). After modifying the xorg-server port to include the cvs-ati drivers and compiling drm-cvs from today i am able to start Xorg with dri enabled for r300. Glxinfo says that direct-rendering is enabled. However whenever i start an GL-application (like glxgears) i get the same error message as you did. I think this is because r300_driver has his own drm-modules (which include r300_cmdbuf.c). I have also the same error under linux-2.6 when i use kernels-drm. However trying to compile the drm-module from r300_driver under freebsd gives me the following error: $ 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. 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 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.2&r2=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=6595&alloc_id=14396&op=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.2&r2=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=6595&alloc_id=14396&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
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. 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=6595&alloc_id=14396&op=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=6595&alloc_id=14396&op=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=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
> 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...) ? 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=6595&alloc_id=14396&op=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=6595&alloc_id=14396&op=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=6595&alloc_id=14396&op=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=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
> 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... Anyway r300 demo is really a card playing application... 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=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
> 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. Could you grab a screenshot of the interlaced effects ? 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=6595&alloc_id=14396&op=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: 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=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
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: 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. 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=6595&alloc_id=14396&op=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: 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=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
> 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 . > > Thanks, > Johannes -- Aapo Tahkola --- 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_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] what about *BSD?
Johannes Hofmann 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". A few weeks ago I tried to get the r300_driver drm bsd-core driver to compile on FreeBSD, but it errored out. That was my first and last attempt to get it working :-) 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=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
