<Siddh[m]>
mairacanal @mairacanal:matrix.org: How much familiar were you with the drm / gpu codebase when you started work on it? Also, what is the implicitly expected level of familiarity with GPU code, kernel, and/or testing in general for someone to consider applying in the first place?
heat has joined #dri-devel
danvet has joined #dri-devel
kts has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
fab has quit [Quit: fab]
bgs has quit [Remote host closed the connection]
jfalempe has joined #dri-devel
dcz_ has joined #dri-devel
kts has quit [Quit: Leaving]
kts has joined #dri-devel
rasterman has joined #dri-devel
tursulin has joined #dri-devel
noord has quit [Quit: bye]
fab has joined #dri-devel
linusw has joined #dri-devel
jkrzyszt has joined #dri-devel
rgallaispou has joined #dri-devel
noord has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
glennk has quit [Remote host closed the connection]
glennk has joined #dri-devel
tzimmermann has joined #dri-devel
swalker__ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest999
swalker__ has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
lemonzest has joined #dri-devel
heat_ has joined #dri-devel
bluepenquin has quit [Server closed connection]
heat has quit [Read error: No route to host]
bluepenquin has joined #dri-devel
bluepenquin is now known as Guest1000
MajorBiscuit has joined #dri-devel
Guest1000 is now known as bluepenquin
apinheiro has joined #dri-devel
jeeeun8413 has quit [Read error: Connection reset by peer]
jeeeun8413 has joined #dri-devel
pcercuei has joined #dri-devel
srslypascal has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
Danct12 has joined #dri-devel
frieder has quit [Quit: Leaving]
frieder has joined #dri-devel
Danct12 has quit []
Danct12 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
JohnnyonF has joined #dri-devel
rasterman has joined #dri-devel
Cyrinux has quit [Server closed connection]
Cyrinux has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<repetitivestrain>
how do ``variable refresh'' monitors work in DRM? i don't see any documentation
<repetitivestrain>
or rather KMS
<repetitivestrain>
say a flip is queued for sequence foo, how does the driver determine whether or not vrr should work
<repetitivestrain>
i mean, when the flip actually happens?
<repetitivestrain>
or is it just ``fast modesetting'', where you specify a mode with the refresh rate you want and the mode is set without a 500ms delay+blanking the screen
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Venemo has quit [Server closed connection]
Venemo_ has joined #dri-devel
glehmann has quit [Server closed connection]
glehmann_ has joined #dri-devel
Nyaa has joined #dri-devel
<repetitivestrain>
also, is there a uint32_t that can never be a drm prop_id?
<repetitivestrain>
like -1 or 0
<repetitivestrain>
i think i've seen code that assumes 0 can never be a prop_id but am not sure if that's a correct assumption
OftenTimeConsuming has quit [Remote host closed the connection]
devilhorns has quit []
OftenTimeConsuming has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
Akari has quit [Quit: segmentation fault (core dumped)]
<glennk>
g5 mac, r300, any code archaeologists in here?
<Nyaa>
lol
<DavidHeidelberg[m]>
gawin: ^
egbert has quit [Server closed connection]
egbert has joined #dri-devel
yuq825 has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, i want to merge the mipi-dbi patchset if you don't have further comments
<javierm>
tzimmermann: Go for it. Tested as mentioned, everything works correctly but I don't think that have enough knowledge to do a review, and Noralf already did
<tzimmermann>
ok, thanks
<javierm>
tzimmermann: yw
<tzimmermann>
javierm, BTW did you follow the review discussion?
<tzimmermann>
i was asking noralf why mipi-dpi often uses GEM DMA helpers
<tzimmermann>
instead of SHMEM
<javierm>
tzimmermann: not in detail because noralf was already doing review
<javierm>
tzimmermann: but in general I think that are many assumptions in mipi-dbi and the drivers using it in general, that are made for the rpi
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
<javierm>
for example, the need for CMA, the SPI bus bits-per-word, etc
<tzimmermann>
javierm, it crossed my mind that SHMEM requires MMU support. and those displays might often be connected to non-mmu systems. is that something that could apply to the solomon driver as well? would that be a good reason to convert the driver to DMA helpers?
<javierm>
tzimmermann: hmm, good question. I've never owned a non-MMU board that supports Linux
<javierm>
I know that at least some based on Cortex-M are supported but never got my hand on one of these
<tzimmermann>
me neither and i don't have much insight into the ecosystem around arm cpus
<tzimmermann>
and the inofficial builds could be in any state
heat has quit [Remote host closed the connection]
<Nyaa>
javierm, ye but the c3 module has a native risc-v core, no need to emulate
heat has joined #dri-devel
<gawin>
Nyaa: gonna be answering in gitlab topic (easier to follow)
<Nyaa>
gawin, alright, i'm mostly just waiting for it to compile so not much going on
<javierm>
Nyaa: yes, I got that. I was just pointing out that if one is really willing to run Linux, they could :P
i-garrison has quit [Ping timeout: 480 seconds]
<gawin>
btw has someone got gpu passthrough with emulating another architecture via qemu working?
<javierm>
tzimmermann: right. That's only aarch64, armv7 and armv6. Which really are AFAIK aarch64-a, armv{6,7}-a while for cortex-m you need binaries for a different ISA (i.e: armv7-m)
<karolherbst>
airlied: I now suspect that most of the fails you see are with updated CTS :D I'll update it locally and see if I can fix all those regressions this week
<javierm>
tzimmermann: we definitely don't build that in fedora, but maybe someone takes the source rpms and builds them in a spin
<javierm>
tzimmermann: I guess that in most cases people just build their own rootfs with yocto and whatnot
<tzimmermann>
yeah, i guess
<Nyaa>
gawin, I do not think that's possible if emulating an arch different from host, passthrough kind of depends on KVM/IOMMU which only works with a guest off an architecture host can natively run
<Nyaa>
of*
<Nyaa>
I mean, in theory it could be possible to emulate such IOMMU functionality, albeit extremely slowly, and afaik nobody has bothered to try to write code necessary to do that.
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<Nyaa>
To do so, you would need a kernel module that takes over the device and proxies commands back and forth... which may not provide any degree of usable performance.
kts has quit [Quit: Leaving]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
<MrCooper>
glennk: if you don't ask your question(s), you definitely won't get an answer :)
* glennk
passes on to intended target Nyaa
<MrCooper>
repetitivestrain: KMS flips always take effect for the next refresh cycle, there's no way to schedule flips further into the future
<MrCooper>
repetitivestrain: VRR works mostly the same as a fixed-refresh mode for the maximum refresh rate; the main difference is that the end of vertical blank can be delayed until a timeout which corresponds to the minimum refresh rate
i-garrison has joined #dri-devel
<Nyaa>
VRR can even be used over VGA with a few CRT displays because of that
<repetitivestrain>
repetitivestrain: right.. i see how to implement it in my program now. before i proceed: is there anything else special i have to do apart from setting the VRR_ENABLED property to make it work?
<repetitivestrain>
i mean to have flips respect the extended deadline
<repetitivestrain>
oops, MrCooper:
<repetitivestrain>
sorry about that and thanks in advance
<gawin>
uh, i'd be so nice to have. older/unpopular hardware can be so picky in mixing with newer one. for example nforce3 (best chipset for agp) seems currently busted
<gawin>
Nyaa: directly via VGA or with adapter DP to VGA?
<Nyaa>
gawin, directly would work fine if you can coax the driver and gpu into letting you
<MrCooper>
and if the monitor doesn't lose synchronization? :)
jkrzyszt has quit [Remote host closed the connection]
<Nyaa>
yeah, that's why i said "a few CRT displays" there happen to be a few do not care about anything other than start of image
<MrCooper>
interesting, presumably that would result in brightness varying corresponding to the refresh rate though
<Nyaa>
likely, I have not managed to get my CRT to work, mostly because amdgpu will not expose the VRR setting on DVI ports so I can't test
<Nyaa>
No idea whether or not GPU would allow it even if driver did either, it could refuse to enable for same arbitrary reasons driver does not give you the option.
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
<Nyaa>
Should someone wish to try doing so themselves, they would need to make amdgpu provide the option regardless of port type, then set an EDID override that says VRR happens to be supported.
junaid has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
<Nyaa>
Many monitors intended for analogue signals will tolerate fluctuations of at least a few hz in vertical blanking, particularly older ones where perfect timing was not a guarantee and often fluctuated with ambient temperature.
jkrzyszt has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<Nyaa>
A few, however, were designed in such a way where they can handle quite wide margins
bgs has joined #dri-devel
fxkamd has joined #dri-devel
agd5f has joined #dri-devel
JohnnyonF has joined #dri-devel
mal has quit [Server closed connection]
mal has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kallisti5[m] has quit [Server closed connection]
kallisti5[m] has joined #dri-devel
yuq825 has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
mbrost has joined #dri-devel
glehmann_ has quit []
glehmann has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest1025
macromorgan has joined #dri-devel
fab has quit [Quit: fab]
Haaninjo has joined #dri-devel
Lucretia has quit [Read error: Connection reset by peer]
Lucretia has joined #dri-devel
Guest1025 has quit [Ping timeout: 480 seconds]
<karolherbst>
airlied: ahh yeah.. I have 7 fails with iris now :)
jkrzyszt has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
yuq825 has quit []
<karolherbst>
heh.. just one of them is really relevant
<karolherbst>
something changed with the CL_FILTER_LINEAR tests again, oh well
fab has joined #dri-devel
<karolherbst>
airlied: but I don't think that CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE is actually required to support
jkrzyszt has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
gawin has joined #dri-devel
Guest999 has quit [Remote host closed the connection]
heat_ has quit [Read error: Connection reset by peer]
lina has quit [Remote host closed the connection]
heat has joined #dri-devel
Guest1032 has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
frieder has quit [Remote host closed the connection]
mbrost has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
pixelcluster_ has joined #dri-devel
Leopold has joined #dri-devel
pixelcluster has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
djbw has joined #dri-devel
bnieuwenhuizen has quit [Server closed connection]
bnieuwenhuizen has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
agd5f has quit [Read error: Connection reset by peer]
rgallaispou has quit [Read error: Connection reset by peer]
maxzor has quit [Remote host closed the connection]
<airlied>
karolherbst: i cant spot where it says its optional thoigh
maxzor has joined #dri-devel
<airlied>
or a way to know you cant use it
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
Jeremy_Rand_Talos_ has joined #dri-devel
heat_ has quit []
heat has joined #dri-devel
<karolherbst>
airlied: it's not specified as required either
<karolherbst>
see "CL_DEVICE_QUEUE_ON_HOST_PROPERTIES": "The mandated minimum capability is: CL_QUEUE_PROFILING_ENABLE."
<karolherbst>
so yes, CL_DEVICE_QUEUE_ON_HOST_PROPERTIES is the way of fetching it's supported or not
ybogdano has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<jenatali>
Yeah it looked optional to me from my read through the spec
<jenatali>
(I did implement it though, it was easy with my queue design)
jkrzyszt has quit [Remote host closed the connection]
<karolherbst>
yeah.. it's simple to implement for me as well, I just didn't get to it yet :)
<karolherbst>
but for that I'd actually have to implement barriers and markers correctly :)
lcn has quit [Server closed connection]
lcn_ has joined #dri-devel
lcn_ is now known as lcn
pekkari has quit [Quit: Konversation terminated!]
junaid has joined #dri-devel
<airlied>
karolherbst: then probably need to report a CTS bug
<airlied>
since the test clearly fails when it can't set it
ds` has quit [Server closed connection]
ds` has joined #dri-devel
<karolherbst>
yeah..
<jessica_24>
hey emersion, robclark -- working on the v2 for solid fill property rn... irt not having pixel_format as part of the solid_fill property data, wouldn't this cause issue in use cases where there are multiple layers?
<jessica_24>
i.e., in cases where the solid_fill plane is to be blended with other planes in a different format, wouldn't it be less complex if the user could specify the color format of the solid fill plane? Otherwise, we'd have to implement a way for driver to know when the other layers have a different color format and convert the solid_fill plane to the
<jessica_24>
correct format.
<robclark>
jessica_24: IIRC the idea was to call the format uint32_t (or float32?) per component, and have driver convert that into actual hw format
<robclark>
so as long as we use something that doesn't have less precision than what the hw uses, we are ok
<robclark>
ie. it isn't zero copy so no problem doing cpu color conversion for a single pixel ;-)
bgs has quit [Remote host closed the connection]
<emersion>
jessica_24: i'm not sure i understand your concern
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
q66 has quit [Server closed connection]
q66 has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
jani has quit [Server closed connection]
jani has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
Surkow|laptop is now known as Surkow
<jessica_24>
robclark: I agree that the color conversion shouldn't be a problem, but wouldn't we also have to implement a way for driver to track what format other layers (if any) are using on top of doing the color conversion, in cases where we have to blend the layers? IMO it might be more straightforward to have user specify the pixel format (and expect that
<jessica_24>
it matches the format of the other layers) instead
epoll has quit [Ping timeout: 480 seconds]
slattann2 has quit [Ping timeout: 480 seconds]
<jessica_24>
emersion: I'm wondering if the plan to take in just an RGB323232 value for the solid_fill property might require a more complicated solution in the driver when dealing with cases where we have to blend multiple layers (since in that case we'd have to track what format those other layers are using then convert the solid_fill layer to match that
<jessica_24>
format)
<emersion>
jessica_24: i'm not following. are you saying your driver supports only the case where all layers use the same format?
<emersion>
ie, can't blend a plane with RGBA8888 with a plane with RGBA1010102? for instance?
epoll has joined #dri-devel
gouchi has joined #dri-devel
Thymo has quit [Server closed connection]
Thymo has joined #dri-devel
mwalle has quit [Server closed connection]
mwalle has joined #dri-devel
<HdkR>
Is there a way for applications to abuse drm from multiple threads? Is it as simple as multi-threaded GL or something?
<HdkR>
Woke up with the realization that I have a race in some code but I don't have any way to test it
bgs has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
apinheiro has quit [Ping timeout: 480 seconds]
bgs has quit [Remote host closed the connection]
<DavidHeidelberg[m]>
btw. have to ask, any objections against building Debian sid and using it for RISC-V crosscompilation in our CI? :) The image should be fairly stable, no depending HW currently.
fab has quit [Quit: fab]
gawin has joined #dri-devel
mvlad has quit [Remote host closed the connection]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
martijnbraam has quit [Server closed connection]
martijnbraam1 has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
mbrost has quit [Ping timeout: 480 seconds]
<anholt_>
DavidHeidelberg[m]: you can't use sid because sid moves constantly, so container rebuilds are unreliable. so you'd think, well, snapshots.debian.org, except that that site is unusable due to bad ratelimiting.
<DavidHeidelberg[m]>
anholt_: in theory, if we build once a time separate DEBIAN_SID tag, it would be pretty stable? It won't be shared with other stuff, so if it breaks, I'll disable the risc-v build? And it'll break only when sid image gets regenerated, which is now only for risc-v. Could it work that way?
apinheiro has joined #dri-devel
<anholt_>
Sounds like a lot of extra mess. I would -1 that unless there's a strong reason.
rmckeever has joined #dri-devel
off^ has joined #dri-devel
eyearesee has quit [Server closed connection]
eyearesee has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
rasterman has quit [Quit: Gettin' stinky!]
<DavidHeidelberg[m]>
anholt_: and with snapshots with some image caching?