Date: Wed, 23 Dec 2009 09:46:56 -0600 From: Robert Noland <rnoland@FreeBSD.org> To: Alex Kozlov <spam@rm-rf.kiev.ua> Cc: ports@FreeBSD.org, x11@FreeBSD.org, Norikatsu Shigemura <nork@FreeBSD.org> Subject: Re: [HEADS UP] Experimental 3D HW accel support for Radeon HD 2xxx, 3xxx and 4xxx, 2nd! Message-ID: <1261583216.2304.68.camel@balrog.2hip.net> In-Reply-To: <20091223061535.GA90713@ravenloft.kiev.ua> References: <20091223061535.GA90713@ravenloft.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2009-12-23 at 08:15 +0200, Alex Kozlov wrote:
> On Tue, Dec 22, 2009 at 11:38:50PM -0600, Robert Noland wrote:
> > On Wed, 2009-12-23 at 07:31 +0200, Alex Kozlov wrote:
> > > On Wed, Dec 23, 2009 at 02:03:15AM +0900, Norikatsu Shigemura wrote:
> > > > On Tue, 22 Dec 2009 00:26:38 -0600 Robert Noland <rnoland@FreeBSD.org> wrote:
> > > > > As much as I don't want to, I need to request a repo copy of libdrm in
> > > > > order to keep nouveau working... The bits needed for r600 were added
> > > > > just after 2.4.12 and the bits that broke nouveau were just before
> > > > > 2.4.13...
> > > >
> > > > Ah, I just see! ABI breakage is building issue, I confirmed:
> > > >
> > > > I think simple-fully xf86-video-nouveau updating at the same
> > > > time. Please see also attached patch. I confirmed that
> > > > compile is OK. But I don't have any GeForce video cards.
> > > > So I don't know any problems of updating it in real.
> > > >
> > > > And do you have any recommendation of GeForce? e.g. 9800GTX,
> > > > GT260, ... I'll get one and test. I'm interested in Cuda
> > > > and nvidia binary driver, too.
> > > >
> > > > P.S. libdrm was update to 2.4.17, so I'll update...
> > > I just tested libdrm 2.4.17 with --enable-radeon-experimental-api
> > > and mesalib git master. It's work quite good. Well, it worked
> > > quite good before
> >
> > I've said it before, but I'll repeat... libdrm_radeon serves no purpose
> > on FreeBSD and may cause problems. It is only used by TTM/KMS enabled
> > drivers on linux. If it ever becomes useful... I'll enable it in the
> > port.
> Sorry. I only mean that libradeon is a harmless at the moment.
Yes, the potential issue is that if it exists, the DDX driver or mesa
may detect it and have build issues.
> Could You please let us know rough roadmap for freebsd kernel drm?
GEM: WIP no ETA
Still a fair amount of work to do here figuring out how to allocate
and manage the objects using the FreeBSD VM system. I am still trying
to learn how to manipulate the VM system. I only know of a couple of
people that truly understand it though. I think that we can get any
needed functionality that we need added, but if it has to go into their
queue, it may take some time. I don't know that we need any more new
features to do this yet. This is primarily only used on Intel hardware,
but radeon and nouveau use a TTM backend while presenting a GEM api to
userland, so this has to be the first task in queue.
TTM: WIP no ETA (less done than GEM)
I've at least got this stubbed out, but I haven't looked at exactly
what is needed to get this going yet. Overall, TTM is a bit more
complex than GEM since it manages pools of memory of various types from
both the system and the GPU. In the end, this may be more suited to our
VM than GEM, but I'm only speculating at this point. This will be used
by radeon, nouveau and possibly via at some point.
KMS: glimmer in my eye...
Overall, this may be easier to port, however it relies on GEM/TTM
to handle all of the buffer management. I'll need to coordinate with
Ed@ when we get ready to do this to integrate it with our console
support.
I mentioned via... I finally have hardware of the appropriate vintage to
finish porting the via drm driver, thanks to Bruno Schwander. This is
jumbled up with working on the above, but I have most of the code
ported. I still have one file to go through and fix up, though it is
the most complex bit of functionality. Once I received the board, I had
to fix via agp, which I committed a couple of nights ago. I'm not sure
how it has existed and been broken for as long as it had. This driver
will support Unichrome chips using the openchrome DDX driver. There is
an alternate via driver which uses TTM, but it doesn't ship in linux
either.
I had previously been sent a via chrome9 part (VX800) which
unfortunately uses a different driver. I had this mostly completed,
though not actually working. The primary problem here is that there is
no shipping DDX driver that uses it and no open source 3d for it either.
The *HUGE* issue is that I am one person... Trying to keep up with 20 or
30 developers on linux, many of whom are paid full time to work on
graphics if not drm directly. Probably more, when you consider that I
have to try and keep mesa and Xorg going as well. I have upstream
commit rights for all of the above, so I try to make sure that when
folks break things on FreeBSD that fixes get committed upstream.
robert.
>
> > > "Merge branch 'glsl-pp-rework-2'" (e195eab9093d2a6cf55a42b2e7789c9a381b778)
> > > but this is separate matter.
> > > So may be enabling libdrm_radeon is not such a bad idea.
>
>
> --
> Adios
--
Robert Noland <rnoland@FreeBSD.org>
FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1261583216.2304.68.camel>