<ishitatsuyuki>
pretty sure the power-of-two check for vramlimit is a mistake, but if there's any legitimate reason please let me know
<ishitatsuyuki>
I don't see any possible reason right now especially when 3GB/6GB cards exists
<tagr>
daniels:
<tagr>
daniels: hi, I've been meaning to create a tegra project on gitlab for issue tracking (and maybe also to host the drm/tegra kernel driver), but for some reason I can't add a repository to the drm group
<tagr>
is there anything I need to do first to be able to do this?
<tagr>
oh wait... do I need to be a member of that group first?
lynxeye has joined #dri-devel
rbrune has joined #dri-devel
shashank1202 has joined #dri-devel
<MrCooper>
ishitatsuyuki: I'm afraid you'll be disappointed when it needs to read back from swap in RAM, 10s of MB/s
<MrCooper>
*in VRAM
<ishitatsuyuki>
still better than a SSD
<ishitatsuyuki>
no?
<MrCooper>
not even close
<ishitatsuyuki>
that sounds concerning
<MrCooper>
NVMe SSDs read 100s of MB or even GB/s
<MrCooper>
even spinning rust does 100s of MB/s
Lucretia has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
tzimmermann has quit [Ping timeout: 480 seconds]
muhomor has quit [Remote host closed the connection]
adjtm has quit [Quit: Leaving]
tzimmermann has joined #dri-devel
<airlied>
MrCooper: I think I've seen a vramfs impl on opencl which might be able to use sdma, granted you'd have to have a CL impl and SDMA :-P
<ccr>
somehow that sounds a bit scary to me
<MrCooper>
FWIW, compute shaders shouldn't be much worse than SDMA AFAIK
Ahuj has joined #dri-devel
<ishitatsuyuki>
MrCooper: I haven't bother to do a benchmark yet, but was your configuration using PCI BAR?
pcercuei has joined #dri-devel
<ishitatsuyuki>
I'm planning to use the slram kernel module
<MrCooper>
PCI(e) BAR, yeah; does slram use something else?
<ishitatsuyuki>
I don't think so
<ishitatsuyuki>
I was just wondering if your setup could have been involving too much abstractions, like passing a memory page into userspace then read/write using the Vulkan/CL driver
<MrCooper>
the only trick I know of it could use is non-temporal reads, but even that would only yield around 100 MB/s IIRC
<MrCooper>
nope, raw CPU reads
<ishitatsuyuki>
hmm, sounds unfortunate
<ishitatsuyuki>
SDMA on the other hand has the track record of being buggy and disabled by the driver devs
<MrCooper>
it's uncacheable memory at the other end of a PCIe link
<MrCooper>
every normal CPU read is a synchronous round-trip to the GPU and back
pjakobsson has quit [Remote host closed the connection]
<ishitatsuyuki>
fair, queue based protocols like NVMe definitely can have an advantage here
pjakobsson has joined #dri-devel
thellstrom has quit [Quit: thellstrom]
<ishitatsuyuki>
yeah you're right, I just benchmarked with phram (slram's successor) and write is very fast but read is absurdly slow
<mceier>
gawin: "mareko> when gawin joins, can please somebody tell him that r3xx doesn't have hw support for break, ifs, and loops?"
<gawin>
thanks
hansg has joined #dri-devel
<gawin>
mareko: so probably best would be to tell tgsi or even earlier (glsl etc) to not use break?
<mareko>
gawin: that's impossible
<mareko>
gawin: break can't be lowered or eliminated by upper layers
<gawin>
mareko: how about changing break into "wrap rest of code with if and set loop's condition to true"?
<gawin>
wait you said that if is also not supported
<mareko>
the for loop condition is the break
agners has quit [Ping timeout: 480 seconds]
<tagr>
danvet: great, thanks! yeah, karolherbst had also suggested that we could track issues as part of drm/nouveau... I don't really mind where they are tracked, as long as I have access to them and can get notified
<FLHerne>
I know i915 lacks that entirely and is "best efforts" for anything above ES2
agners has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
agners1 has joined #dri-devel
agners has quit [Ping timeout: 480 seconds]
shashank1202 has quit [Quit: Connection closed for inactivity]
Company has joined #dri-devel
rbrune has quit [Quit: Leaving]
thellstrom has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
Peste_Bubonica has joined #dri-devel
vivijim has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
itoral has quit []
Ahuj has quit [Ping timeout: 480 seconds]
shashank1202 has joined #dri-devel
sukbeom__ has quit [Ping timeout: 480 seconds]
tobiasjakobi has quit [Remote host closed the connection]
gawin has quit [Quit: Konversation terminated!]
<dj-death>
I'm trying to lower mem_global variables into mem_temp when I know that those are read_only, in the hope that they can be optimized somehow
<dj-death>
anybody's done anything like that before?
dviola has quit [Quit: WeeChat 3.2.1]
jewins has joined #dri-devel
agd5f has joined #dri-devel
fxkamd has joined #dri-devel
sdutt has joined #dri-devel
<jenatali>
dj-death: We do this in CLOn12, not sure if it's mem_global or maybe just constant, but we look for access patterns and lower to shader_temp
<jenatali>
dj-death: dxil_nir_lower_ubo_to_temp
<dj-death>
jljusten: oh thanks a lot
<jenatali>
dj-death: I expect you'll want to use it as reference rather than move it as-is, ours has some DXIL-specific details in there like memory access widths
<dj-death>
jljusten: I'm just curious how you deal with casts
<dj-death>
jenatali: I'm just curious how you deal with casts
<jenatali>
IIRC we give up on casts
<dj-death>
ah ;)
<dj-death>
because patching stuff makes me generate invalid NIR because of the casts that still retain mem_global
<jenatali>
Oh sure you'd have to walk the deref chain and replace everything
dviola has joined #dri-devel
Danct12 has joined #dri-devel
<dj-death>
I see
<dj-death>
I'll attempt that
<dj-death>
jenatali: I guess I'm missing where you update the whole chain
<jenatali>
dj-death: Yeah I looked at that pass, it's too simple, it only supports single-deref accesses
<danvet>
mripard, sry I've massively ignored dri-devel last week
<danvet>
mripard, I think it's fine
<danvet>
ish
<danvet>
mripard, in other drivers we've solved these by just directly calling into encoder callbacks
<danvet>
and taking the right drm_modeset_lock
<danvet>
since it's kinda modeset state
<danvet>
like re-training dp links
<danvet>
just feels a bit icky to throw this into the detect callback
<danvet>
but also our locking between these two is icky a bit, so *shrug*
<danvet>
mripard, that was kinda what I mean with "handle in their own code"
<danvet>
not "you should only touch this from modeset state"
<danvet>
but more "why are you fighting the helper layers here for no good reason"
<danvet>
but if you think that's the best way, then looks all fine to me
<mripard>
I don't think anything at all about this to be honest :)
<mripard>
I know it fixes our issues, but I don't have an argument for this approach compared to another
<mripard>
if anything, we should at least be consistent
<mripard>
do you have an example of drivers calling into the encoder callbacks?
<danvet>
mripard, yeah it makes sense
<danvet>
one issue you do have though is that your locking is busted
<danvet>
or at least maybe
<danvet>
mripard, I'm trying to find out where/how you actually restore the scrambler state
<danvet>
doing that might require the connection_mutex drm_modeset_lock
<danvet>
i.e. needs detect_ctx, not detect
<danvet>
ah no we grab that by default now since 6c5ed5ae353cd
<danvet>
mripard, should be all good
<danvet>
if you want a-b: me on the series
<danvet>
assuming sravn_ has actually reviewed this
<danvet>
maybe if you're bored also check how many others have screwed this up
rasterman has joined #dri-devel
<mripard>
I was looking at the other users of drm_scdc_set_scrambling (which should be all of the drivers supporting HDMI scrabling)
<mripard>
there's i915, tegra, dw-hdmi and vc4
<mripard>
tegra and dw-hdmi don't seem to be doing anything in that case
<mripard>
they just enable it in enable(), and don't care anymore after that
<mripard>
and I couldn't really figure out the flow of functions of i915
mattrope has joined #dri-devel
<mripard>
danvet: I guess we should also document that behaviour somewhere? (in drm_scdc_helper.c?)
<danvet>
yeah maybe an assert_lock_held or so?
<danvet>
and yeah i915 is hand-rolled hpd handling entirely
<mripard>
I wasn't really talking about the locking itself, but rather how does one deal with the disconnection and scrambling status
<mripard>
but yeah, locking is another thing we should document :)
sravn_ has quit []
sravn has joined #dri-devel
<sravn>
danvet, mripard: I reviewed only patch 1 and two in the set. I bailed the last patch "[PATCH v2 3/3] drm/vc4: hdmi: Actually check for the connector status in hotplug"
<sravn>
I had to dig through too much other code to review it properly.
Peste_Bubonica has quit [Quit: Leaving]
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
jernej_ is now known as jernej
Duke`` has joined #dri-devel
Net147 has quit [Ping timeout: 480 seconds]
<mauld>
mlankhorst: mripard: there are some ttm changes here: https://patchwork.freedesktop.org/series/95093/. what is the quickest way to get the ttm changes back into drm-intel-gt-next? just merge to drm-misc-next and backmerge to gt-next, or maybe topic branch?
qyliss has quit [Quit: bye]
Net147 has joined #dri-devel
<mlankhorst>
topic branch
<mlankhorst>
what do you need as base?
<mlankhorst>
depends mostly, do any of the i915 changes depend on some current stuff in drm-intel-gt-next?
qyliss has joined #dri-devel
mbrost has joined #dri-devel
<jenatali>
I'm assuming people are aware that the GitLab runners all appear to be down?
sukbeom has joined #dri-devel
<mauld>
mlankhorst: i don't think so?
nchery has joined #dri-devel
<dcbaker>
Someone brought it up on #freedesktop a couple of hours ago
<jenatali>
I should join that channel...
Net147 has quit [Ping timeout: 480 seconds]
Net147 has joined #dri-devel
<danvet>
mlankhorst, mauld yeah if the ttm patches just can land right away, topic-branch-less is less paperwork and as fast (outside of merge window at least)
unsolo has joined #dri-devel
heat has joined #dri-devel
<anholt_>
jenatali: kicked the registry again. #freedesktop is the place to report, though.
rasterman has quit [Quit: Gettin' stinky!]
frieder has quit [Remote host closed the connection]
agd5f_ has joined #dri-devel
iive has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
jhweruyuw has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
kem has joined #dri-devel
<robclark>
danvet: hmm, are we allowed to use c11 in drivers yet?
<robclark>
or even gnu99/c99?
rgallaispou has quit [Read error: Connection reset by peer]
<ajax>
in mesa? yes.
<dcbaker>
Doesn't mesa straight require c11 now?
* robclark
meant kernel
camus1 has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
hch12907 has quit [Remote host closed the connection]
gouchi has joined #dri-devel
hch12907 has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<jernej>
mripard: I just tested DW-HDMI driver with 4k monitor and it already properly re-enables scrambling after power off/on cycle
<mripard>
jernej: power off/on of the monitor?
<jernej>
yes
<jernej>
it seems that whole mode set procedure is executed in this case
<jernej>
on disconnect HDMI PHY is powered down
<jernej>
so I guess this makes sence
<jernej>
*sense
<mripard>
jernej: is that what dw_hdmi_setup_rx_sense is doing?
<jernej>
I'm studying this function now and yeah, it can power on/off phy and in the process, set mode
<mripard>
I'm not sure it's valid
<jernej>
but that function is also called from irq handler, which doesn't seem like a good choice to me
<mripard>
it's a threaded irq
<mripard>
so the context is a thread, it can sleep or whatever
<jernej>
oh, right
kem has quit [Ping timeout: 480 seconds]
<jernej>
anyway, while everything works pretty good with monitor, it doesn't with my 4k TV
<jernej>
I suspect TV uses some hpd tricks and in the process, driver doesn't set scrambling or something
jhweruyuw has quit []
<jernej>
I have yet to figure it out
<mripard>
what are you testing it with?
<mripard>
fbcon?
gawin has joined #dri-devel
<jernej>
no, Kodi on LibreELEC
<jernej>
I'll try without it
<jernej>
works with fbcon too
<mripard>
if it works with fbcon but not with Kodi
<mripard>
it's that it relies on the user-space / client (for fbdev emulation) to come and poke at the device to make it work
<jernej>
anyway, it works with and without Kodi running
<mripard>
while Kodi (just like modetest) ignores hpd events
<mripard>
wait, I'm confused
<mripard>
does it work or not?
<jernej>
it works in both cases with my 4k monitor but neither case on my TV :)
<jernej>
I don't have idea why TV doesn't work, it may be scrambling, but it may be something else too
hch12907 has quit [Ping timeout: 480 seconds]
<jernej>
(only 4k@60 doesn't work, 1080p works on TV)
kem has joined #dri-devel
<jernej>
so userspace in my case doesn't really matter
gawin_ has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
sukbeom has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
mbrost has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
<HdkR>
Having never looked at Wayland APIs, Did Wayland resolve the issue of the API exposing allocations that the application is expected to call `free` on? I see a bunch of X11 APIs assume this behaviour...
mlankhorst has joined #dri-devel
kmn has quit [Quit: Leaving.]
idr has joined #dri-devel
NiksDev has quit [Remote host closed the connection]
mbrost has quit [Remote host closed the connection]
NiksDev has joined #dri-devel
jkrzyszt_ has quit [Remote host closed the connection]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
gawin_ has quit []
tzimmermann has quit [Quit: Leaving]
valentind has quit []
Ahuj has joined #dri-devel
adjtm has joined #dri-devel
lynxeye has quit []
gawin has joined #dri-devel
<gawin>
sorry for spaming, but is there a good way for finding source code of test in piglit's code? uhh, debugging r300 is a hell
<ajax>
they're all under test/
<ajax>
git grep (some substring of the test name) usually gets you pretty close
hansg has quit [Quit: Leaving]
<gawin>
I have an issue with founding "built-in-functions" from glsl 1.1
<gawin>
are they generated by python on the fly?
<ajax>
yep
<ajax>
generated_tests/builtin_function.py
<dcbaker>
Not on the fly
<dcbaker>
They're generated at build time
<ajax>
fine, on the ground.
halfline has quit [Ping timeout: 480 seconds]
tomeu has quit [Read error: Connection reset by peer]
shadeslayer has quit [Write error: connection closed]
padovan has quit [Read error: Connection reset by peer]
italove has quit [Read error: Connection reset by peer]
fahien2 has quit [Remote host closed the connection]
leandrohrb has quit [Read error: Connection reset by peer]
tomeu has joined #dri-devel
italove has joined #dri-devel
fahien2 has joined #dri-devel
padovan has joined #dri-devel
shadeslayer has joined #dri-devel
leandrohrb has joined #dri-devel
flibitijibibo has joined #dri-devel
italove8 has joined #dri-devel
<emersion>
HdkR: libwayland has dedicated destructors
<HdkR>
emersion: So any application visible pointers must be passed back to the API for the destruction then? :)
<HdkR>
Or anything above libwayland layer I guess
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
xexaxo has quit [Remote host closed the connection]
italove8 has quit []
elongbug has quit [Ping timeout: 480 seconds]
xexaxo has joined #dri-devel
mbrost has joined #dri-devel
<emersion>
HdkR: yeah
<HdkR>
niiice
<HdkR>
I'm currently reading through X11 API and trying to figure out who deletes a pointer on return is...madness
cyrozap has quit [Remote host closed the connection]
leandrohrb0 has joined #dri-devel
<HdkR>
Is there a way to control the mesa shader cache program name other than mesa reading `/proc/self/exe`?
<HdkR>
Environment variables or API paths I'm thinking
danvet has quit [Ping timeout: 480 seconds]
leandrohrb0 has quit []
leandrohrb0 has joined #dri-devel
<HdkR>
I started grepping the source but getting the process name sort of spider webs out a bit :)
<HdkR>
Also concerned about driconf breaking
bcarvalho has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Ahuj has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.2]
mbrost has quit [Remote host closed the connection]
<jekstrand>
Bah... Once again, I get to figure out why I can't enumerate an OpenCL device. *sigh*
<jenatali>
Dynamic pipe loader?
<jekstrand>
Nah, looks like it can't find libclc
<jekstrand>
Looks like my libclc.pc file was wrong. Seems like a fedora bug.
<jekstrand>
Woo! I have a device now.
<jekstrand>
Now I can figure out how I torched images.
<robclark>
you hit the /usr/usr/... thing?
<jekstrand>
yup
<jekstrand>
Actually, /usr//usr/ if we're being pedantic. :P
<zmike>
we are.
<robclark>
yeah, I think I ended up just hacking local .pc file for that, IIRC
<jekstrand>
samw
<jekstrand>
*same
<jekstrand>
Someone should probably fix the Fedora package
<jekstrand>
ajax: ^^
<airlied>
oops wierd
<airlied>
I wonder when that snuck in
<airlied>
days since I last vomited due to cmake: 0
<dcbaker>
That belongs on the cmake-hate twitter for sure :)
<zmike>
will retweet
kaylie has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
adjtm has quit [Remote host closed the connection]
Viciouss has quit [Quit: Ping timeout (120 seconds)]
adjtm has joined #dri-devel
Viciouss has joined #dri-devel
<anholt_>
could anyone give me a high-level explanation of what the VK_EXT_display_control is supposed to be able to do while I'm logged into an X or wayland desktop session?
<HdkR>
This is the VR HMD control extension isn't it?
<HdkR>
I guess you could use it for regular display events?
<HdkR>
It's jsut all about returning events about that display, you can see all the event types in the enums there :)
karolherbst has quit [Quit: Konversation terminated!]
<haagch>
VK_DISPLAY_EVENT_TYPE_FIRST_PIXEL_OUT_EXT seems very interesting. does that actually work?
pcercuei has quit [Quit: dodo]
<HdkR>
If your driver stack implements it then hopefully
* haagch
just gonna try it
X-Scale has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
X-Scale` has quit [Ping timeout: 480 seconds]
jhweruyuw has joined #dri-devel
jhweruyuw has quit [Remote host closed the connection]
jhweruyuw has joined #dri-devel
cyrozap has joined #dri-devel
<jekstrand>
jenatali: I think I have !4743 mostly working for CL now with clover. It doesn't pass on iris but it also doesn't crash so I think it's likely just iris problems at this point.
<jekstrand>
jenatali: Still waiting on CI for llvmpipe.
<jekstrand>
jenatali: Point being, now would be a good time for you to look at it. :D
<jenatali>
jekstrand: Ack
<jenatali>
I can probably block some time off this week
<jekstrand>
Thanks!
<jekstrand>
I *think* all you'll need to fix is replace any loops over image variables with nir_foreach_image_variable
<jekstrand>
But, you know... famous last words and all....
<jekstrand>
Hrm... Looks like llvmpipe CL is now failing instead of crashing so I probably did break something. (-:
<jekstrand>
I'll look at that tomorrow.
<jenatali>
Yeah, I think that'll be okay
<jekstrand>
Ugh... Clover uses images as actual uniforms. I forgot that.
<jenatali>
Just to confirm, image != texture, right?
<jekstrand>
yes
<jenatali>
That also seems odd, for the record. I'd expect images and textures to be similar enough that a variable that's an image would have the same mode as a variable that's a texture
<jenatali>
But ah well
<jekstrand>
At least on our HW, they go through totally different HW units, caches, etc. They are not the same in any way.
<jenatali>
Oh, huh
<jekstrand>
I mean, they both turn into dimensional pixel data in memory but that's about it.
<jekstrand>
And the descriptors, annoyingly, are slightly different too. :-(
<jekstrand>
I should complain at the HW guys about that.
<airlied>
the write paths are always painful in hw
Lyude has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
<airlied>
esp anything with multisample or compression
shashank_sharma has joined #dri-devel
shashanks has quit [Remote host closed the connection]
karolherbst has joined #dri-devel
shashank1202 has quit [Quit: Connection closed for inactivity]
<robclark>
jenatali: fwiw on adreno we can use texelFetch (texture) for image reads that don't need to be coherent with other sorts of writes.. but not for ones that need to be coherent (because cache hierarchy)
<jekstrand>
We could too, technically. But we don't bother except for Vulkan input attachments.
<jenatali>
robclark: Ah, yeah ok that makes sense
<jekstrand>
Modulo descriptor differences, that is.
<anholt_>
jekstrand: your image accesses go through render cache, right?
jernej_ has joined #dri-devel
jernej has quit [Read error: Connection reset by peer]
<jekstrand>
anholt_: On IVB, yes. On HSW+, it's through the data cache (same as SSBOs). On DG2+, SSBOs move to a new cache and images stay in the data cache.
<anholt_>
(for us, texelFetch has the normal texture cache, but image accesses don't have one that I know of)
<robclark>
(and SSBO's and images are *basically* the same thing)
<jekstrand>
If you want a little entertainment, read my recent patches for barrier(). It all moves around an annoying amount.
iive has quit []
jernej has joined #dri-devel
jernej_ has quit [Ping timeout: 480 seconds]
* jekstrand
has no idea how clover works at all....
<airlied>
it's okay nobody does
<jenatali>
Yup
<jekstrand>
Figured it out
<jekstrand>
I think I've got clover working for realz now. Even on iris. :D