ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Danct12 has joined #dri-devel
Mangix has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
Mangix has joined #dri-devel
kzd has quit [Quit: kzd]
sukrutb has quit [Ping timeout: 480 seconds]
sukrutb has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
sukrutb has quit [Ping timeout: 480 seconds]
kzd has joined #dri-devel
crabbedhaloablut has joined #dri-devel
loki_val has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
ngcortes has quit [Ping timeout: 480 seconds]
rcf has quit [Read error: Connection reset by peer]
rcf has joined #dri-devel
atipls has quit [Killed (NickServ (Too many failed password attempts.))]
atipls has joined #dri-devel
<tarceri> mareko: sorry for the delay. Yes the cache does crc checks on the data after its loaded
<tarceri> see para_and_validate_cache_item() for the multifile cache eaxmple
<tarceri> or mesa_cache_db_read_entry() for the single file example
sukrutb has joined #dri-devel
Haaninjo has joined #dri-devel
aravind has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
atipls_ has joined #dri-devel
atipls has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
gfxstrand has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
gfxstrand has joined #dri-devel
tzimmermann has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
An0num0us has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
sukrutb has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
novaisc has quit [Remote host closed the connection]
mairacanal has quit [Remote host closed the connection]
tonyk has quit [Remote host closed the connection]
tales-aparecida has quit [Remote host closed the connection]
tursulin has joined #dri-devel
pekkari has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jkrzyszt has joined #dri-devel
Adrinael has quit [Ping timeout: 480 seconds]
<MrCooper> DemiMarie: "compute and gfx are serialized" means any long-running compute job makes the GPU unusable for interactive graphics
guru_ has quit [Remote host closed the connection]
guru_ has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
vliaskov has joined #dri-devel
Daanct12 has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.0.5]
Daanct12 has joined #dri-devel
rasterman has joined #dri-devel
lynxeye has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
Company has joined #dri-devel
mvlad has joined #dri-devel
atipls_ has quit []
pekkari has quit [Quit: Konversation terminated!]
atipls has joined #dri-devel
An0num0us has quit [Ping timeout: 480 seconds]
<karolherbst> airlied: I might need some help debugging llvmpipe JIT code
<karolherbst> uhh actually.. I have an idea what's wrong
<karolherbst> yeah.. scratch memory is busted
<karolherbst> nice, it works :3
sarahwalker has joined #dri-devel
Peuc_ has joined #dri-devel
Peuc has quit [Ping timeout: 480 seconds]
An0num0us has joined #dri-devel
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
cmichael has joined #dri-devel
novaisc has joined #dri-devel
tonyk has joined #dri-devel
heat has joined #dri-devel
<cwabbott> dj-death: bad news, apparently past me wasn't careful enough because there are more failures with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25436 and it's a fundamental problem that requires a bigger rework
<cwabbott> the problem is that different stages contribute different pipeline_flags, and we can't combine them in vk_graphics_pipeline_state_merge() because we'd have to create a new render pass state object instead of doing a shallow copy and it's totally not setup to do that
<cwabbott> I think we weren't sanitizing the flags as much before this so we didn't run into it
<cwabbott> but it's a fundamental problem with how we're handling it
<cwabbott> I think the only non-terrible solution is to move the pipeline_flags up into vk_graphics_pipeline_state
<cwabbott> that means I'm gonna have to rewrite everything again :/
<dj-death> hmm I see
<dj-death> gfx libs again...
* cwabbott hates GPL
<cwabbott> another example of the axiom that there are no correct GPL implementations
<dj-death> I don't even want to think about shader objects
<karolherbst> shader objects are the best
<karolherbst> at least nvk and nvidia should have valid and correct implementations for shader objects
<karolherbst> easily
<cwabbott> at least shader objects doesn't have any of this nonsense
<karolherbst> shader objects map 1:1 to nvidia hardware (more or less)
<cwabbott> you just pass create flags into the shader and that's it
<cwabbott> no futzing around with copying state everywhere that's wrong half of the time
<dj-death> yeah
<dj-death> should have been called NV_shader_objects
<karolherbst> well.. it makes life easier for a lot of programmers
YuGiOhJCJ has quit [Remote host closed the connection]
<karolherbst> mareko: yeah.. the UI is way smoother now with COMPUTE_ONLY set
<karolherbst> though radv doesn't seem to use the compute queue for compute only vulkan contexts? Is this even a thing in vulkan?
<karolherbst> or maybe zink doesn't do something properly?
<karolherbst> oh well..
enunes has quit [Quit: ZNC - https://znc.in]
<glehmann> sounds like a zink issue, you can easily only create a queue from the family that supports compute but not graphics
enunes has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
mairacanal has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<karolherbst> mhh.. also the way I query zink devices only works on nvidia if nvidia-drm is used...
<karolherbst> mhh.. also gives me a VK_ERROR_OUT_OF_DEVICE_MEMORY...
<karolherbst> "566MiB / 23040MiB".. _sure_
<karolherbst> ahh
<karolherbst> zink allocates from the mappable region.. mhh
<karolherbst> "budget = 23461888 (0x01660000) (22.38 MiB)" figures..
<karolherbst> ohh probably missing BIND_GLOBAL handling or something...
<zmike> you can't use a compute queue in zink until there's a screen param added for compute screens
<karolherbst> ohh.. it needs tohappen on the screen level.. right
<karolherbst> I have no idea why, but whatever I do, it's entirely broken on nvidia :D
<karolherbst> ahh. the vvl go crazy
<karolherbst> that's because of one of my local changes...
<karolherbst> uhhh
<karolherbst> pain
<karolherbst> zmike: so the issue is, that nvidia only has this 256MiB window for HOST_VISIBLE | DEVICE_LOCAL memory.. https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/zink/zink_resource.c?ref_type=heads#L879
<zmike> that's gpu-
<zmike> dependent
<zmike> or you have rebar disabled
<karolherbst> I might have rebar disabled
<karolherbst> though does nvidia even support it on linux?
<zmike> yes
<karolherbst> how?
<karolherbst> it sounds like I have to flash the vbios?
<zmike> pretty sure it just works
<karolherbst> mhh.. let me check my uefi then, because I'm mildly sure I've enabled it there
<zmike> be pretty hard to do any gaming at all in the current year without it
<karolherbst> yeah.. it's enabled in my uefi
<karolherbst> well
aravind has quit [Ping timeout: 480 seconds]
<karolherbst> maybe I need a newer GPU? I have no idea, on my Turing I get 256MiB out of the box and that's it
<karolherbst> and there is this "NVIDIA Resizable BAR Firmware Update Tool" thing
<karolherbst> though there seem to be patches for nvidias driver to enable it as well...
<tnt> lspci for my card shows Region 1: Memory at 7400000000 (64-bit, prefetchable) [size=16G
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst> what nvidia gpu is that, and what distribution?
<zmike> I use a 2070 when I'm testing that
<karolherbst> I bet you have a nvidia kernel module patch for it then
<karolherbst> or maybe they added support for it and my driver is outdated..
Duke`` has joined #dri-devel
<karolherbst> but anyway "nvidia-smi -q | grep -i bar -A 3" reports 256 MiB on my Quadro 6000
<tnt> karolherbst: That's a 4070 running ubuntu 22.04 with 535.(104?) drivers.
<karolherbst> I'm on 535.104.05
<tnt> But you might be rights that your card needs a vbios update.
<karolherbst> it's one of the early turing ones, so yeah...
<karolherbst> anyway... having to rely on rebar might not be something which would be feasible here.. dunno
<karolherbst> but I suspect the vbios is just toggling some bit given that there is a module patch for it
<tnt> There is also some reference to a "compute mode"/"graphics mode", the former having a 8G BAR and the latter 256M.
<karolherbst> mhh.. interesting
<zmike> things should work, albeit suboptimally, without rebar, but it's definitely not a preferred mode of operation
<karolherbst> well.. 256 MiB isn't enough and zink fails to allocate memory at some point
<zmike> yeah and then it'll do a fallback to another heap
<karolherbst> but there isn't any compatible one
<zmike> compatibility is relative
<karolherbst> buffer allocates need HOST_VISIBLE and DEVICE_LOCAL and it doesn't look like it falls back to anything.. maybe I should debug a bit more, but it does look like it's just doing nonsense after that and crashes the GPU
<zmike> ctrl+f /* demote BAR allocations to a different heap on failure to avoid oom */
<karolherbst> ohh indeed.. still crashes the GPU though that might be something else going wrong
<karolherbst> mhh.. the vvl doesn't complain... let me run the CTS
masteratwork has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.0.5]
<masteratwork> I remember few details about thing called binary buddy allocator , in theory it's somehow possible to put stack and heap both to pc-relative locations in the kernel, and have the kernels allocator defragment things , but i do not remember the details well, sortix claims to do that, but i know sbrk and mmap are not very good at this regard. Of course i can be mistaken, binary buddy allocator was for win95 that seemed to
<masteratwork> work great alike though.
flto has joined #dri-devel
Daanct12 has joined #dri-devel
<masteratwork> Maybe in case of heap it would not make overly too much sense, cause heap can be larger on loops of memory intensive apps then code, its programmers responsibility to free it
<masteratwork> but if those ain't possible than only thing to do is to index the memory in compressed format, and that is quite rough
Danct12 has quit [Read error: Connection reset by peer]
<masteratwork> i mean not heap overall but the issue is with global variables likely , so that would make more sense, this can be pc-relative
<masteratwork> some section as to where they live
<masteratwork> all the heap apps allocation would be ping ponged through global variables or TLS or something like that through stack
Daanct12 has quit [Ping timeout: 480 seconds]
<masteratwork> so it's not like i made a very huge blooper on my compression theories, it's just that i may still lack some of the kernel skills to do it more easily
<cwabbott> dj-death: just pushed a fixed version
<cwabbott> now with this turnip actually passes all the tests again
<cwabbott> as usual, past me was an idiot
<cwabbott> dj-death: fyi, because of the reworks rebasing is not going to be trivial
<cwabbott> also I didn't build-test anv so I'm testing it in CI now
<dj-death> cwabbott: I'm doing it right now
<dj-death> it's not too bad
<cwabbott> one small thing is that anv had a few places passing around the render pass state which used it just to get the pipeline_flags
<cwabbott> so they passed around render pass state, multisample state, etc.
<cwabbott> and now they pass around all those other states... plus the vk_graphics_pipeline_state struct that contains all of them
<cwabbott> you could collapse all of those arguments down to one now that we have to pass around the overall state anyway, but I just went for the minimal change that replaced state->rp with state
<dj-death> yeah
Adrinael has joined #dri-devel
Adrinael is now known as Guest1666
alyssa has joined #dri-devel
<alyssa> cwabbott: hard disagree
<alyssa> past you wrote a state-of-the-art RA that present me is still digesting, definitely non-idiot
pcercuei has quit [Quit: leaving]
<cwabbott> dj-death: ugh, one last bug that I needed to fix so I pushed again
<cwabbott> forgot that other drivers merge libraries first so I have to OR in the flags in vk_pipeline_flags_init
<cwabbott> anv pipeline libraries will probably blow up without that
Guest1666 is now known as Adrinael
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
Danct12 has joined #dri-devel
yyds has joined #dri-devel
qyliss has quit [Remote host closed the connection]
qyliss has joined #dri-devel
vyivel has quit [Remote host closed the connection]
i509vcb has joined #dri-devel
Haaninjo has joined #dri-devel
<alyssa> airlied: so what happens with fedora 39 given the current mesa + llvm 17 lulz?
<karolherbst> I probably also should look into llvm 17.. pain
masteratwork has quit []
vyivel has joined #dri-devel
<Armote[m]> does Venus still require CONFIG_TRANSPARENT_HUGEPAGE to be disabled on the host or was this old KVM bug fixed? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/docs/drivers/venus.rst
<alyssa> karolherbst: i'm just confused, like
<karolherbst> same
<alyssa> why is f39 pulling in llvm17 if it breaks the mesa build
<karolherbst> I bet the reson is "it built, so it's fine"
<alyssa> mesa literally won't build
<karolherbst> maybe we should make life miserable for everybody by always checking for the llvm version and fail to compile on a newer one
<karolherbst> heh
<karolherbst> that's bad
<karolherbst> but anyway, my involvement in downstream fedora is pretty non existent, so I guess that's more like something for airlied to figure out
pekkari has joined #dri-devel
<alyssa> k
<psykose> alyssa: are you sure they rebuilt it yet?
<psykose> i've noticed a lot of specs that just 'use llvm' when i know for sure the latest llvm doesn't work with them
<psykose> i assume they just have some other invisible system or didn't actually rebuild
<alyssa> psykose: I don't know. but apparently we're supposed to be shipping f39 and um.
<psykose> :D
<HdkR> That's a spicy release schedule. LLVM 17 released 10 days ago
kzd has joined #dri-devel
kts has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
vyivel has quit [Read error: Connection reset by peer]
kts has quit [Ping timeout: 480 seconds]
vyivel has joined #dri-devel
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #dri-devel
<alyssa> daniels: sadly that's just the tip of the iceberg
<alyssa> but the fact 23827 isn't merged yet tells me fedora 39 should be fine with building against llvm16 lol
<karolherbst> fedora does indeed provide different llvm runtimes, just `llvm-devel` is always the newest
Danct12 has quit [Quit: What if we rewrite the code?]
kts has joined #dri-devel
Danct12 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
masteratwork has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
<karolherbst> sooo.. let's take a look at this llvm-17 mess
<karolherbst> alyssa: I'll probably try to make that CL stuff work on llvm-17 now, not sure how long it will take, but let me try to figure things out until next week
<karolherbst> though I think we already had fixes for most in place
<karolherbst> mhhh
Plagman has quit [Read error: Connection reset by peer]
Plagman has joined #dri-devel
egbert is now known as Guest1675
Guest1675 has quit [Remote host closed the connection]
egbert has joined #dri-devel
cmichael has quit [Quit: Leaving]
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
yang3 has quit [Read error: Connection reset by peer]
yang3__ has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
opotin65 has quit [Remote host closed the connection]
opotin65 has joined #dri-devel
sukrutb has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
tursulin has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
yyds has quit [Remote host closed the connection]
sukrutb has quit [Ping timeout: 480 seconds]
flom84 has joined #dri-devel
sukrutb has joined #dri-devel
Cyrinux9474 has quit []
Cyrinux9474 has joined #dri-devel
danylo has quit [Ping timeout: 480 seconds]
sukrutb has quit [Ping timeout: 480 seconds]
mripard has quit [Quit: mripard]
gouchi has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
gouchi has quit []
kts has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
digetx has quit [Ping timeout: 480 seconds]
ungeskriptet8 has joined #dri-devel
Danct12 has quit []
Danct12 has joined #dri-devel
haasn` has joined #dri-devel
ungeskriptet has quit [Ping timeout: 480 seconds]
digetx has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
masteratwork has quit [Remote host closed the connection]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
kts has joined #dri-devel
kts has quit []
vaxry has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<alyssa> dcbaker: adding script with multiple outputs
<alyssa> i know you don't like that but not as much as everyone won't like what it's for (:
<dcbaker> alyssa: I'm cool with a script with multiple outputs
<alyssa> oh I thought that was treif?
<dcbaker> I'm always the one shooting down "gen_thing_c.py" + "gen_thing_h.py" and arguing that we should have "gen_thing.py" that generates both
<alyssa> ahhhh
<alyssa> this is an extremely spicy intel_clc spin-off
<dcbaker> oh boy, how could intel_lcl get any spicier
<alyssa> I heard you like C, so I'm writing C to generate C from your C for your C
fab has quit [Quit: fab]
<alyssa> magic that makes arbitraryish OpenCL functions available as nir_builder with no bindings
<dcbaker> Xzibit approves this message
<dcbaker> the existing CLC stuff is annoying, as is getting people to review the meson bits I'm trying to add to make it less annoying
<alyssa> cc me on anything you want reviewed
<dcbaker> I should rephrase that "new Meson features I'm trying to add to Meson itself to make clc less annoying"
<dcbaker> but in particular this: https://github.com/mesonbuild/meson/pull/12258
<dcbaker> which I need to make dependency(..., native : 'both') work correctly
ngcortes has quit [Ping timeout: 480 seconds]
<alyssa> oh
<cmarcelo> dcbaker: oh, I thought we had issues with multiple outputs? probably can fix this for glsl_type stuff (we have three outputs, so right now three separate scripts).
<dcbaker> only if we use capture : true, which we shouldn't be using because it makes everything slow on Windows
<cmarcelo> yeah. I've moved off capture, so maybe can just merge them up. will take a note of that.
<dcbaker> Well, slow on Linux too, but really slow on Windows because forking is so expensive
<dcbaker> I would review that change
<alyssa> how does capture with 2 outputs work..?
<dcbaker> it doesn't :)
<alyssa> no perf issue then!
<alyssa> :P
<dcbaker> lol
<cmarcelo> well.... one for stderr and other for stdout. :-D
<dcbaker> capture is just slow in general because Meson has to wrap a custom_target that uses feed or capture inside a meson script
<dcbaker> so you get an extra fork
<alyssa> ah
<cmarcelo> not the case of meson, but I think you could open fds and let the child inherit them, so not touching stdout or stderr.
<cmarcelo> (but yeah, unrelated to the wrapper issue)
tobiasjakobi has joined #dri-devel
grillo_0 has joined #dri-devel
tobiasjakobi has quit []
mszyprow has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
clamps has joined #dri-devel
luben has joined #dri-devel
DorAskayo[m] has joined #dri-devel
jfalempe has quit [Quit: Leaving]
An0num0us has quit [Ping timeout: 480 seconds]
DorAskayo[m] is now known as doraskayo
doraskayo has quit [Quit: Reconnecting]
doraskayo has joined #dri-devel
sghuge has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
heat has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
flom84 has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
sghuge has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<gfxstrand> Ugh... Found a very old bug in spirv_to_nir with tesselation patch I/O. Do I dare fix it?
<gfxstrand> We're using VARYING_SLOT_VARN sometimes for patch stuff
i509vcb has quit [Quit: Connection closed for inactivity]
loki_val has quit []
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
doraskayo has quit [Quit: Reconnecting]
doraskayo has joined #dri-devel
shashanks_ has joined #dri-devel
<gfxstrand> I kinda want a load/store_patch_output
shashanks__ has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
doraskayo has quit []
doraskayo has joined #dri-devel
kzd has quit [Quit: kzd]
ngcortes has quit [Read error: Connection reset by peer]
rsalvaterra has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<cmarcelo> gfxstrand: found by inspection or you have a test case?
kts has joined #dri-devel
Company has quit [Remote host closed the connection]