From owner-freebsd-x11@freebsd.org Mon Apr 13 21:40:39 2020 Return-Path: Delivered-To: freebsd-x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 766C82A9F05 for ; Mon, 13 Apr 2020 21:40:39 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 491MVb1Yqbz4FZp for ; Mon, 13 Apr 2020 21:40:39 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: by mailman.nyi.freebsd.org (Postfix) id 339E12A9F04; Mon, 13 Apr 2020 21:40:39 +0000 (UTC) Delivered-To: x11@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 336432A9F03 for ; Mon, 13 Apr 2020 21:40:39 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 491MVY3wX5z4FZj; Mon, 13 Apr 2020 21:40:37 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.206] (cpe-23-243-162-239.socal.res.rr.com [23.243.162.239]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id fdc7a666 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 13 Apr 2020 21:40:36 +0000 (UTC) Subject: Re: Ars Technica article To: bsd-lists@BSDforge.com, Niclas Zeising Cc: FreeBSD X11 References: From: Pete Wright Message-ID: <9fb362dd-0b3b-2c09-8ae9-26167f9d42ff@nomadlogic.org> Date: Mon, 13 Apr 2020 14:40:35 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 491MVY3wX5z4FZj X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 174.136.98.114 as permitted sender) smtp.mailfrom=pete@nomadlogic.org X-Spamd-Result: default: False [-5.07 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[239.162.243.23.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.10]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-2.77)[ip: (-9.26), ipnet: 174.136.96.0/20(-4.14), asn: 25795(-0.42), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 21:40:39 -0000  What direction change are you talking about? > As alluded to earlier; the importation of so much Linux code. On one > hand; yes it shortens the time-to-implementation. But in the broader > scope; it's more work (and time) in the long term for it's removal, > and replacement -- assuming that day ever arrives. this misses the key point that there is literally *zero* people being paid full-time to implement graphics drivers for FreeBSD, whereas at both Intel and AMD developers are being paid to develop drivers for the linux kernel.  They are also getting access to documentation and other resources on how these chips are implemented which I am not certain we have access to either. as such it seems like a good opportunity for us to leverage this work that is being done for the linux kernel (warts and all) to get better coverage to modern GPU's on FreeBSD. > The Kpi is also a kludge, and with it comes a performance hit. How is it a kludge, and what is the performance hit in real numbers?  Regarding perf numbers there is no data to back this up because there has not been enough work to get the testing & benchmarking suites working in a reliable state on FreeBSD. As a counterpoint, I periodically run OpenBSD which as gone in a different direction of implementing their own drivers for i915.  I would say subjectively the performance with their implementation is several orders of magnitude less performant than FreeBSD's - but you know what, that is OK!  They have different objectives and approaches which is totally healthy IMHO. We just need to be honest that their are trade offs that will be taken with either approach - and perf is one of the most obvious and noisy areas. > > Is there really that little interest in the Graphics area/dept. that > what we've currently been using couldn't be sustained/improved? > I would say yes! Until this work began we had support for older i915 graphics but that development had stalled while hardware most definitely had *not* stalled.  The situation that we are at now is a direct result of this - someone stood up and got things working, entropy took over and support was added and improved. There is nothing preventing others from standing up and implementing non-linux derived graphics drivers though!  I would just suggest taking a moment to understand how much of a lift this work is from a dev perspective, let alone support after bits land.  At the end of the day most people just assume graphics to work so they can get on with their real work they need to accomplish. Not trying to start a flame, just offering perspective from things i've observed through this process... -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA