Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 01 Oct 2008 22:44:56 -0400
From:      Robert Noland <rnoland@FreeBSD.org>
To:        Warren Block <wblock@wonkity.com>
Cc:        x11@freebsd.org
Subject:   Re: Radeon testing
Message-ID:  <1222915496.1684.26.camel@wombat.2hip.net>
In-Reply-To: <alpine.BSF.2.00.0810011925270.30960@wonkity.com>
References:  <alpine.BSF.2.00.0810011925270.30960@wonkity.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--=-0GEAU3yK20xomBdx0rOl
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2008-10-01 at 19:36 -0600, Warren Block wrote:
> I have access to five Radeon cards of differing ages and generations,=20
> all on machines with FreeBSD 7-stable of recent vintage.

=46rom a drm perspective, 7 still has really stale bits... I recently made
updates to -CURRENT and I'm likely to do another one in the near future.
(read, maybe as soon as tomorrow).  I currently don't have access to any
radeon hardware, so I have to rely on others to test code for me.  It
would be really handy to have someone who was able to test on hardware
of various generations.

> What testing or benchmarking utilities should be used?  What would be=20
> useful for driver debugging?

xscreensaver hacks are probably reasonable.  There is also rendercheck,
which isn't very exciting, but does perform a lot of tests.  drm is
certainly not the only relevant part, but I attempt to let other folks
deal with the mesa (libGL) and X side of things.  Those components are
more portable and therefore issues that crop up there tend to effect the
linux folks as well and they have a lot more resources to deal with
those than we do.

> So far, only one can run the xscreensaver "carousel" full-screen without=20
> killing X.  glxgears is not supposed to be a benchmark, and glxinfo=20
> reports a lot of information that may or may not be useful.  Beyond=20
> dmesg, uname, and Xorg.0.log, what other information would be helpful?

Please define "killing X".

As long as we are talking about kernel components, that is drm and has
become my responsibility...  What is useful information really depends
on exactly what the failure is and/or what is being tested.  Generally,
dmesg, architecture (i386 or amd64) and some mechanism of identifying
exactly what bits of code your running are useful along with X logs.
Other times, I need drm debugging dumps and / or backtraces...

robert.

> -Warren Block * Rapid City, South Dakota USA
> _______________________________________________
> freebsd-x11@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org"

--=-0GEAU3yK20xomBdx0rOl
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEABECAAYFAkjkNagACgkQM4TrQ4qfROMKagCfRP6ReqKl2ldXwIZLz/baw+2K
QecAn0r1ULgpp9lwPhdW5I476JoHh6Tq
=ZOa/
-----END PGP SIGNATURE-----

--=-0GEAU3yK20xomBdx0rOl--




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1222915496.1684.26.camel>