01:42 Justice: How is the mesa_glthread whitelist application work? seems that the whitelist is per application is there any plans to make it default and use blacklist instead?
02:11 dcbaker: Justice: we're unlikely to move to an allow list. Gl thread helps some apps a lot, and hurts a lot of apps.
02:26 alyssa:is curious why it hurts
02:42 dcbaker: I seem to remember one case is apps that already do threaded gl stuff, but I don't remember all the details
02:46 imirkin: mesa_glthread is a way of deferring all GL work onto a separate work thread
02:46 imirkin: this deferral isn't completely free
02:50 alyssa: ah
03:55 Justice: damn just started black mesa on amdgpu the flashlight does not work ;( well thats kinda gamebraking..
04:03 imirkin: i guess that's why it's called *black* mesa...
04:04 Justice: **badum...ts*
04:04 imirkin: iirc that game was fairly non-conformant and you needed a whole bunch of overrides to make it work
04:04 Justice: is there any documentation? for it seems though that its amdgpu specific since it worked perfectly fine on nvidia
04:05 imirkin: another way to look at it
04:05 Justice: well mesa specific atleast*
04:05 imirkin: is that the game is only tested to run on nvidia
04:05 imirkin: which doesn't have all the proper spec-mandated checks
04:05 imirkin: so trips over itself when run on a proper impl
04:05 Justice: but isnt the core still source?
04:05 Justice: "source engine"
04:06 imirkin: not sure that's the case, of course, but "works on nvidia, therefore other thing must be broken" is fairly annoying to hear
04:06 Justice: yeah I understand that
04:07 imirkin: random google search result: https://www.reddit.com/r/HalfLife/comments/fox9hp/black_mesa_flashlight_issue_linux/
04:07 Justice: yeah tried that sadly did not work will try the -force_vendor_id 0x10DE -force_device_id 0x1180 -dxlevel 95 to see if that works found somewere on steam discussions
04:08 imirkin: the name of the game is very unfortunate
04:08 Justice: how so?
04:09 imirkin: well ... "black mesa"
04:09 imirkin: so searching for that in combination with mesa
04:09 imirkin: is ... not straightforward
04:09 alyssa: that was a joke. ha-ha. fat chance.
04:10 imirkin: Justice: that force vendor stuff is to make it think it's running on an nvidia gpu
04:10 Justice: hm i think i found the issue
04:11 imirkin: often software has workarounds for specific drivers. it's a huge mess.
04:11 imirkin: (which again negates the "but it runs on nvidia!" argument)
04:11 imirkin: (0x10de = nvidia pci vendor id)
04:14 Justice: damn it it worked thought it was threaded issue since it magically worked when i turned it off but no...
04:14 imirkin: so i guess you were right... it *does* work on nvidia ;)
04:14 imirkin: at least when it thinks it's running on nvidia
04:15 alyssa: anyway this cake is great
04:15 Justice: not tested the vendor thing _yet_
04:15 imirkin: oh
04:15 Justice: the game is buggy as hell, setting something in options and load game suddenly video options are different
04:16 Justice: i think it could be something it sets after options are saved
04:16 Justice: that breaks it for "non nvidia"
04:21 Justice: well thats annoying. Validate files => 1 file has issues launch game flashlight == OK
04:23 Justice: yup, change video settings restart game and flashlight broken
04:26 Justice: hm feels like the devs added a random hardcore mode to this game o.O
04:29 Justice: funny thing they had the same issue on windows it seems
04:31 imirkin: Justice: there's some comment about removing the dxlevel thing after initial run
04:31 imirkin: seems like a quality piece of software
04:31 Justice: https://www.youtube.com/watch?v=ptLKlRtkaJs this one is quality :P
04:32 Justice: guessing its windows will try if it works the same way here
04:45 Justice: yup its working fine with threaded after verifying the files so something is getting corrupt when saving the options menu, will see if the devs are even somewhat active on steam forums
04:46 shoober420: anyone here got axiom verge on steam?
04:46 shoober420: it doesnt launch for me, as well as some other games
04:47 shoober420: im using mesa master and sway
04:50 shoober420: the strangest thing is forsaken remastered, which uses the kex engine, doesnt launch
04:50 shoober420: but turok launches, which uses the same kex engine
04:51 shoober420: forasken remastered says it "Couldnt find matching GLX visual)
04:52 shoober420: other games launch ok though, like ion fury, timespinner, serious sam fusion, amnesia
04:52 Justice: shoober420: does it just crash or ? check dmesg, jorunal, steamlogs
04:55 shoober420: it will just say "Running" for a second then close
04:55 shoober420: i can wgetpaste the forsaken remastered logs
04:56 shoober420: i rolled back to stable mesa because i thought it was a git bug
04:56 Justice: i am not a developer at any point but see if you find anything out of the ordinary in the logs really. If its proton game see github if there is anything on it.
04:57 shoober420: this is a native game
04:57 imirkin: shoober420: some games in steam end up with library conflicts, and it helps to use the "native" libs vs the "steam" ones
04:57 shoober420: im running without the steam runtime, using all native libs
04:58 Justice: is the issue there with their runtime?
04:58 shoober420: i was thinking of trying with the runtime, but if it works then i still dont have a good lead
04:58 Justice: well if it works with the runtime then its compatibility issues =)
04:58 Justice: atleast then its "something"
04:59 shoober420: timespinner has a wacky fix
04:59 shoober420: you have to put TERM="" in the launch options
04:59 Justice: o.O
04:59 shoober420: some games require LD_PRELOAD=libcurl.so.3 and other wacky stuff
04:59 shoober420: some games require openssl 1.0, and dont work with openssl 1.1
04:59 Justice: thats why you want runtime really
05:00 Justice: since they ship the libs the game needs
05:00 shoober420: i have them though
05:00 Justice: now with steam containers they will ship libs for each game I think
05:00 shoober420: arch has a package that installs all the old poopy libs
05:00 shoober420: they were working for me in the past
05:00 Justice: you mean the steam-native ?
05:00 shoober420: yes
05:01 Justice: yeah i have it too but stopped using native steam for some time now.
05:01 shoober420: why
05:01 Justice: didnt really see why, also that VR requires runtime for my Alyx gameplay
05:01 shoober420: i wonder what libs VR needs
05:01 shoober420: im going to try with the runtime
05:01 Justice: lots of steam libs probably
05:02 Justice: the VR part of steam is scarly integrated into steam client
05:03 Justice: I like Valves support with Wine and their support for open drivers etc but some of their stuff is way to hard integrated into steam
05:03 shoober420: they dont launch using the runtime either
05:03 shoober420: so thats not it
05:03 Justice: anything in logs?
05:03 shoober420: same error
05:04 Justice: that is?
05:04 shoober420: failed to create window (couldnt find matching glx visual)
05:04 shoober420: thats a kex error though
05:04 shoober420: it says SDL initialized
05:04 shoober420: let me woll back SDL and see if thats it
05:05 shoober420: roll back*
05:05 shoober420: im using sdl2 git master as well
05:05 HdkR: I ran Axiom Verge just a couple weeks ago on Linux, but with i3. Was fine
05:05 Justice: but if you have sdl-git and valve has its own sdl would it not use the valve version in steam runtime?
05:06 shoober420: it uses the native system libs
05:06 shoober420: i have the runtime disabled
05:06 shoober420: hmm
05:06 shoober420: HdkR: do you use the runtime or use steam natively?
05:06 Justice: you should have a launcher for steam runtime
05:07 HdkR: I use native steam without any random runtime changes
05:07 Justice: HdkR: so you use their own runtime
05:07 HdkR: yes
05:07 Justice: steam native is when you use system libs instead of steam provided libs
05:07 HdkR: I don't tinker with the Steam install
05:07 shoober420: i just tried using the runtime though getting the same error, so that cant be it
05:08 HdkR: ah, I was assuming not steam native was wine running
05:08 Justice: shoober420: could you check that its actually using the runtime? Goto systeminfo there you can see if its using that or not
05:12 shoober420: its for sure using the runtime
05:12 shoober420: i checked steam information
05:13 Justice: hm other than gooling for it i have no idea ;/
05:15 shoober420: i might have to launch them through proton
05:15 shoober420: thats so lame
05:25 shoober420: well, im going to get my system back to all git master packages lolol
05:25 shoober420: thanks for all the help guys
05:25 shoober420: i think they are just bad ports
05:27 HdkR: Just reran it locally
05:27 HdkR: Works fine
05:27 HdkR: blame xwayland until proven otherwise
05:44 Justice: HdkR: what game?
05:44 HdkR: Axiom Verge
05:45 HdkR: One of the games they were complaining about not working
05:53 HdkR: Forsaken Remastered also "just works"
07:35 Justice: hah dad confirms it quite good. proton ftw over black mesa native port
07:35 Justice: dat*
07:36 Justice: less graphical bugs and about 30% better performance
09:30 MrCooper: Kayden: radeon/r200 also use swtnl
09:45 tzimmermann: danvet, do you know if VM_PFNMAP is still a thing: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem_cma_helper.c#L279
09:45 tzimmermann: drm_gem_mmap() doesn't seem to set it
09:46 danvet: I do not really understand what that thing does
09:46 tzimmermann: danvet, ah ok
09:47 tzimmermann: do you know who might know more about this?
09:47 danvet: well I tried to understand it, and it's kinda lost in pre-git times
09:48 danvet: or do you just mean the comment about clearing VM_PFNMAP?
09:48 tzimmermann: i mean the the comment about clearing the flag. because drm_gem_mmap() doesn't seem to set it in the rsp branch
09:50 tzimmermann: the caller is here: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem.c#L1091
09:50 danvet: emersion, will you push mauro's doc fix?
09:50 danvet: always a bit confusing when committers ack a patch but don't say whom they expect to merge it
09:50 tzimmermann: and the flag is being set here: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem.c#L1107
09:50 danvet: yeah I have no idea why we need to clear it for dma_map_wc
09:54 tzimmermann: i'll investigate closer and maybe send a patch to remove this code
09:54 tzimmermann: thanks
09:56 danvet: tzimmermann, kerneldoc isn't explaining any of this either unfortunately
09:56 danvet: kerneldoc for the dma_mmap family of functions I mean
09:57 tzimmermann: i'm sure it makes total sense for mem devs :)
09:58 danvet: lol remap_pfn_range re-adds VM_PFNMAP again
09:58 danvet: I'm not sure there's anything else
09:59 danvet: maybe ask pinchartl why this was needed
10:00 emersion: danvet: ok, will be more explicit next time. i like to wait a little before merging anything in case others have something to say, but in this case it's trivial so might as well just merge it
10:03 tzimmermann: ah, ok
13:52 zmike: is anyone aware of a reason that might cause piglit to be seemingly random about running certain tests?
13:53 zmike: specifically it seems like from run to run a lot of the image load/store tests will randomly enable or disable themselves
13:59 jenatali: Sounds like you have uninitialized memory you're returning for a cap somehow, but that also sounds really unlikely
14:00 zmike: but it's only some of the image load/store tests that disable
14:00 zmike: the rest run
14:00 zmike: which is pretty 🤔
14:07 MrCooper: if they're sub-tests, crashes in some sub-tests might result in later sub-tests of the same test binary not running
14:07 zmike: hmm
14:12 emersion: is there a reason why dim now adds a S-o-b tag for the committer?
14:15 dolphin: emersion: always has, if you commit patch from someone else
14:15 emersion: eh
14:15 emersion: i see, haven't merged a lot of patches from others yet i guess
14:16 dolphin: it's a requirement to have S-o-b from the person who actually pushed the patch to git log
14:45 danvet: zackr, https://lore.kernel.org/dri-devel/CAKMK7uFjeJHS9siPfY4swYyHi92Ee2eEVw1syQ0h-efOHEKPig@mail.gmail.com/ can you perhaps look at this one?
14:46 danvet: I'd trade some reviews but looks like your series is all good already
15:23 dolphin: danvet, airlied: sent PR for drm-intel-gt-next, very fixes oriented. Once you have merged, j4ni and vivijim were hoping me to backmerge drm-next so we can have some common topic branches between drm-intel-gt-next and drm-intel-next
15:28 zackr: danvet: ah, sorry, reviewed now, i was off the entire december so i missed a bit of stuff. Looks great. Thanks for doing this.
15:28 danvet: zackr, thx
15:28 danvet: zackr, should I push or do you want to test it too?
15:29 danvet: or will your ci pick it up once pushed?
15:30 zackr: danvet: whatever is easier for you. starting today our CI will pick it up if you push it to drm-misc-next or -fixes
15:30 danvet: ok I'll just push then
15:31 turol: is there any documentation for VK_LAYER_MESA_device_select?
15:56 jekstrand: PSA all: The Intel Mesa team currently has several reqs open. This doesn't happen every day (hiring has been difficult the last few years), so get 'em while they're hot!
15:56 HdkR: Whoa!
15:56 jekstrand: If you're interested in joining our team, send me an e-mail or PM me.
15:57 karolherbst: jekstrand: to late for me :p
15:57 jekstrand: Shameless plug over
15:57 karolherbst: jep, very shameless
15:57 jekstrand:has no shame. :P
15:57 karolherbst: jekstrand: what a coincidence that you also got a new CEO and stuff :D but probably unrelated :p
15:58 jekstrand: karolherbst: Totally unrelated.
16:01 jekstrand: But the new CEO is a graphics guy sort-of
16:02 ccr: can't you just make clones of the existing team, I think they are great people
16:02 jekstrand: My manager has suggested that
16:03 ccr:waits for Intel to announce 1st gen human cloning technology.
16:06 bl4ckb0ne: jekstrand: is it a remote position?
16:07 jekstrand: bl4ckb0ne: It can be. Kind-of depends on how successful we think you'd be spinning up remote.
16:08 jekstrand: Preferably, Oregon, USA or Gdansk, Poland but we've got a couple which are more general USA or general EU.
16:09 bl4ckb0ne: ill dust up my resume and pm you soon, thanks
16:11 danvet: jekstrand, "bombed larrabee" kind of gpu guy even :-)
16:12 jekstrand: danvet: I said sort-of. Larabe was sort-of a graphics thing. :-)
16:30 imirkin: mareko: have there been semi-recent changes to pipe_draw_info::index_bounds_valid setting?
16:31 imirkin: for client-side non-index-buffer vbo's
16:50 mareko: imirkin: many
16:55 danvet: glisse, futex for gpu
16:56 glisse: the fence question ?
16:57 imirkin: mareko: like we no longer get bounds?
16:59 king_chad: hey fellas, I have a bit of a noob question. I'm trying to read some code that uses glDrawRangeElementsBaseVertex, but I'm confused about the indices argument. on this page(https://www.khronos.org/opengl/wiki/GLAPI/glDrawRangeElementsBaseVertex) it says that indices Specifies a byte offset into GL_ELEMENT_ARRAY_BUFFER -- However on this page(https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glDrawRangeElementsBaseV
16:59 king_chad: ertex.xhtml) it says that indices is a pointer to the location in RAM. I've seen it used both ways so i'm fairly confused. Is there a toggle for it to behave the other way?
17:00 imirkin: king_chad: depends if there's a GL_ELEMENT_ARRAY_BUFFER bound or not
17:01 imirkin: if there is, then it's an offset into that buffer
17:01 imirkin: if there isn't, then it's a client-side pointer
17:01 king_chad: oh I see, thanks
17:02 danvet: glisse, yup
17:02 danvet: at least that's what I'm understanding
17:02 zackr: jekstrand: your new ceo is our old ceo. who are you sending in return?
17:02 mareko: imirkin: bounds are always invalid for non-indexed and can be computed manually; indexed draws should check index_bounds_valid
17:03 imirkin: mareko: ok -- did this change semi-recently?
17:03 mareko: yes
17:03 imirkin: (i agree, i'm not sure why bounds would have been provided for non-indexed draws, but nouveau expected it]
17:03 mareko: I think I fixed many drivers to not expect them to be valid, not sure
17:03 jekstrand: zackr: I could come up with quite a few names but I don't think you'd want them. :P
17:04 imirkin: and obviously there's no indirect drawing with client-side buffers?
17:04 imirkin: actually i guess that's unrelated.
17:04 mareko: there is
17:04 mareko: with GL compat
17:04 imirkin: doh
17:04 imirkin: anyways, i'll check your commits to see how to properly compute the bounds
17:05 zackr: jekstrand: haha
17:06 mareko: imirkin: you'd be better off if you let frontends handle user buffers for you, it's a requirement for all the multithreaded goodness
17:06 imirkin: mareko: we have interfaces to send user buffers via pushbuf directly
17:07 imirkin: saves on all the separate upload/sync/etc stuff
17:07 mareko: uploads are free, there are no synchronizations
17:08 imirkin: anyways, that's not a change i'd do lightly - would need to test, etc
17:08 imirkin: otoh we should just flip that on for maxwell+
17:09 imirkin: since those direct submit interfaces are gone there
17:17 Kayden: imirkin: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8453 might be relevant, but I'm not sure if it applies to gallium drivers...fixes some things for classic
17:18 imirkin: Kayden: thanks!
17:18 Kayden: ah but that apparently breaks v3d
17:18 imirkin: can't win 'em all
17:58 anholt: pepp: any word on getting deqp-runner for piglit released?
18:22 danvet: pinchartl, got cc'ed on some v4l thread ... are the dma-buf mappings not fixed when you set up the pipeline?
18:22 danvet: it sounds like you can spec a new one for each enqueue
18:23 danvet: which sounds pretty bad compared to native v4l buffers
18:24 pepp: anholt: not yet, so for now I can't publish it :(
19:31 airlied: jekstrand, bnieuwenhuizen so layers need an api version in json greater than app asks for
19:32 airlied: this is why device select doesnt currently load for vulkaninfo
19:32 dcbaker: Anyone know Jeremy Huddleston Sequoia'a nick (or if they have one?). They're pushing a bunch of branches to the mesa/mesa repo instead of a fork
19:33 airlied: not sure if i should generate the json from the version of headers we have
19:34 airlied: dcbaker: ysed to be jeremyhu i think, but dont see them on heew
19:35 HdkR: I have nothing in any of my Freenode logs from that alias
19:36 dcbaker: I haven't seen Jeremy around for years
19:46 karolherbst: HdkR: ehhh.. I figured out why tsan was useless.. I threw away my build dir all the time and that disabled tsan :D
19:47 HdkR: oh, haha
20:28 kisak: hmm ... jeremyhu now has 4 topic branches in mainline mesa instead of in a personal fork. Seems like a communication failure.
20:28 jekstrand: Yeah...
20:28 mattst88: I left a comment on one of his PRs
20:29 jekstrand: I wish there was a button in Gitlab to prevent creation of branches
20:29 mattst88: I remember we had someone force push the Mesa master branch when we hadn't seen that people around in maybe a year
20:30 mattst88: probably indicates that we should be a little more proactive about disabling commit access
20:33 dcbaker: but seriously, who would have ever thought that a Microsoft would be reviewing Apple code in mesa? What a strange world.
20:33 mattst88: lol
20:33 airlied: someone just needs to take alyssa RE work build on it and port Mesa userspace to apple iokit drivers for native GL drivers :-P
20:34 jenatali: :)
20:34 dcbaker: Alyssa was talking about doing that I think...
20:35 dcbaker: "Before you can install our game, you need to install mesa to get a native vulkan driver..." 🤣
20:36 airlied: well it would allow developing a mesa driver while waiting for a base Linux OS to show up
20:37 bnieuwenhuizen: airlied: time for layer 1.2.999 ?
20:37 jenatali: Seems like a flaw in gitlab's permissions system that you can't disable branch creation permissions
20:37 kisak: dcbaker: that doesn't sound like the Apple ecosystem ... better bundle it in every application
20:37 airlied: bnieuwenhuizen: yeah need to look today and see what the loader matches on, if it cares about patch
20:38 airlied: bnieuwenhuizen: might just need 1.999.0 :-P
20:38 dcbaker: kisak: it also sounds like the sort of thing apple would deny you entry into the app store for doing
20:47 anholt: progress on getting asan into CI: https://gitlab.freedesktop.org/anholt/mesa/-/jobs/6664088
20:48 HdkR: oooo, I like
20:51 HdkR: Now I want to get a couple more CI machines to run asan builds myself
20:53 imirkin: anholt: now you get to fix the leaks :)
20:57 anholt: that's what xfail lists are for
21:09 imirkin: hehe
21:13 MrBIOS: hey, has anybody here ever worked on directfb?
21:13 imirkin: the sdl backend?
21:43 Rodrigo_: imirkin: the stream buffer seems to have fixed the performance issues on mesa
21:43 Rodrigo_: NV is still faster but that's to be expected since there are still some synchornized BufferSubData calls and I'm using vendor extensions when available
21:50 imirkin: cool
22:14 Lyude: vsyrjala: wouldn't surprise me if they don't because speed
23:56 karolherbst: MrBIOS: why would you even need that?
23:56 MrBIOS: karolherbst legacy shit, man
23:56 karolherbst: I feel sorry for you
23:57 MrBIOS: don't :)
23:57 karolherbst: too late