illwieckz has quit [Remote host closed the connection]
gnuiyl has quit []
gnuiyl has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit [Quit: Leaving]
The_Company has quit []
i-garrison has quit []
i-garrison has joined #dri-devel
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
kasper93_ has quit [Remote host closed the connection]
feaneron has quit [Ping timeout: 480 seconds]
vedm_ is now known as vedm
gnuiyl has quit [Remote host closed the connection]
itoral has joined #dri-devel
kts has joined #dri-devel
dolphin has joined #dri-devel
tzimmermann has joined #dri-devel
glennk has joined #dri-devel
cascardo_ has joined #dri-devel
cascardo has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
gnuiyl has joined #dri-devel
jsa1 has joined #dri-devel
sima has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
azerov has quit [Quit: Gateway shutdown]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
atiltedtree has quit [Remote host closed the connection]
ella-0 has quit [Remote host closed the connection]
rosefromthedead has quit [Remote host closed the connection]
nucfreq has quit [Remote host closed the connection]
cmarcelo has quit [Remote host closed the connection]
kuruczgy has quit [Remote host closed the connection]
mainiomano has quit [Remote host closed the connection]
hummer12007 has quit [Remote host closed the connection]
pitust has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
alethkit has quit [Remote host closed the connection]
lph has quit [Remote host closed the connection]
rpigott has quit [Remote host closed the connection]
cmarcelo has joined #dri-devel
warpme has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
ella-0 has joined #dri-devel
kuruczgy has joined #dri-devel
atiltedtree has joined #dri-devel
ifreund has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
nucfreq has joined #dri-devel
sguddati has joined #dri-devel
alethkit has joined #dri-devel
rpigott has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
rosefromthedead has joined #dri-devel
hummer12007 has joined #dri-devel
pitust has joined #dri-devel
kennylevinsen has joined #dri-devel
lph has joined #dri-devel
mainiomano has joined #dri-devel
MrCooper_ is now known as MrCooper
fab has joined #dri-devel
fab has quit [Read error: Connection reset by peer]
fab_ has joined #dri-devel
fab_ is now known as Guest9369
apinheiro has joined #dri-devel
Guest9369 has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
fab has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
kts has joined #dri-devel
<luc>
hi, what's the difference between window_modifiers and screen_modifiers in xcb_dri3_get_supported_modifiers_reply_t? with a quick search in xserver code, i found window_modifiers returned from ->get_drawable_modifiers() which seems like to be implemented only by glamor. i wonder what purpose exactly another set of modifiers needs to be provided in
<luc>
glamor.
mripard has joined #dri-devel
bbrezillon has quit [Ping timeout: 480 seconds]
gnarchie has quit []
<MrCooper>
luc: in a nutshell, screen_modifiers is that the drivers support in general, whereas window_modifiers can be a subset of that which changes dynamically, e.g. to allow direct scanout
<MrCooper>
err, s/that/what/ for the first instance
gnarchie has joined #dri-devel
hansg has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<luc>
MrCooper: thanks
kts has joined #dri-devel
<pq>
What do people think about storing userspace virtual addresses in KMS blobs for kernel driver access? The "Display Global Histogram" series seems to use them.
rasterman has joined #dri-devel
<pinchartl>
pq: in my experience, when it comes to passing userspace pointers, proper design is needed to create good APIs. KMS blobs are still documented APIs, even if they may get less scrutiny than ioctls
<pinchartl>
it could be worse, I've seen (out of tree) drivers passing physical addresses from unpriviledged userspace
kts has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
<pq>
pinchartl, I was kinda expecting to hear "don't do that".
<pq>
who knows what the lifetime of the blob is, so it's impossible to make sure the life time of the pointed to virtual memory is good.
<pinchartl>
I don't *like* the idea much, but I also have no really strong argument against it
<pinchartl>
true, but you'll have the same issue with ioctl arguments
<pinchartl>
it's inherent to user pointers
<pinchartl>
or was your question about whether or not we should use user pointers in APIs in the first place ?
<pq>
usually once the ioctl returns, the address is no longer used nor stored anywhere, right?
<pinchartl>
we have an API in V4L2 where you can queue a buffer to capture a video frame, using a userspace pointer
<pinchartl>
that's been deprecated a while ago, but it's still exists
<pinchartl>
I refuse new drivers using that API
<pinchartl>
so I'd say it's bad practice, yes
<pq>
cool.
<pinchartl>
maybe pass a GEM handle instead ?
<pq>
dunno
<pq>
the series has two uses: user->kernel has no reason to use user pointers, one could just put the pointed-to data into the blob.
<pq>
kernel->user for returning the histogram is more interesting
<pinchartl>
for user->kernel, true as long as the data isn't too big. if we're talking about MBs of data the copy can cause a performance impact
<pq>
nope, doesn't seem it would be 100s of bytes
<pq>
even
<pinchartl>
does this essentially queue a command to tell the device to calculate a histogram, with the histogram data being returned asynchronously ?
<pq>
pretty much, yeah, I think there is some kind of an event to tell when it's ready
feaneron has joined #dri-devel
<pq>
it's a pixel value histogram of a KMS output (CRTC)
<pinchartl>
a buffer whose lifetime is managed by the kernel would seem more appropriate
<pq>
yeah
feaneron has quit []
<pinchartl>
depending on the size of the histogram, the data could even be copied by DMA
<pinchartl>
so you don't want that memory to just be malloc'ed by userspace
<pq>
I think the histogram size in this one specific case is limited to 256 kB, but other modes could be added later.
<pinchartl>
even 256kB isn't negligible if you do it for every frame
vliaskov has joined #dri-devel
<sima>
pq, you can't do that
<sima>
I guess I'd need to reply there, do you have a link?
<sima>
it's also kinda not doable with out-blobs, because blobs are immutable
<pq>
sima, I just sent my reply now, I can dig the link
<sima>
blob properties aren't necessarily immutable, but we do mutability by changing the entire blob
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
sguddati has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
<pq>
I think something in my lei filter doesn't work.
<pq>
emersion, I think all my wildcard expressions in my lei search are broken.
factorymonkey has joined #dri-devel
factorymonkey has quit [Remote host closed the connection]
<pq>
Looks like matching for dfn:include/uapi/drm/drm_* just isn't possible.
monsterillies has joined #dri-devel
fab has joined #dri-devel
<pq>
emersion, FYI, if the lei search string is broken, you just get silently no hits.
fab is now known as Guest9378
warpme has quit []
vliaskov_ has joined #dri-devel
warpme has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
Guest9378 has quit [Ping timeout: 480 seconds]
rz_ has quit [Ping timeout: 480 seconds]
<monsterillies>
You think system rights are dangerous as to hijacking a syscall or ioctl can lead to the former but this seems correct and you think why not randomize the memory to make it harder right? Which is so and so, but why not to let kernel dealing with it's own memory ring and pass a pointer to all compressed or encrypted memory which has rights of userspace ring, now you see that actually
<monsterillies>
this tends to be more similar to microkernel concepts though even this holds not entirely either, so it is very new concept. Today you have so many threads not only pipeline subentities already, that some threads can have booting function, som kernel function forever etc. what that means the safety and security work becomes a sideproduct of my super execution and compression format....i
<monsterillies>
just told that cause it was likely you figured it out already. So to ever get access to something you insert a large code to change that system design etc.
feaneron has joined #dri-devel
mehdi-djait3397165695212282475 has joined #dri-devel
rz has joined #dri-devel
hansg has quit [Quit: Leaving]
pcercuei has joined #dri-devel
fab has joined #dri-devel
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #dri-devel
guludo has joined #dri-devel
itoral has quit [Quit: Leaving]
picosaurus has joined #dri-devel
monsterillies has quit [Ping timeout: 480 seconds]
u-amarsh04 has quit []
<picosaurus>
and such system is not very hard to design, your IO is accessed from memory or registers and at the moment it's done userspace does nothing with this memory or registers, in other words as the hardware became more powerful compared to eighties and before, entirely secure systems design also became different but is lot easier due the fact, overengineering was needed only with small
<picosaurus>
resources to be more exact.
sguddati has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
hansg has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
sguddati has quit [Ping timeout: 480 seconds]
<sima>
emersion, tldr; I think memfd properties. everything else I've pondered has more or less fundamental issues
<sima>
but it's a longer mail, still need to type it up, and I haven't even gotten to lunch today yet
<emersion>
memfd properties?
<sima>
like blob properties, except it's a memfd
<sima>
can be sealed, so no surprises with wrong size
<sima>
could be r/o sealed too if wanted
<sima>
already has mmap for zero copy
<sima>
and thanks to udmabuf there's memfd pin support, so also no work needed to map them kernel side
<sima>
but the full mail needs to walk through all the other options and why they're worse
<sima>
and the uapi questions we need to nail for memfd properties
nerdopolis has joined #dri-devel
dolphin has quit [Quit: Leaving]
u-amarsh04 has joined #dri-devel
picosaurus has quit [Remote host closed the connection]
u-amarsh04 has quit [Read error: Connection reset by peer]
opennanosaurus has joined #dri-devel
<opennanosaurus>
<picosaurus> based or open source my permission was given to anyone who could understand what i developed. Theory behind the safety of philosophy is simple, people who can level my skills legally are not considered danger unlike dummies or angry devils.
<opennanosaurus>
<picosaurus> You can do whatever you want, have coffee have a shack but at the same time robbing me and my friends on my own territory where my families investements are for maintenance used you are expectedly enough thrown out from our hotels and that is what really happened to laura later on, she was only not kicked out because at the time the earlier owner of that hotel made piles
<opennanosaurus>
of scam and terror <picosaurus> at me with their based of their tyran stories, but as he owned 800k to my dad at that moment and have not paid back a single dime even today, he is already done with his terror in that region and his anal shit is disallowed to come to rob and humiliate the investors in that region, none ever made any restrictions of any kind to their cranks and bangers
<opennanosaurus>
at their own territory, all you tried <picosaurus> to spawn at me was entire absurd. I never went on others territory to play bosses there, and ever since indrek is removed from management i no longer have to be dumped as homeless, and i won the trial in estonia too already then, this shitbag failed to kill me, and never shows his ugly face near me again with many shitbags alike. Now
<opennanosaurus>
you can have whatever resources you earned i am not the <picosaurus> one to tell you how things have to be done. What i said to Lyude even asked, if he now understands how all features of GUD can be accomplished from higher HDMI specifications, yes using the encoding i posted. I can post the patch cause idea wise this is super idea to have usb display management routings, this is very
<opennanosaurus>
practically useful thing. For an example even if the computer is off or bricked at <picosaurus> the displays host side, it would be wonderful to use it as usb display still, i came up with the same conclusion that i wanted to develop something like it, today i have all the equipment to test and carry that out on so many pieces of hardwares. I experimented with uart controllers for this
<opennanosaurus>
sake too, i have the spi ones etc. So if Lyude wants to use my compression, i said in any form fw <picosaurus> based or open source my permission was given to anyone who could understand what i developed.
u-amarsh04 has joined #dri-devel
opennanosaurus has quit [Remote host closed the connection]
kzd has joined #dri-devel
<pinchartl>
sima: does that preclude DMA'ing the histogram data to the buffer then ? isn't that a problem ?
<sima>
well if you dma into it, then maybe a gem_bo is the better thing
<pinchartl>
if the histogram is large-ish, I'd expect the hardware to have DMA support, so it would be good to design the API in that way
<pinchartl>
could be a GEM BO, or even a framebuffer. we likely don't need multi-plane support, but it could still be nice to standardize FB as being the object passed through KMS atomic commits, instead of passing GEM BOs (or do we already use GEM BOs that way?)
<sima>
nah it's all drm_fb
<sima>
gem_bo are not great because for many drivers they're wc, and that's absolutely not what you want for readback to the cpu
<sima>
and so we'd have random non-wc gem_bo in there if we do this, which could lead to all kinds of surprises
<sima>
like we couldn't reject those at prime import time or addfb time anymore
<sima>
unless we add a pile of special cases and flags
<sima>
pinchartl, I guess using a drm_fb and allowing memfd backed drm_fb might work
<sima>
and then drivers need to check that they only allow the memfd stuff on histogram formats
<sima>
still feels yucky to no end
<stsquad>
if I want to track all the allocated buffer objects by their userspace address where would be the best place to put a tracepoint?
<pinchartl>
but memfd-backed drm_fb wouldn't allow DMA
feaneron has quit [Quit: feaneron]
haaninjo has joined #dri-devel
Grzesiek11 has left #dri-devel [WeeChat 4.4.3]
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
<sima>
pinchartl, they're separate use-cases
<sima>
depending upon what your hw can do
<sima>
stsquad, drm_gem_create_mmap_offset() as a one-shot maybe? and then use mmap() tracepoints to figure out where it landed
<sima>
it's a bit indirection, so you need to piece it together with post processing
<sima>
or maybe don't even bother with one-shot, if userspace calls this multiple times it's kinda broken anyway, no point making this more complicated
<sima>
stsquad, might also have some other missing tracepoints for just basic gem buffers, not sure about that
<stsquad>
sima grepping seems to imply that ttm buffers share the gem buffer tracking data underneath - so I guess tt_bo->base->vma_node->drm_mm_node->start?
<sima>
yeah, they should probably all end up in the same helper function I pasted
<sima>
maybe not vmwgfx, but that's super special anyway
<sima>
otoh I think even vmwgfx isn't that special anymore
* stsquad
looks at drm_trace.h
<sima>
I just don't want to have more driver specific tracepoints for stuff like this where we managed to unify it pretty well
<stsquad>
sima this is only for my internal debugging, just trying to keep it neater than a bunch of kprintfs and so I can turn them on and off again ;-)
<sima>
ideal world and all that ofc
<sima>
stsquad, ah, well I can still hope that more good tracing infra is being built on upstream and shared across driver teams and users :-)
<sima>
pepp, ^^ maybe of interest to you too
<stsquad>
I can certainly post my tree status for reference once I've understood whats going on - this is working around broken PCI anyway
sguddati has joined #dri-devel
kts has joined #dri-devel
guludo has quit [Ping timeout: 480 seconds]
<pinchartl>
sima: as long as the API is based on a drm_fb, then it can be backed by GEM BOs, memfd or something else
hansg has quit [Quit: Leaving]
<sima>
alyssa, just noticed the apple touch bar driver got a bit stuck, I guess you need to resurrect drm-misc commit rights
<sima>
and figure out with bentiss how to handle the cross tree aspect
feaneron has joined #dri-devel
<alyssa>
sima: uhhh alright
frieder has joined #dri-devel
<sima>
alyssa, maybe also coordinate with drm-misc maintainers here depending if you need a topic branch, but usually we try to avoid these
<alyssa>
i'm not really sure who to pin gabout what here
<alyssa>
feels like I'm jumping into the deep end, lol
<sima>
yeah
<sima>
since it's a patch set spanning hid and drm you get three options a) land in hid through bentiss, some drm maintainer acks b) in drm-misc, bentiss acks c) topic branch (drm-misc maintainers can wrangle that for you) and merge into both
<sima>
and drm-misc maintainers are tzimmermann mripard and mlankhorst here
<sima>
a or b preferred since less work
bolson has joined #dri-devel
<alyssa>
sima: I'm not sure I see the need for the complexity here
<tzimmermann>
alyssa, sima, for a simple driver with little dependencies, you'd have my ack to merged it through hid
<alyssa>
the touchbar support is 2 separate series
<alyssa>
1 is a DRM driver for the display, 2 is a HID driver for the touchscreen
<tzimmermann>
although drm moves faster than hid; so merging through drm might be easier
<chaos_princess>
yea, there is no need to merge it all at the same time, just merge it at all somehow
<jannau>
I'm not aware of functional dependencies between touchscreen and display so merging them independently shouldn't be a problem
<alyssa>
merging the DRM driver through drm-misc and the input through HID seems simplest
<tzimmermann>
sounds good
<alyssa>
I can try to figure out how to use dim enough to push the DRM side
<sima>
ah yeah if there's no functional dependency then even easier
Duke`` has joined #dri-devel
<jannau>
what's maybe missing are hints to link touchscreen and display. user space currently knows which devices to use which is not much of an issue if there are just a handful devices (was going to say 2 but then remembered that intel macbooks with tiouchbar exists)
yrlf has quit [Ping timeout: 480 seconds]
warpme has quit []
<sima>
jannau, sysfs links are usually used for that
frieder has quit [Remote host closed the connection]
davispuh has joined #dri-devel
yrlf has joined #dri-devel
sguddati has quit [Ping timeout: 480 seconds]
sguddati has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<sima>
mripard, bridge state stuff looks good up to the added pointers in bridge states, from there I'm not entirely sure
<sima>
dropped some comments and big thanks dmitry for reviewing almost all of it
<sima>
(yeah forgot the right nick just now)
<sima>
(does irc have a search to find nicks by name)
<mripard>
lumag: ^
<mripard>
sima: thanks :)
ybogdano has quit [Remote host closed the connection]
<sima>
dakr, Lyude, karolherbst kinda no bw to type a nice mail to karol's resignation letter, so just thanks for the work, understanding for quitting and an ack here
<sima>
and I guess one of you three lands this through drm-misc
<dakr>
sima, my plan was to pick it up, once I got an ACK from Steven or Masami to take it through drm-misc.
<sima>
dakr, sounds good
<colinmarc>
<colinmarc> "(are syncobjs on-topic here..." <- user error 😓
ddavenport__ has joined #dri-devel
guludo has joined #dri-devel
ddavenport_ has quit [Ping timeout: 480 seconds]
mripard_ has joined #dri-devel
mripard has quit [Ping timeout: 480 seconds]
epoch101 has quit []
<sima>
colinmarc, yeah
fab has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
preliminarywalkover has joined #dri-devel
fab has joined #dri-devel
fab is now known as Guest9400
<preliminarywalkover>
Are we going forward with my design instead :D? Yeah doubtful. Karol's tasks were pretty even very complex in fact but in this todays world, not even smallest chips need anything more than opencl 1.2 paradigm. Same goes to power usage like scaling the power up of the gpu etc. He chose or was given tasks that nobody needs, the community has always been harch though, still a pitty
<preliminarywalkover>
to hear he had burned out.
sguddati has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
preliminarywalkover has quit [Remote host closed the connection]
u-amarsh04 has quit []
phasta has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
epoch101 has joined #dri-devel
mripard has joined #dri-devel
mripard_ has quit [Ping timeout: 480 seconds]
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
coldfeet has joined #dri-devel
<zf>
<pendingchaos> zf: try also doing RADV_DEBUG=nocache with spirv or preoptir < it doesn't seem to have helped :-(
dsimic is now known as Guest9401
dsimic has joined #dri-devel
Guest9401 has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
iive has joined #dri-devel
<zf>
there's not some other cache I need to disable, is there?
mi6x3m has joined #dri-devel
<mi6x3m>
hey, can someone tell me how vk_Result_to_str is generated? I get an undefined ref for it
<zf>
MESA_SHADER_CACHE_DISABLE=true doesn't seem to have an effect either
jkrzyszt has quit [Ping timeout: 480 seconds]
coldfeet has quit [Quit: Lost terminal]
<sima>
emersion, pq enjoy
coldfeet has joined #dri-devel
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
<pinchartl>
mripard: sorry about that. I'm still grateful for the result :)
<DragoonAethis>
FYI: The Intel kernel CI will soon start requiring emails to be allowlisted for CI to proceed with your patches (you'll get 'LGCI.VerificationFailed' in Patchwork if not allowlisted). While we have most common company domains allowlisted, your private addresses might not be, so PM me with your email address to add to the list if needed. Sorry for the extra annoyance :/
ybogdano has joined #dri-devel
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
coldfeet has quit [Quit: Lost terminal]
agd5f_ has joined #dri-devel
agd5f_ has quit []
agd5f_ has joined #dri-devel
jsa1 has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
<DemiMarie>
pinchartl: sorry for the off-topic, but how common is UVC vs IPU in laptops nowadays? I'm trying to figure out if the lack of IPU entries in Qubes OS HCL reports is selection bias.
agd5f_ has quit []
agd5f has joined #dri-devel
<pinchartl>
DemiMarie: I don't have numbers, but I'd expect UVC >> IPU
<pinchartl>
if you find a reliable source of data, I'm interested
<FL4SHK[m]>
what are UVC and IPU?
<DemiMarie>
pinchartl: That's good to know. Do you know what caused IPU to be a flop?
mi6x3m has quit [Ping timeout: 480 seconds]
<DemiMarie>
FL4SHK: USB Video Class vs Image Processing Unut
<FL4SHK[m]>
hmm okay
<FL4SHK[m]>
So like, for the GPU?
<pinchartl>
FL4SHK[m]: USB webcam vs. raw sensor connected to an in-SoC ISP
<DemiMarie>
Intel's Image Processing Units have had poor Linux support.
<FL4SHK[m]>
ahhhh
<FL4SHK[m]>
gotcha
<FL4SHK[m]>
Interesting, usually Intel is pretty good about the Linux support
<pinchartl>
historically webcams integrated in laptops were just USB devices, exactly like an external USB webcam
<FL4SHK[m]>
oh
<FL4SHK[m]>
huh
<pinchartl>
but for a few years now, some vendors have tried to use a raw camera sensor connected to the CPU chip using MIPI CSI-2, with image processing in the chip using a dedicated image signal processor
<DemiMarie>
One of the reasons I asked is that a USB GPIO expander is going to be a nightmare in Qubes OS, as the VM with the USB controllers doesn't have access to ACPI tables and visa versa.
<pinchartl>
IPU is the Intel name for that ISP
<pinchartl>
DemiMarie: as for IPU being a "flop", I'm not sure I'd put it that way, but lack of care for Linux is certainly part of the reasons why it's not universally loved
<DemiMarie>
It is much simpler if hardware where ACPI references USB is rare enough to ignore.
<pinchartl>
it was designed for windows initially, Linux support was retro-fitted
<pinchartl>
as for USB GPIO expanders
<pinchartl>
I expect you'll see more of them
<pinchartl>
on machines with an IPU
<DemiMarie>
Is this because it saves expensive CPU/PCH GPIOs?
<DemiMarie>
Is this on a dedicated PCI USB controller or is it the same USB as everything else?
gouchi has joined #dri-devel
ybogdano has joined #dri-devel
<DemiMarie>
pinchartl: Is Intel not being willing to provide open userspace the main problem, or would it be a nightmare even if everything was open?
<pinchartl>
if things were open, we'd be fine
<pinchartl>
it would require a recent Linux desktop environment, with applications accessing the camera through pipewire, but the building blocks exist
<DemiMarie>
I wonder if Intel licensed the IP from someone and doesn't have the rights to open things.
<pinchartl>
(there would then be complains about pipewire not exposing some of the camera controls, that's business as usual, development is quite active there)
<pinchartl>
why they don't want to provide information is for them to explain
<pinchartl>
my main concern at the moment is that they're not saying what they're willing to open
<DemiMarie>
Also the need for per-model tuning (which is expensive if I understand correctly) means that Linux could never be a first-class citizen anyway.
<DemiMarie>
Unless I am missing something.
mehdi-djait3397165695212282475 has quit []
apinheiro has quit [Ping timeout: 480 seconds]
DJVulkan has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
gouchi has quit [Quit: Quitte]
DJVulkan has quit []
Guest9400 has quit [Remote host closed the connection]
fab has joined #dri-devel
apinheiro has joined #dri-devel
nowrep has quit [Quit: WeeChat 4.3.4]
nowrep has joined #dri-devel
nerdopolis_ has joined #dri-devel
nerdopolis is now known as Guest9409
nerdopolis_ is now known as nerdopolis
Guest9409 has quit [Read error: Connection reset by peer]
<zf>
oh okay, so those options don't do anything unless RADV_DEBUG also includes "shaders", that's a little obscure :-/
fab has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
mvlad has quit [Remote host closed the connection]
Anorelsan has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Anorelsan has quit [Read error: Connection reset by peer]
haaninjo has quit [Quit: Ex-Chat]
Anorelsan has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
<zf>
nir_lower_global_vars_to_local() seems to be turning my input varying into a "function_temp", whereupon it's subsequently replaced with "undefined" since it's never written
<zf>
that... doesn't seem right? but also seems like it should be breaking pretty much every shader ever, so I must be missing something