Date: Wed, 30 Nov 2011 19:33:46 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Adam K Kirchhoff <akirchhoff135014@comcast.net> Cc: freebsd-x11@freebsd.org Subject: Re: suggested xorg-compatible video HW for FreeBSD/amd64 ? Message-ID: <20111130173346.GC50300@deviant.kiev.zoral.com.ua> In-Reply-To: <4ED564B4.1080001@comcast.net> References: <20111128092008.GA58668@onelab2.iet.unipi.it> <201111291412.28576.jkim@FreeBSD.org> <4ED52FF6.9070104@comcast.net> <201111291518.04364.jkim@FreeBSD.org> <4ED564B4.1080001@comcast.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Tue, Nov 29, 2011 at 06:03:16PM -0500, Adam K Kirchhoff wrote: > On 11/29/11 15:17, Jung-uk Kim wrote: > >On Tuesday 29 November 2011 02:18 pm, Adam K Kirchhoff wrote: > >> > >>It is my understanding that to simplify have one unified API for > >>interacting with the DRM code, the radeon developers (and others) > >>agreed/decided to use the GEM userspace API, even though the > >>internals (for radeon DRM) require functionality provided by TTM. > >Understood. > > > >>For what it's worth, the radeon developer I just spoke to even said > >>in order to remove TTM from the equation, "something" would have to > >>be recoded to do "partly what ttm does". > >Yes, *partly*. That's exactly what I was talking about. If porting > >entire TTM layer is harder than recoding to do "partly what TTM > >does", then it is worth considering, IMHO. > > > >Jung-uk Kim > > So we end up with more questions than answers :-) > > Of course, everything would also likely depend on the exact goals of > this completely hypothetical Radeon DRM project. > > How much of TTM would need to be re-implemented/ported to simply support > 2D acceleration on newer radeon hardware (HD5xxx and higher, and the new > APUs)? How much would be required to support DRI2 and gallium3D? How > much for a full port of KMS? We can only speculate on what the FreeBSD > Foundation would be interested in sponsoring, or what would interest the > developer doing the work. Use of the abbreviations goes in the strange and unexplainable ways. Would it be easier if I say that whole TTM, execution and KMS bits needs to be ported ? There are two big DRM infrastructure bits that are missing right now: TTM and multi-master support. TTM is absolutely critical for anything non-Intel. Multi-master can be lived without. TTM as such has no GPU-specific bits, there is a large piece of code that manages execution for the GPU families. > > Out of curiosity: Can anyone tell me if DRI2 is currently supported on > the intel GPUs with Kostik's patches? Has anyone tried the i915g > gallium driver? It's unofficial, unsupported by Intel, but still has > development going on (as compared to i965g, which was dropped from Mesa > today). Do you mean DRI2 protocol ? Yes, it is supported and works, in particular, vblanks work. i915g could work, but Gen3 and earlier hardware is supported by my patchset on the best effort basis - I have no access to such old machines, and most testers do not either. I had one report of successful use, see AGP_Testing wiki page. I expect that gallium driver would work, but I might have to fix a bug or two. Note that it seems that gallium driver for Gen4 and newer chips was removed several hours ago. > > As a side-note, but still relevant to the discussion: the r300 and r600 > classic mesa drivers were dropped from Mesa a few weeks ago. They > are/were the only functioning 3D drivers on FreeBSD for everything from > the Radeon 9500 to the HD4950. > > Adam > > > > _______________________________________________ > 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" [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7WaPoACgkQC3+MBN1Mb4gXpQCg0YAfqxt0S0KZVCPHpv9dBPVX to0An2uIOeP74s0f1qVaJMw6ceuLKiin =W1jI -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111130173346.GC50300>