Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
USE=d3d9 for i965 (Q45) no longer valid for dev-libs/mesa ?
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 9645
Location: almost Mile High in the USA

PostPosted: Mon Nov 19, 2018 4:45 am    Post subject: USE=d3d9 for i965 (Q45) no longer valid for dev-libs/mesa ? Reply with quote

Maybe I didn't quite understand what was going on.

For the longest time I had USE=d3d9 for my Q45 chipset board, which should be a i965 derivative. dev-libs/mesa compiled just fine.

However with the 18.2 update it refuses to build. I had to disable USE=d3d9 ... Yes it's an aging graphics chipset, but I wonder, did d3d9 ever work before and why can't I build it now?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
ali3nx
l33t
l33t


Joined: 21 Sep 2003
Posts: 722
Location: Winnipeg, Canada

PostPosted: Mon Nov 19, 2018 1:17 pm    Post subject: Reply with quote

The same build warning is also presented for vdpau and vaapi.

I too am curious what changed since both wine-staging and mesa would build with all of those use flags including building wine-staging against osmesa

Code:
# wine

app-emulation/wine-staging X alsa cups fontconfig gecko jpeg lcms mono mp3 ncurses nls opengl perl png realtime run-exes samba sdl ssl threads truetype udev udisks v4l vaapi vkd3d vulkan xcomposite xinerama xml -capi custom-cflags -dos gphoto2 -gsm -gssapi -gstreamer -kerberos -ldap netapi -odbc openal opencl osmesa -oss pcap -pipelight -prelink -pulseaudio -s3tc -scanner


This wine build worked great linked to userland mesa with nvidia-drivers, a 1060 gtx and played eve online in DX11 mode however the config is now invalid?
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper!
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Mon Nov 19, 2018 2:44 pm    Post subject: Reply with quote

I think there chooser is wrong, I have intel (on my laptop) and it removed the vaapi flag from mesa, which is odd because intel is the one that did all the work on vaapi and it works well on their chips. Looks like I'll have to modify the ebuild.

Quote:
On Linux/X11, there are two competing interfaces for hardware video decoding, VA-API from Intel, and VDPAU from NVIDIA. Generally, VAAPI is used for Intel and Broadcom graphic cards, while VDPAU is used for AMD/ATI and NVIDIA cards.


ETA: looking at the ebuild it looks like he C&P'd without using his brain.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
ali3nx
l33t
l33t


Joined: 21 Sep 2003
Posts: 722
Location: Winnipeg, Canada

PostPosted: Mon Nov 19, 2018 3:20 pm    Post subject: Reply with quote

Anon-E-moose wrote:
I think there chooser is wrong, I have intel (on my laptop) and it removed the vaapi flag from mesa, which is odd because intel is the one that did all the work on vaapi and it works well on their chips. Looks like I'll have to modify the ebuild.

Quote:
On Linux/X11, there are two competing interfaces for hardware video decoding, VA-API from Intel, and VDPAU from NVIDIA. Generally, VAAPI is used for Intel and Broadcom graphic cards, while VDPAU is used for AMD/ATI and NVIDIA cards.


ETA: looking at the ebuild it looks like he C&P'd without using his brain.


PC Builds do exist that use both discrete gpu's and igpu graphics chipsets. Perhaps the dev responsible had not considered the purpose of gpu multi mode :)

somewhat off topic... I haven't checked commit logs for mesa but i find myself curious if the same dev that maintains mesa also maintains xorg-server and may be responsible for the xorg-server suid useflag permissions issues. I want to believe that if this dev is responsible for both packages has been doing adequate research and has enough aid or forethought to seek advice from peers for the purpose of possessing necessary perspective to commit safe, secure and functional code to the portage tree instead of committing code changes based on anecdotal evidence.
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper!
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 9645
Location: almost Mile High in the USA

PostPosted: Tue Nov 20, 2018 7:10 am    Post subject: Reply with quote

So I suspect a new mesa-18.2.5-r1 will be out or something rather?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Tue Nov 20, 2018 12:04 pm    Post subject: Reply with quote

ali3nx wrote:
somewhat off topic... I haven't checked commit logs for mesa but i find myself curious if the same dev that maintains mesa also maintains xorg-server and may be responsible for the xorg-server suid useflag permissions issues


It's the same group (according to metadata.xml) for both, but don't know if it's the same dev.
But judging by the cluster-fsck on both, it's highly probably

eccerr0r wrote:
So I suspect a new mesa-18.2.5-r1 will be out or something rather?


I'm not so sure, no bug reports complaining about it, so probably no changes.

Note: all the logic for the stupidity is in pkg_pretend() area of ebuild.
To make it like it used to be either remove "pkg_pretend() { lots of stupid logic }" completely or set it to "pkg_pretend() {}"

The "logic" seems to still be there for 18.3.0_rc* ebuilds.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2551
Location: Here and Away Again

PostPosted: Tue Nov 20, 2018 1:10 pm    Post subject: ><)))°€ Reply with quote

I saw a bug related to Mesa and Wine, and this is what it lead to: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4d352ccb

After only a quick peek, I'm not entirely sure that it is the commit that introduced the change in behaviour you're seeing.
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3264
Location: Canada

PostPosted: Tue Nov 20, 2018 1:31 pm    Post subject: Reply with quote

Anon-E-moose wrote:
I think there chooser is wrong, I have intel (on my laptop) and it removed the vaapi flag from mesa, which is odd because intel is the one that did all the work on vaapi and it works well on their chips. Looks like I'll have to modify the ebuild.

Quote:
On Linux/X11, there are two competing interfaces for hardware video decoding, VA-API from Intel, and VDPAU from NVIDIA. Generally, VAAPI is used for Intel and Broadcom graphic cards, while VDPAU is used for AMD/ATI and NVIDIA cards.


ETA: looking at the ebuild it looks like he C&P'd without using his brain.



How does it all interplay with classic/gallium architecture ? modesetting i965 requires classic (what is happening on this intel choice when both are enabled, as is the default ?), while all vaapi and vdpau options seems to refer to gallium interface
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Tue Nov 20, 2018 2:45 pm    Post subject: Reply with quote

dmpogo wrote:
Anon-E-moose wrote:
I think there chooser is wrong, I have intel (on my laptop) and it removed the vaapi flag from mesa, which is odd because intel is the one that did all the work on vaapi and it works well on their chips. Looks like I'll have to modify the ebuild.

Quote:
On Linux/X11, there are two competing interfaces for hardware video decoding, VA-API from Intel, and VDPAU from NVIDIA. Generally, VAAPI is used for Intel and Broadcom graphic cards, while VDPAU is used for AMD/ATI and NVIDIA cards.


ETA: looking at the ebuild it looks like he C&P'd without using his brain.



How does it all interplay with classic/gallium architecture ? modesetting i965 requires classic (what is happening on this intel choice when both are enabled, as is the default ?), while all vaapi and vdpau options seems to refer to gallium interface


In answer to your first question, I really don't know.
I do know that intel was working on adding iris specific stuff to gallium, but that was as of the middle of the year, and I haven't heard anything different since.

AFAIK, if you enable stuff that it can't use, it won't use it. Which to me means it shouldn't be a problem with stuff compiled. But that's just a guess.

And unfortunately, if you google enough about it you get seemingly conflicting info, which leaves you scratching your head.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3264
Location: Canada

PostPosted: Tue Nov 20, 2018 3:30 pm    Post subject: Reply with quote

Anon-E-moose wrote:
dmpogo wrote:
Anon-E-moose wrote:
I think there chooser is wrong, I have intel (on my laptop) and it removed the vaapi flag from mesa, which is odd because intel is the one that did all the work on vaapi and it works well on their chips. Looks like I'll have to modify the ebuild.

Quote:
On Linux/X11, there are two competing interfaces for hardware video decoding, VA-API from Intel, and VDPAU from NVIDIA. Generally, VAAPI is used for Intel and Broadcom graphic cards, while VDPAU is used for AMD/ATI and NVIDIA cards.


ETA: looking at the ebuild it looks like he C&P'd without using his brain.


How does it all interplay with classic/gallium architecture ? modesetting i965 requires classic (what is happening on this intel choice when both are enabled, as is the default ?), while all vaapi and vdpau options seems to refer to gallium interface


In answer to your first question, I really don't know.
I do know that intel was working on adding iris specific stuff to gallium, but that was as of the middle of the year, and I haven't heard anything different since.

AFAIK, if you enable stuff that it can't use, it won't use it. Which to me means it shouldn't be a problem with stuff compiled. But that's just a guess.

And unfortunately, if you google enough about it you get seemingly conflicting info, which leaves you scratching your head.





Indeed, I am scratching the head :( I am not even sure that Mesa uses 'i915' 'i965' and 'intel' VIDEO_CARDS in the same sense that they are used for the xorg-drivers. There
'intel' means installing xf86-video-intel with its on 2D acceleration (?), while i965 uses kernel modesetting and glamor 2D acceleration from xorg-server. If both are set, i965 overwrites intel.

Now, on my machine I have VIDEO_CARDS='i965', amd mesa is compiled with +classic +gallium
if now I enable vaapi by hand, I get
Code:

USE='vaapi' emerge -pv mesa
......
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] x11-libs/libdrm-2.4.96::gentoo  USE="-libkms -valgrind" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="intel* -amdgpu (-exynos) (-freedreno) -nouveau (-omap) -radeon (-tegra) (-vc4) (-vivante) -vmware" 0 KiB
[ebuild  N     ] x11-libs/libva-1.7.3::gentoo  USE="X drm opengl -egl -vdpau -wayland" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="i965 -dummy -intel -nouveau -nvidia" 806 KiB
[ebuild  N     ] x11-libs/libva-intel-driver-1.7.3::gentoo  USE="X drm -wayland" ABI_X86="(64) -32 (-x32)" 1,611 KiB
[ebuild   R    ] media-libs/mesa-18.2.5::gentoo  USE="classic dri3 egl gallium gbm llvm lm_sensors vaapi* wayland -d3d9 -debug -gles1 -gles2 -opencl -osmesa -pax_kernel -pic (-selinux) -test -unwind -valgrind -vdpau -vulkan -xa -xvmc" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="i965 (-freedreno) -i915 (-imx) -intel -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) -virgl (-vivante) -vmware" 0 KiB

Total: 4 packages (2 new, 2 reinstalls), Size of downloads: 2,416 KiB

The following USE changes are necessary to proceed:
 (see "package.use" in the portage(5) man page for more details)
# required by x11-libs/libva-intel-driver-1.7.3::gentoo
# required by x11-libs/libva-1.7.3::gentoo[-video_cards_intel,video_cards_i965]
# required by media-libs/mesa-18.2.5::gentoo[vaapi,gallium]
# required by @selected
# required by @world (argument)
>=x11-libs/libdrm-2.4.96 video_cards_intel


so it tries to install libva which then pulls in standalone vaapi implementation in libva-intel-driver, but it requires recompilation of libdrm with VIDEO_CARDS='intel' choice.
(surprisingly, it is not required that from libva itself, it is happy with +i965 -intel combination)

Ah, looks bloody messy
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21489

PostPosted: Wed Nov 21, 2018 2:37 am    Post subject: Reply with quote

Regarding all the negative comments about the Gentoo maintainer who caused the problems with xorg-server, I would suggest that readers first read the comments in x11-base/xorg-server: add USE=suid so that /usr/bin/Xorg setuid can be disabled. In particular, these remarks from Matt:
In comment #10, Matt Turner wrote:
The story is that we had a IUSE=suid flag and no one knew why. Gentoo has a long history of adding knobs where they're not needed and since I'm maintaining x11@ packages by myself I've tried to reduce the surface area of such configuration options.
...
I want this to be configurable but not in a way that I'm going to constantly have to explain to people.
I interpret that and some of his other remarks to mean that he's doing the best he can with the limited time and information he has available. He's not deliberately trying to break anyone's systems or coerce people to a particular way of using X.
Back to top
View user's profile Send private message
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Wed Nov 21, 2018 10:40 am    Post subject: Reply with quote

Speaking just for me. :D
I never thought the dev was doing it out of maliciousness. I had read the comments and knew it was from ignorance (lack of knowledge) about the package.

But the whole remove suid, put it in, take it out, do the hokey-pokey and suid-wrapper stuff under systemd flag, etc, was just nonsense.

And quite frankly, if I were a dev and didn't have a lot of knowledge about what I was doing, I might float the idea of what I wanted to do, on a thread someplace like this where it would get some attention from normal folks before I put it in action. But that's just me.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
josephg
l33t
l33t


Joined: 10 Jan 2016
Posts: 783
Location: usually offline

PostPosted: Wed Nov 21, 2018 11:10 am    Post subject: Reply with quote

Anon-E-moose wrote:
And quite frankly, if I were a dev and didn't have a lot of knowledge about what I was doing

I might wonder if I should handover to someone more capable..
_________________
"Growth for the sake of growth is the ideology of the cancer cell." Edward Abbey
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1791

PostPosted: Wed Nov 21, 2018 5:03 pm    Post subject: Reply with quote

Quote:
I might wonder if I should handover to someone more capable..


I don't necessarily think the dev isn't capable on maintaining the package, as it isn't always a easy job to do; especially with such a large and complex package like xorg that affects most users. I can see some parts of where he is trying to simplify the package on all of it's use flags and possibly some of it's conditional dependencies. It is never easy when you don't always know what happens to all the use cases. This is specially evident with the suid fiasco, as I wouldn't be surprised the devs was primarily hearing from the people of wanting to get rid of suid. This is even though those people keep saying it's more safer, but if you don't do it their way, you are in the stone ages.

I agree with anon, as I'd like to see the devs more active in the forums, beyond the few that do pop up. Even if the devs use a second account to be anonymous, it would help them see what people are having troubles with besides what is said in the bug reports.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21489

PostPosted: Thu Nov 22, 2018 1:30 am    Post subject: Reply with quote

In my opinion, the whole mess is further complicated by the presence of documentation that asserts that non-root Xorg is easy to make work, but which does not adequately enumerate the places where that is still not true (certain video drivers, direct-start from accounts that are not granted various powerful group memberships, etc.).
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 9645
Location: almost Mile High in the USA

PostPosted: Sat Nov 24, 2018 12:14 am    Post subject: Reply with quote

So I take it that DX9 never worked with i965 anyway so I won't miss anything?

I always thought DX9 was just stripping out a translation layer, but I suspect there are underlying features that need to be there to fully implement it. Then there's always emulating or ignoring the features that don't exist...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum