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
