<alyssa>
jekstrand: I think one of the lovely things about NIR -- including common impls of CSE and algebraic opts and especially out-of-SSA -- is that you /don't/ need to be a black belt to use it.
<alyssa>
For lots of archs you can translate NIR literally and call it a day, without understanding almost any compiler theory, and pass gles2 conformance with good enough perf
<alyssa>
The minute the backend has to see derefs or phis or parallel copies, that disappears
appledash has joined #dri-devel
appledash has quit [Remote host closed the connection]
zzoon has joined #dri-devel
ngcortes_ has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
zzoon has left #dri-devel [#dri-devel]
cheater has joined #dri-devel
cheater has quit [Remote host closed the connection]
vivijim has quit [Ping timeout: 481 seconds]
ngcortes_ has quit [Remote host closed the connection]
RAOF has joined #dri-devel
zzoon has joined #dri-devel
Andregrey has joined #dri-devel
Andregrey has quit [Remote host closed the connection]
pnowack has quit [Quit: pnowack]
rasterman has quit []
zzoon has quit []
zzoon has joined #dri-devel
zzoon_ has joined #dri-devel
zzoon has quit []
zzoon_ has quit []
zzoon has joined #dri-devel
zzoon has quit [Quit: Leaving]
zzoon has joined #dri-devel
zzoon has quit [Quit: Leaving]
zzoon has joined #dri-devel
zzoon has quit []
zzoon has joined #dri-devel
zzoon_ has joined #dri-devel
zzoon has quit []
zzoon_ has quit []
zzoon_ has joined #dri-devel
zzoon[m] has left #dri-devel [#dri-devel]
zzoon_ has quit []
zzoon__ has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
zzoon has joined #dri-devel
zzoon has quit []
zzoon2 has joined #dri-devel
zzoon2 is now known as zzoon
adjtm has joined #dri-devel
libv has joined #dri-devel
zzoon[m] has joined #dri-devel
zzoon has quit [Quit: Leaving]
zzoon has joined #dri-devel
zzoon has quit []
libv_ has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 482 seconds]
RAOF has left #dri-devel [#dri-devel]
boistordu_old has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
dt9 has quit [Remote host closed the connection]
dt9 has joined #dri-devel
boistordu has quit [Ping timeout: 480 seconds]
pzanoni has quit [Remote host closed the connection]
pzanoni has joined #dri-devel
rsripada has quit [Remote host closed the connection]
rsripada has joined #dri-devel
mdnavare has quit [Remote host closed the connection]
mdnavare has joined #dri-devel
dolphin has quit [Remote host closed the connection]
dolphin has joined #dri-devel
dt9 has quit [Remote host closed the connection]
dt9 has joined #dri-devel
boxr has joined #dri-devel
boxr has quit [Remote host closed the connection]
illwieckz has quit []
illwieckz has joined #dri-devel
ramaling_ has joined #dri-devel
ramaling has quit [Remote host closed the connection]
pzanoni has quit [Remote host closed the connection]
pzanoni` has joined #dri-devel
mdnavare has quit [Remote host closed the connection]
dolphin has quit [Remote host closed the connection]
mdnavare has joined #dri-devel
dolphin has joined #dri-devel
rsripada has quit [Remote host closed the connection]
rsripada has joined #dri-devel
lemonzest has joined #dri-devel
ramaling_ has quit [Remote host closed the connection]
ramaling has joined #dri-devel
Danct12 has joined #dri-devel
hwabyong has joined #dri-devel
hwabyong has quit [Remote host closed the connection]
rgallaispou1 has joined #dri-devel
rgallaispou2 has joined #dri-devel
rgallaispou1 has quit [Read error: Connection reset by peer]
rgallaispou has quit [Ping timeout: 480 seconds]
swissChili has joined #dri-devel
swissChili has quit [Remote host closed the connection]
shankaru1 has joined #dri-devel
mbrost_ has quit []
mbrost has joined #dri-devel
Duke`` has joined #dri-devel
gpoo has quit [Ping timeout: 480 seconds]
blue__penquin has joined #dri-devel
itoral has joined #dri-devel
sdutt has quit [Remote host closed the connection]
itoral has quit []
itoral has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
pekkari has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
danvet has joined #dri-devel
demonbane has joined #dri-devel
demonbane has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-04 06:50:43)]
csoriano has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
blue__penquin has quit []
blue__penquin has joined #dri-devel
MrCooper_ has joined #dri-devel
pnowack has joined #dri-devel
yk has quit [Remote host closed the connection]
MrCooper has quit [Ping timeout: 480 seconds]
flibit has quit [Ping timeout: 480 seconds]
adjtm has quit [Ping timeout: 481 seconds]
cognemo has joined #dri-devel
cognemo has quit [Remote host closed the connection]
adjtm has joined #dri-devel
pcercuei has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
Peng_4 has joined #dri-devel
Peng_4 has quit [Remote host closed the connection]
MrCooper_ is now known as MrCooper
yk has joined #dri-devel
rasterman has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
thellstrom has quit []
thellstrom has joined #dri-devel
adjtm has quit [Ping timeout: 480 seconds]
sarnex_ has joined #dri-devel
adjtm has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
cef is now known as Guest832
cef has joined #dri-devel
Guest832 has quit [Ping timeout: 480 seconds]
pcercuei_ has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
Anorelsan has joined #dri-devel
adjtm has quit [Ping timeout: 482 seconds]
txenoo has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
pcercuei_ has quit []
pcercuei has joined #dri-devel
itoral_ has joined #dri-devel
itoral has quit [Remote host closed the connection]
adjtm has joined #dri-devel
neonking has joined #dri-devel
gpoo has joined #dri-devel
vivijim has joined #dri-devel
adjtm has quit [Quit: Leaving]
Lightkey has quit [Ping timeout: 480 seconds]
PsyZeus has joined #dri-devel
PsyZeus has quit [autokilled: Suspected spammer. Mail support@oftc.net with questions (2021-06-04 12:18:08)]
Lightkey has joined #dri-devel
CommandPrompt has joined #dri-devel
CommandPrompt has quit [Remote host closed the connection]
itoral_ has quit [Remote host closed the connection]
blue__penquin has quit []
blue__penquin has joined #dri-devel
blue__penquin has quit []
blue__penquin has joined #dri-devel
dinosomething has joined #dri-devel
dinosomething has quit [Remote host closed the connection]
sarnex_ has quit []
sarnex has joined #dri-devel
macromorgan_ has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
<zmike>
mareko: do you know of any apps/games which bind resources across multiple contexts? looking to do some extended testing
jewins has joined #dri-devel
<alyssa>
dschuermann: SSA is hard :'o
* dschuermann
reads backlog
<alyssa>
dschuermann: No backlog to read I'm just trying to understand ACO and ir3 regallocs
<alyssa>
to see how much I can #shamelessly copypaste into bifrost :p
Anorelsan has quit [Quit: Leaving]
<dschuermann>
I'm really thinking if I should do an in-depth talk about RA at XDC.. but I really dislike the decision for a virtual conference all over :/
<alyssa>
heh
hikiko has quit [Remote host closed the connection]
<alyssa>
If I do write an SSA-based RA for Bifrost, I'm seriously considering a "So you want to SSA RA?" blog post for collabora.com
hikiko has joined #dri-devel
tagr has joined #dri-devel
_whitelogger has joined #dri-devel
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
karolherbst has quit []
karolherbst has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
iive has joined #dri-devel
macromorgan_ has quit []
macromorgan has joined #dri-devel
sdutt has joined #dri-devel
shankaru1 has quit []
lemonzest has joined #dri-devel
Aerroon_ has joined #dri-devel
flibitijibibo has joined #dri-devel
Aerroon_ has quit [Remote host closed the connection]
flibitijibibo has quit []
<jekstrand>
dschuermann: If you wanted to refresh your memory, you could convert IBC to SSA and do SSA RA there too! :-P
<pinchartl>
alyssa: I'd be happy to read that blog post, I could learn what SSA RA is :-)
<alyssa>
pinchartl: hihi
flibitijibibo has joined #dri-devel
<dschuermann>
jekstrand: You’re building your first house for your enemy, your second one for your friend and your third one for yourself. so you my friend then? :P
<jekstrand>
WFM
<jekstrand>
And here I thought we were all friends. I guess mareko and bnieuwenhuizen are the enemy, then?
<dschuermann>
don't tell them 🤭
raoel has joined #dri-devel
<alyssa>
:p
raoel has quit [Remote host closed the connection]
<jekstrand>
🤐
<alyssa>
dschuermann: I think the order is swapped, if I did Midgard then Bifrost then AGX
<alyssa>
:-p
<alyssa>
I will leave the current assignment to your imagination
<jekstrand>
Bah... Where did I mess up a reference count?!?
CircuitRCAY has joined #dri-devel
CircuitRCAY has quit [Remote host closed the connection]
<mareko>
zmike: one thing that's been on my mind is moving bind_velems before set_vertex_buffers
<jekstrand>
vsyrjala: I don't see anything obviously wrong with it. Do you have a partial rebuild going wrong?
<zmike>
hm
<alyssa>
mareko: I hope we're not enemies, I've never written a register allocator for you
<jekstrand>
vsyrjala: NVM. Yeah, it's missing an export
<zmike>
I think that makes sense
<jekstrand>
vsyrjala: If you want to send the patch, I'll happily review it.
blue__penquin has quit []
<vsyrjala>
jekstrand: i guess this also means that code was never actually tested
<mareko>
I honestly don't understand these RA jokes :)
<jekstrand>
vsyrjala: Actually, there's a patch on the list. I just CC'd you.
<zmike>
mareko: one thing I've started to wonder lately is why the stride is with the buffer and not the element state?
<zmike>
I guess just for update batching
<mareko>
zmike: it was probably vmware's idea
<zmike>
ah
<zmike>
I might be interested in trying to rejigger that since having them split like this is unbelievably inconvenient
<jekstrand>
zmike: Our HW goes both ways. ¯\_(ツ)_/¯
<alyssa>
zmike: I recall being inconvenienced by this recently, let me try to remember where each of my hw wants it
<zmike>
jekstrand: this is why we're best friends epic-handclasp.jpg
<jekstrand>
Actually, no, it alwasy puts the stride with the buffer
<zmike>
friendship with intel ended. lavapipe is my new best friend.
<jekstrand>
So Vulkan is the inconvenient one for us.
<alyssa>
Mali always wants the stride with the buffer, so Gallium is convenient there
<alyssa>
The real problem with Mali is that we need the buffers themselves aligned to 64 bytes
<jekstrand>
zmike: I think you just got two NAKs for your refactor. :-P
<alyssa>
which Gallium does not guarantee at all
<jekstrand>
alyssa: Ouch
<alyssa>
jekstrand: The hack we do in the backend is to instead bind the buffer as ptr & ~63, so it's aligned
<zmike>
jekstrand: I think that'd mean you have to actually interact with the MRs instead of hot potatoing them around :p
<alyssa>
and then add (ptr & 63) to src_offset
<imirkin>
alyssa: which buffers?
<mareko>
moving the stride to a different structure would be a lot of work, is it worth it? and you also need to ask others because radeonsi doesn't care where the stride is
<alyssa>
imirkin: vertex buffers, and by extension transform feedback
<imirkin>
alyssa: you can definitely require some alignment on some buffers, not 100% sure about VB
<zmike>
I'm pretty far off from even considering how such a thing would work
<jekstrand>
iris and crocus both want it with the buffer. That's two drivers against! :-P
<alyssa>
and getting to mareko 's point, Apple doesn't support any of this so we just stick it all on the VS key and it doesn't matter one lick which CSO it's on
<alyssa>
jekstrand: [insert bicameral joke here]
<zmike>
ordering is a lot more important
<jekstrand>
zmike: Feel free to write a Vulkan extension to move it. :-P
<jekstrand>
Actually..... I think there might be one.
<zmike>
there's already extensions for it, but on some hw using them reduces perf (supposedly)
<zmike>
also dynamic vertex input is apparently v v v hard to implement
<imirkin>
alyssa: yeah, looks like you can enforce alignment on texture/const/image buffers, but not on vertex
<jekstrand>
zmike: I could see the RADV folks not wanting to mess with it.
<zmike>
radv is ahead of anv :p
<mareko>
VBs are element-aligned
<imirkin>
right
<imirkin>
you can't have a 32-bit element with an offset of 1
<imirkin>
but nothing to force e.g. 64
<alyssa>
nod
<alyssa>
and I think that might be a spec thing so the driver hack stays \srug/
<mareko>
we have to lower certain cases of sub-dword alignment, but we do it in the shader, not u_vbuf, so it's fast
<imirkin>
yeah, there's stuff like PIPE_CAP_VERTEX_BUFFER_OFFSET_4BYTE_ALIGNED_ONLY
<imirkin>
and PIPE_CAP_VERTEX_ELEMENT_SRC_OFFSET_4BYTE_ALIGNED_ONLY
<imirkin>
which i believe are instructions to u_vbuf
<mareko>
will nouveau switch to u_vbuf? :)
<imirkin>
why?
<mareko>
one less cap
<imirkin>
but ... novueau doesn't want what u_vbuf does
<imirkin>
nv50 supports direct input of vertex data
<imirkin>
as does most of the nvc0 gen
<mareko>
is it faster than buffers?
<imirkin>
saves uploading the buffer
<imirkin>
(since you're essentially uploading it via cmdstream)
ngcortes has joined #dri-devel
<imirkin>
also edge flags are _really_ dumb on nvidia hw, so actually having the user buffers is better :)
rgallaispou2 has quit [Read error: Connection reset by peer]
<mareko>
so it doesn't save anything, but you have to interleave attribs I supposed, so more overhead than u_vbuf
<alyssa>
what CAP is this?
<mareko>
user vertex buffers
<alyssa>
ah, right
<alyssa>
th
<alyssa>
thanks
<imirkin>
mareko: is there a benchmark you like for this?
<imirkin>
i can run it
<imirkin>
i'm moderately sure no u_vbuf is better than u_vbuf for nouveau
<imirkin>
but it's largely based on approximations in my head
<alyssa>
llvmpipe sets USER_VERTEX_BUFFERS
<mareko>
alyssa: good point
<mareko>
and all hw with emulated vertex shaders
<mareko>
imirkin: I don't have a benchmark, but there is torcs, which is the most legacy GL you can get
<imirkin>
mareko: ok, will check it out.
<mareko>
it also enables alpha test by default and keeps it enabled even if it doesn't do anything, so there is no early Z 100% of the time (alpha test disables early Z)
<imirkin>
don't have it set up right now
<imirkin>
alpha test is unfortunate. leads to some sad fixups on nv50 (unlikely to hit that though -- only alpha test + weird RT format)
ec019 has joined #dri-devel
<alyssa>
I have some unreasonable long commands these days
curvv27 has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
<anholt>
sometimes I wish we baked the CI_JOB_URL for our containers into the container's contents so I could go look up why piglit decided to not build these tests or whatever
enilflah has quit [Ping timeout: 480 seconds]
pastly-antispam has quit [Remote host closed the connection]
anujp has quit [Quit: WeeChat 3.0.1]
rasterman has quit []
reductum has joined #dri-devel
ella-0 has joined #dri-devel
pastly-antispam has joined #dri-devel
reductum has quit []
reductum has joined #dri-devel
<jekstrand>
airlied: Random Q: How's LLVMpipe's YUV support?
* anholt
not sure there's any way to get at yuv with llvmpipe
<jekstrand>
Run a compositor on llvmpipe and run a media player?
<jekstrand>
Getting at YUV is always a pain
<jekstrand>
There should be some piglit tests somewhere but those probably use GBM directly and llvmpipe might not be happy about that.
<anholt>
how do you make a yuv texture?
<alyssa>
import a dmabuf?
<alyssa>
_external?
<alyssa>
I think that's what the piglit does
<alyssa>
robclark: ^^
ngcortes has quit [Remote host closed the connection]
<jekstrand>
Yeah, you make it a dmabuf by hand and then import it
<jekstrand>
idr probably knows. He's been playing in that sandbox recently. :)
<anholt>
I don't know of an llvmpipe path with a drm fd that can dmabuf import.
Daanct12 has joined #dri-devel
<jekstrand>
Well, then that would be problematic. :)
<robclark>
jekstrand: try kmscube, it has a yuv mode (the "1img" one) ?
<robclark>
oh, hmm, it probably does rely on gbm being able to export/import an fd I think
<anholt>
there was some activity recently on making it so you could import user memory as egl images. one could extend the piglit tests using that when available as an alternative to dmabuf-based import.
<jekstrand>
One could make llvmpipe support dma-buf. You can mmap them, after all.
<alyssa>
also, what about.. er, vgem maybe?
<alyssa>
is that still a thing?
<anholt>
mmaping it does apparently require using some cache sync ioctls.
<jekstrand>
Yes, it does. I just documented them. :)
<anholt>
so, yeah. if you were really excited about doing down that path, I think vgem import and mapping the vgem bo would probably be the way to go. but also, I would ask what problem you're really trying to solve at that point.
ngcortes has joined #dri-devel
<airlied>
jekstrand: yeah pretty much non existant afaik, i generally steer away from yuv unless i have a use case
<alyssa>
anholt: Speaking of !11193, did we make any progress on bikeshedding policy around CI uptimes?
Danct12 has quit [Ping timeout: 480 seconds]
<jekstrand>
airlied: Fair enough. I usually do too. :)
<alyssa>
But I yuv silly colour spaces
<anholt>
alyssa: I don't know of any bikeshedding about that
<alyssa>
Maybe that was a dream I had
<alyssa>
Pandemic memory \s/
<jekstrand>
alyssa: Maybe you agreed with the bike shed color, you just had the wrong colorspace. :P
<danvet>
vgem import and then mapping probably doesn't work too well
<danvet>
not even sure we support that
<danvet>
also have fun reading from wc
<anholt>
danvet: wait, so you're saying that vgem is *entirely* useless?
<anholt>
;)
ngcortes has quit [Read error: Connection reset by peer]
<alyssa>
lolol
ngcortes has joined #dri-devel
<jekstrand>
If you mmapped the dma-buf FD and used the DMA_BUF_IOCTL_SYNC around access, I'd hope you wouldn't get WC. That'd be pretty mean.
<alyssa>
speaking of useless gfx drivers, I probably should start work on M1 kernel DRM before I reach gles2 conformance on macOS via shear procrastination :p
ngcortes has quit []
ngcortes has joined #dri-devel
<jekstrand>
alyssa: Vulkan or bust!
<alyssa>
jekstrand: Definitely not touching Vulkan until I have a DRM driver :-p
<jekstrand>
alyssa: Why not? You wouldn't need shader keys. All your VS attribs are part of VkGraphicsPipelineCreateInfo.
<jekstrand>
As is your blend state
<jekstrand>
It's all so much easier
<jekstrand>
And you can let zmike figure out how to cache thigns and make them fast.
* zmike
encounters ptsd from the future for the first time
<alyssa>
lolololol
<alyssa>
zmike: <3
<zmike>
I need a nap
<alyssa>
jekstrand: I figure the first driver written for this hardware will suck
<alyssa>
so might as well waste GL :P
<jekstrand>
alyssa: I can get behind that reasoning. :)
<Sachiel>
pre traumatic stress disorder
<danvet>
anholt, just checked, it does handle import
ngcortes has quit []
<danvet>
but that means it comes with caveats
ngcortes has joined #dri-devel
<zmike>
pre++
<jekstrand>
zmike: Don't you mean ++pre?
<zmike>
jekstrand: you can't review my irc texts when you won't even review my actual patches
<zmike>
that's against the #dri-devel handbook
ngcortes has quit [Read error: Connection reset by peer]
<jekstrand>
zmike: Feel free to make an MR which adds that rule so I can igore it. :)
<zmike>
so #executive
ngcortes has joined #dri-devel
<alyssa>
zmike: Cc me on that patch
* zmike
finds more obscure corner cases where ANV silently explodes
<alyssa>
specifically cc my gmail account so I won't ever read.
<zmike>
email me from that account first so it's in my address book
* zmike
updates spam filters
csoriano has quit [Remote host closed the connection]
demarchi has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
ngcortes has joined #dri-devel
<karolherbst>
sooo.. any drm experts here in regards to checking valid drm modes?
<karolherbst>
I have an... annoying problem
<karolherbst>
so.. nouveau_connector_helper_funcs.mode_valid gets called for all the modes the display provides
<karolherbst>
but.. it's a 12 bpc display and we reject the 4k@60 mode
<karolherbst>
because we assume 12 bpc
<karolherbst>
of course that can be used as 8 bpc anyway
<karolherbst>
and would fit within DP 1.2 limits
<karolherbst>
(HDMI to DP converter used, pixelclock of the mode is 597MHz)
<imirkin>
afaik there's no guarantee about bpc when modesetting
<imirkin>
there's a "max bpc" property which should limit at the high end
<karolherbst>
okay.. so can just use 8 and be done with it?
gouchi has joined #dri-devel
<karolherbst>
well if the display supports it
<karolherbst>
or are lower numbers always supported?
<imirkin>
other drivers, i believe, pick the max supported
<karolherbst>
mhh
<karolherbst>
yeah.. I don't want that :d
<imirkin>
8 is always supported if 12 is supported
<imirkin>
however 8 may not be supported at all, and only 6 is supported.
<karolherbst>
let's assume that a user is generally fine with 8 and if a display supports 8 then use this to check instead?
<imirkin>
that's not what all the other drivers assume, afaik
<karolherbst>
I guess we can rework all of that once HDR support is more.. solid
<imirkin>
the other drivers try to max out bpc, i believe
<karolherbst>
yeah sure..
<imirkin>
(within the constraints)
<karolherbst>
but with the current userspace I rather have a valid 4K@60 mode
<imirkin>
including automatically switching to 4:2:0 as needed
<karolherbst>
than... not
<imirkin>
they mark the 4k@60 mode as valid
<imirkin>
as long as they can support it at some bpc
<karolherbst>
ohh you mean they check on modeset?
<imirkin>
and then pick the max bpc when actually setting it
<karolherbst>
ahh..
danvet has quit [Ping timeout: 480 seconds]
ajax has quit [Ping timeout: 480 seconds]
<karolherbst>
imirkin: okay.. but at least in the display_info I only see a field for maximum bpc
<imirkin>
one could make a pretty reasonable argument that it's pointless to do > 8 bpc unless you have a format that's > 8 bits per chan
<imirkin>
but i don't think such considerations currently come into play
<imirkin>
karolherbst: yeah, you can assume lower bpc are always supported
<imirkin>
(except 6 bpc, which is a special thing)
<karolherbst>
ohh okay
<imirkin>
8bpc doesn't necessarily support 6bpc, for example
gouchi has quit []
<imirkin>
(afaik)
<karolherbst>
okay
<vsyrjala>
6bpc is mandatory for rgb. but not supported for ycbcr at all. 8bpc is the min for ycbcr
<karolherbst>
yeah.. then let's check against 8 bpc instead even if the display supports more
<vsyrjala>
assuming we're talking about dp
<karolherbst>
yeah
<imirkin>
vsyrjala: yes
<imirkin>
karolherbst: we support > 8 bpc formats
<karolherbst>
and? I want my 4k@60 mode :D
<imirkin>
that's fine
<imirkin>
you don't have to burn everything to the ground while fixing it though
<karolherbst>
so what we have to do is to check against 8bpc instead of whatever is max and then when the mode is requested we drop to whatever bpc we actually do support for that mode respecting the max_bpc for that mode
<imirkin>
for the mode_valid thing, use min(8, info.bpc)
<imirkin>
and then when modesetting, do the freq calc using bpc, and then fall back to 8 if it doesn't fit
<karolherbst>
sounds like a plan
<karolherbst>
okay
<imirkin>
vsyrjala: does that sound reasonable?
<imirkin>
in some future where we support yuv 4:2:2 and 4:2:0, that support would also be factored into the mode_valid function
<vsyrjala>
in i915 mode_valid we just check against 8bpc for ycbcr only modes, 6bpc for all other modes
sdutt has quit [Remote host closed the connection]
<karolherbst>
yeah.. but 6bpc looks stupid, doesn't it?
<imirkin>
oh yeah, that makes sense...
<imirkin>
karolherbst: if someone wants it, they can have it?
<karolherbst>
mhh
<imirkin>
vsyrjala: how do you mark a "ycbcr-only mode" btw?
<karolherbst>
I guess we could do it as well
<vsyrjala>
there is drm_mode_is_420_only()
<imirkin>
vsyrjala: oh. i see. based on VIC?
<vsyrjala>
yeah. comes from the edid
<vsyrjala>
there is also drm_mode_is_420_also()
<karolherbst>
yeah.. we don't support 4:2:0 yet anyway
<karolherbst>
so I guess we always do 8 and I leave a comment?
<vsyrjala>
if your modeset code knows to reduce the bpc accodingly that should be ok
<vsyrjala>
or just uses fixed 8bpc always (which is what we do for mst in i915 due to reasons)
<karolherbst>
well.. no
<karolherbst>
it doesn't :)
<karolherbst>
no DSC nor 4:2:2 nor 4:2:0 support at all
<karolherbst>
imirkin: or are there cases where one wants 6 bpc besides that?
<imirkin>
karolherbst: you want 6bpc if your display is 6bpc
<vsyrjala>
oh, and for dp->hdmi you should really account for the limits of the dongle as well
<imirkin>
in that case, that allows dithering to do its job
<imirkin>
if you treat it as 8bpc, then dithering doesn't work
<karolherbst>
ahh
<karolherbst>
mhh
<karolherbst>
imirkin: so.. how to know that we could actually do 6 bpc for that mode?
<imirkin>
like vsyrjala said ... just always assume 6bpc
<imirkin>
and then try to max it out at modeset time
<karolherbst>
ohh
<karolherbst>
now I understand
<imirkin>
(the 8bpc thing will come into play when we support yuv)
<karolherbst>
so if drm_mode_is_420_only is true, we use 8, otherwise 6
<imirkin>
no
<imirkin>
always use 6.
<imirkin>
we don't support 4:2:0 currently.
<imirkin>
or 4:2:2
<imirkin>
if we did, then we'd use 8
<imirkin>
for such modes
<karolherbst>
yeah, but then we might allow a mode we wouldn't be able to use, no?
<karolherbst>
huh?
<imirkin>
i guess if you we hit a is_420_only mode, we should just reject it
<karolherbst>
isn't it the other way around?
<imirkin>
it is not.
<vsyrjala>
the probe helper filters out the 420 only stuff if you haven't set the flag on the connector
<imirkin>
right yeah, i figured there was something like that
<imirkin>
since we've never had that problem beore
<karolherbst>
ohh... mhh, okay
<karolherbst>
okay.. and why does one should check against 8 for ycbcr only modes?
<imirkin>
becuase that's what DP supports
<karolherbst>
ohh, okay
<karolherbst>
mhh
<karolherbst>
ohhh, I get it.. I was thinking about this the wrong way
<imirkin>
according to vsyrjala, DP requires 6bpc for RGB
<imirkin>
i didn't know that, but i trust him :)
<imirkin>
i.e. if you advertise 8 or 10 or 12 bpc, you are still required to support 6
<karolherbst>
yeah.. I was just confused by the fact that you need less data for 4:2:2/4:2:0 modes.. but that's a different thing
<imirkin>
right.
<imirkin>
that's a number-of-pixels, not bits-per-pixel
<karolherbst>
yeah..
<imirkin>
(pixel is the wrong term ... maybe like "point" is better)
<karolherbst>
values per quad?
<imirkin>
for 4:2:0 yes
<imirkin>
for 4:2:2 no
<karolherbst>
mhh
<imirkin>
or maybe "values per quad" is fine actually
<imirkin>
i've always been confused about the terminology
<imirkin>
like why is it 4:2:0 and not 4:1:1 ?
<karolherbst>
mh
<karolherbst>
I think it's more complicated...
<karolherbst>
ahh nvm
Duke`` has quit [Ping timeout: 481 seconds]
<karolherbst>
okay.. now the modesetting part
<karolherbst>
ehh...
<karolherbst>
where is that stuff done?
<karolherbst>
imirkin: what do you say about handling this inside nouveau_connector_detect_depth?
<karolherbst>
mhh
<karolherbst>
actually.. no
<karolherbst>
that's a stupid idea
<karolherbst>
imirkin: ohh.. we actually don't support 12 anyway
<imirkin>
Lyude added some stuff to clamp to 8
<imirkin>
temporarily
<karolherbst>
or uhm..
<karolherbst>
well
<karolherbst>
check nv50_pior_atomic_enable e.g.
<imirkin>
pior is ancient
<karolherbst>
ahh
<imirkin>
that's only on like nva0
<karolherbst>
but it has this default: asyh->or.depth = NV837D_PIOR_SET_CONTROL_PIXEL_DEPTH_DEFAULT; break; line
<imirkin>
and some dude's laptop
<karolherbst>
which would get triggered on 12
<imirkin>
yeah
<imirkin>
that's fine
<imirkin>
don't worry about it
<karolherbst>
okay
<imirkin>
pior is weird
<imirkin>
i mean -- there's a problem here
<karolherbst>
nv50_dp_bpc_to_depth :)
<imirkin>
basically we don't clamp on capabilities
<karolherbst>
that's probably wrong?
<imirkin>
so like if you have an older GPU that only supports 8bpc
<karolherbst>
uses the same for 10 and default
<imirkin>
and you try to do 10bpc because the monitor supports it
<imirkin>
then ka-boom
<imirkin>
we don't clamp down on stuff like that very well
<imirkin>
but pior is squarely nv50-only
<karolherbst>
sure..
<imirkin>
we ran into some issue with someone hooking up a super-new screen to a super-old gpu
<karolherbst>
I am still very unsure how the code flow is in regards to setting a new mode :/
idr has quit [Ping timeout: 480 seconds]
<karolherbst>
imirkin: what was the difference between pior and sor?
<karolherbst>
ehh
<karolherbst>
...
<karolherbst>
we just had this :D
Prf_Jakob has joined #dri-devel
neonking has quit [Remote host closed the connection]
<Prf_Jakob>
Howdy o/ I assume writing to a VkSwapchain given VkImageView from a compute shader via IMAGE_STORAGE is in general very not supported?
<jekstrand>
It's supported... ish.
<Prf_Jakob>
Oh?
<Prf_Jakob>
Intel only?
<jekstrand>
I think most Vulkan drivers can do it.
<Prf_Jakob>
Ah cool
<jekstrand>
The sticky bit is that, technically, BGRA isn't a "standard" storage image format.
<Prf_Jakob>
Ah hmm
<jekstrand>
On Intel, that means you need a very recent Mesa and you need to set it writeonly in the shader and use the shaderStorageImageWriteWithoutFormat feature.
<jekstrand>
Given all those things, it works fine.
<jekstrand>
Prf_Jakob: If not, a reproducing case and a bug report would be much appreciated.
<Prf_Jakob>
jekstrand: I haven't submitted anything to hardware yet, making sure validation doesn't complain :)
<Prf_Jakob>
But I will, but I'm basically doing with gamescope is doing.
<jekstrand>
The important part is that you set writeonly and then don't use a format enum in the shader.
<jekstrand>
And gamescope works now so, as long as you go down the same path, you should be fine.
<Prf_Jakob>
Noted
<Prf_Jakob>
And thank you very much
<jekstrand>
yw
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
unerlige has joined #dri-devel
unerlige has left #dri-devel [#dri-devel]
unerlige has joined #dri-devel
rawoul has joined #dri-devel
iive has quit []
i-garrison has quit []
jewins has quit [Remote host closed the connection]
<jekstrand>
anholt: alyssa and I were looking at cc13ffffba42e8f8945666d1ab62337165c6d61e. According to the vk-gl-cts issue, a fix was landed in dEQP on Sep 25 2020. Is it still an issue on freedreno or does the CTS change fix it?
<anholt>
jekstrand: fixed in the cts, which we uprevved in c189d385ce306cd776f2e625fa955c1aba01871a
<jekstrand>
anholt: Cool. Thanks!
ngcortes has quit [Ping timeout: 480 seconds]
<anholt>
piglit-runner subtest handling is almost working now.
<alyssa>
nice!
<anholt>
found some surprises where piglit tests report multiple subtests with the same subtest name, and piglit framework is cool with that