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
