Date: Tue, 21 Jul 2020 07:49:19 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 247441] graphics/gpu-firmware-kmod and or graphics/drm-fbsd11.2-kmod crashing 11.2 to 11.4 with a Radeon HD 5770 card Message-ID: <bug-247441-7141-vgwZo5HLdK@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-247441-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-247441-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247441 --- Comment #17 from Niclas Zeising <zeising@FreeBSD.org> --- (In reply to Alexey Dokuchaev from comment #15) (In reply to Warner Losh from comment #13) >> The graphics drivers are highly sensitive to many things most other driv= ers >> are not. > Could you elaborate a bit more on this? When DRM bits were in the base, > FreeBSDhad offered awesome graphics experience, despite that it was claim= ed > those bits were actually not maintained very well. That was just 2-3 yea= rs ago, > then we started to deteriorate rapidly. What had changed? Why did we al= low it? > Why no one waived the red flag? FreeBSD did not have a great graphics experience 2-3 years ago, not with the code in base at least. The code in base (now called drm-legacy or legacy d= rm or drm2) was never well supported by the project after being imported. This showed in lack of updates, and generally bad support for modern hardware. The source was ported and imported around 2012, and then updated to eventua= lly mostly match what was in Linux 3.8, several years later. This meant that hardware support ended with Haswell, a CPU from 2013. On the AMD side, I am not exactly sure where support ends, but amdgpu.ko does not exist in drm-legacy, which is needed to support things more recent than around HD7700-series, released in 2012 (according to Wikipedia). In the meantime, things moved on, both in the userland parts of the graphics stack, as well as the kernel drivers (drm-legacy doesn't support dri3, as an example), and FreeBSD lagged further and further behind. It was not possib= le to buy reasonably new hardware hand have it work as a desktop, for instance. drm-legacy had been a full port of the graphics drivers in Linux, meaning t= hat all kernel interfaces (mostly VM stuff) had to be rewritten. This made por= ting new versions of the driver quite hard, from my understanding, and also made maintenance hard (apart from keeping the driver compiling, maybe). To remedy this, and to ease with further porting and updating, the new vers= ion of the driver was made to use the linux kpi interface in FreeBSD (this alre= ady existed, but was extended). This made it easier to update the driver, as a= ll shims needed lived in one place, and could be reused, making the diff of the driver against the Linux upstream much smaller and more manageable. At the same time, to ease development effort, and because of licensing issues, the driver was moved outside the FreeBSD source tree. This meant we could deli= ver updates and bug fixes much faster to users, no need to wait for releases or erratas, for instance. It also made it easier for developers not being Fre= eBSD committers to contribute. Without these efforts, support for graphics on FreeBSD would most likely had ended with Haswell, and radeonkms.ko, and the FreeBSD project would be even less relevant in the desktop segment. As for deteriorating, I do not at all agree. On the AMD side, things are a little less stable, and certain GPUs are having some issues, especially old= er GPUs, from the bug reports we get. However, I'm running FreeBSD as a deskt= op across two different laptop models, as well as a desktop, and I know several other laptop models that work without issues. With CURRENT and drm-devel-k= mod we even support the very latest gen10 Intel CPUs, as well as recent AMD GPU offerings, something that was simply not possible with drm-legacy. The support matrix for graphics hardware is enormous. We can not test on e= very single GPU out there, that is simply not feasible. We in the Graphics Team= try our best to test on a variety of hardware, but sometimes, there will be regressions. At some point we also need to move forward, to keep up with upstream, both on the userland and kernel side. >> There's enough churn, even in stable, in the parts of the kernel that ma= tter >> the graphics team is unable to provide much, if any, support for non-rel= eased >> versions of FreeBSD (plus very recent current and stable branches). > This just means that there's bad communication and coordination of develo= pment > efforts between the graphics team and src team. In other words, our proc= ess > sucks (that's how our users see it). No, this means that this is extremely complex. Support for old STABLE (and CURRENT) revisions have always been best-effort. If you are tracking the development branches, you have to keep up. While there are no fixed lines,= for graphics we try to keep the support window a couple of months, but that's n= ot always possible. --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-247441-7141-vgwZo5HLdK>