Please enable gallium i915(which previously named i915g): https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/meson_options.txt#L77 Migration required (for all i915 user) from old non-gallium version of i915 to new gallium version i915(i915g) which is clearly stated in amber branch: "Similarly, users of i915 should migrate to i915g (the Gallium driver for the same hardware), as it’s still being maintained." https://docs.mesa3d.org/amber.html Just in new branch due to removal of of i915(gallium version), i915g renamed to simply i915. Some upstream patches may be required.
Created attachment 240028 [details] Mesa update patch require build of never xorg(xorg-server) and intel(xf86-video-intel) driver with it
Related user reports: https://forums.freebsd.org/threads/mesa-missing-i915-driver.88338/ https://twitter.com/sahajsarup/status/1639571133744963588
This explains the 3-D performance of my Alder Lake graphics being significantly slower than it was on my ancient Ivy Lake system of over a decade ago! I have to ask, though, the prospect of ever getting a newer xorg-server as it's been stuck at 21.1.4 for a VERY long time for reasons I have yet to see explained. Also, is the old xf86-intel-driver required? I've been running the mode setting driver with libva-intel-hybrid-driverfor years with better results than I got with the intel-driver, though I have not tried it on the Alder Lake Iris Xe unit and am not too sure what should work best on it.
(In reply to rkoberman from comment #3) > … a newer xorg-server as it's been stuck at 21.1.4 … Bug 268963.
(In reply to rkoberman from comment #3) Your issue more likely due to UXA been used by default: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259791 And if you using Xorg, you'll need add: Option "DRI" "iris" This driver mostly for pre-gen4.
Created attachment 242518 [details] Mesa with enabled i915g + version bump
(In reply to sasamotikomi from comment #6) I managed to get GMA3150 to work, but if you enable OpenGL 2.1 via .drirc disable it first or add program which can't use it to exception like in example: <driconf> <device screen="0" driver="i915"> <application name="Default"> <option name="stub_occlusion_query" value="true" /> <option name="fragment_shader" value="true" /> </application> <application name="firefox" executable="firefox"> <option name="stub_occlusion_query" value="true" /> <option name="stub_occlusion_query" value="false" /> <option name="fragment_shader" value="false" /> </application> </device> </driconf> Otherwise it may crash and fallback to llmvpipe, at least with Firefox, possible with Chrome as well. You need restart xorg-server if you crash DRI. OpenGL 2.1 work without it so you probably can just disable it. I can't get it to work with GMA 950, it's most likely due to my mistake, I build it with CPUTYPE=atom, so may not work on my Celeron 430 machine. So it crash: [ 2878.185] (EE) Illegal instruction at address 0x83bd45369 [ 2878.185] (EE) Fatal server error: [ 2878.185] (EE) Caught signal 4 (Illegal instruction). Server aborting Please test it yourself if you can.
*** Bug 271930 has been marked as a duplicate of this bug. ***
(In reply to sasamotikomi from comment #7) Seem like it's indeed couple of incorrect options in make.conf on my side. Currently i945g work fine with GMA950(and GMA3150 of course): % glxinfo | grep render direct rendering: Yes GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, Extended renderer info (GLX_MESA_query_renderer): OpenGL renderer string: i915 (chipset: 945G) GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer Issue I encounter actually is VT<->X11 switch disable GPU acceleration (aka llvmpipe fallback): https://github.com/freebsd/drm-kmod/issues/175g So only real issue I'm encounter is WebGL1 broken in browsers Librewolf and Firefox, and Firefox specifically do not display anything in about:support, however es2gears_x11 work on both iGPU and glxinfo show OpenGL ES 2.0 support. Second is Libva don't just give you unsupported status: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272109 There's no serious issues with i915g outside of lack of some feature (like WebGL1). So it's ready for commit.
Since PR get ignored by "maintainer" for more than two weeks, patches can be committed by maintainer timeout. If there's no complain of course.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=6fef4101daa2041a1dffdcde860a8b386d7a5f5f commit 6fef4101daa2041a1dffdcde860a8b386d7a5f5f Author: sasamotikomi <sasamotikomi@gmail.com> AuthorDate: 2023-08-12 20:45:57 +0000 Commit: Kevin Bowling <kbowling@FreeBSD.org> CommitDate: 2023-08-12 20:56:50 +0000 graphics/mesa-dri: enable i915g This is still supported by Mesa for gen2/3 hw not covered by crocus. PR: 269006 graphics/mesa-dri/Makefile | 7 ++++--- graphics/mesa-dri/pkg-plist | 1 + graphics/mesa-libs/Makefile | 2 +- 3 files changed, 6 insertions(+), 4 deletions(-)
(In reply to commit-hook from comment #11) > This is still supported by Mesa for gen2/3 hw not covered by crocus. According to https://gitlab.freedesktop.org/mesa/mesa/-/commit/ceba7f695271 i915g (unlike i915c) only covers Intel Gen3. https://gitlab.freedesktop.org/mesa/mesa/-/blob/mesa-22.3.7/include/pci_ids/i915_pci_ids.h https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Third_generation
I have just updated my ports tree with "portsnap fetch update", but when changing into the graphics/mesa-dri directory and typing "make config", I don't see an option "enable i915g" as suggested in comment 11. All I see are options - Enable support for the Wayland... - Use ZSTD for shader cache - Enable X11 support for GBM/EGL - Enable Wayland support for GBM/EGL So why does it say here "status closed" and "resolution fixed"? Am I missing something here? Thanks.