<imirkin>
er wait, not a year. nevermind. still, a while.
<imirkin>
(Apr != Aug, despite both starting with a 'A')
<imirkin>
oh, and maybe review the pending OpenGL-Refpages PR's...
thellstrom has joined #dri-devel
thellstrom1 has quit [Remote host closed the connection]
Company has joined #dri-devel
Company has quit [Quit: Leaving]
mclasen has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
kevinx has joined #dri-devel
i-garrison has joined #dri-devel
sdutt_ has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #dri-devel
<jstultz>
robclark: atomic behavior question... some changes in the drm_hwcomposer have seemingly uncovered an issue in the kirin drm driver.. and i wanted to double check assumptions.. basically we previously queued the modesetting and only did the atomic commit once we had a frame to show, so the commit would do the mode set and setup the frame in one go. the recently change switched to doing the modeset immediately via atomic commit,
<jstultz>
before we have the frame. this means we don't have any planes "added" to the pipeline at that time. After the modeset the vblank code starts running, but because some of the display engine logic is in the plane atomic update call, we don't get far enough to enable vblank irqs.. so the vblank core times out and things get in a funky state. so i just wanted to make sure calling the modeset without the plane added was valid.
<jstultz>
robclark: I'm trying to pull some of the plane config logic out so we can call it earlier and the vblank irqs are handled properly..
<robclark>
hmm.. perhaps it should be valid, but I guess more than a few drivers won't handle the case of not having at least one plane covering the entire display.. pretty sure dpu doesn't handle that yet, but I think mdp5 should.. probably not a thing well tested on other drivers
<jstultz>
robclark: right.. that's why i'm sort of worried about the drm_hwc change..
<jstultz>
robclark: the db845c doesn't seem to fall over though.. but we had the kirin and the out of tree kirin960 driver both broke
<robclark>
I guess the question is first, whether there is any hw that can't physically handle that.. and then get igt tests to cover the case.. but in the short term it is a thing you might want to avoid in hwc since I guess at least some drivers can't handle it yet
<jstultz>
robclark: ok, i'll see if we can migrate back. it cleaned up the code to not queue things, but having to fix all the old kernels to make sure our testing trees keep working is a bit daunting
<jstultz>
robclark: thanks for the input
<robclark>
igt tests to cover the cases that hwc would like the kernel to support is a recommended thing.. even if it means that drm_hwc can't rely on that immediately
<jstultz>
robclark: ok. let me sync w/ Roman and we can see about adding it
<robclark>
jstultz: btw, at the expense of burning a bit more ram, a dummy/black fb might be a thing that is a simple workaround in the short term (and maybe a thing that needs to be kept as a quirk if there is some hw that can't deal with not having a full screen primary scanout layer)
<jstultz>
robclark: yea, i'm looking to see if i can generate a quick composition before we set the mode.
frytaped has joined #dri-devel
ngcortes has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
itoral has joined #dri-devel
tzimmermann has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
thellstrom1 has quit []
thellstrom has joined #dri-devel
frytaped has quit [Quit: frytaped]
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
frieder has joined #dri-devel
<kevinx>
Hi guys, how to use dim tool to commit patch for drm-misc? I have get drm-misc commit rights, need to running dim setup at first?
danvet has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
agx_ has quit [Remote host closed the connection]
agx has joined #dri-devel
mlankhorst has joined #dri-devel
ahajda has joined #dri-devel
camus1 has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
<javierm>
it would be great if we can land that so the other patches could be posted on top
<tzimmermann>
javierm, i'll send my a-b on patches 6 to 10. but i can't ack my own patches.
<tzimmermann>
if no one else shows up, mripard often helps out if you review some of his code in exchange :)
<javierm>
tzimmermann: yes, I know. I could r-b yours but I was wondering if someone else needs to review before we could push
<MrCooper>
jstultz robclark: FYI, some drivers can never enable a CRTC without enabling the primary plane as well; the driver should explicitly reject that in atomic_check instead of getting into a bad state though
tursulin has joined #dri-devel
<javierm>
tzimmermann: I'm happy to review others patches in exchange. I have been quiet in the list because I don't feel confident enough to review
<tzimmermann>
danvet sometimes knows patchsets that need review. you can often trade reviews with the authors
<tzimmermann>
javierm, if you have someone to trade reviews, i'll take a look as well.
<javierm>
tzimmermann: great
<tzimmermann>
for your other nomodeset patches, i can do the review if the driver maintainers doesn't reply
<danvet>
I dunno any patchsets that need review right now
itoral has quit [Remote host closed the connection]
* danvet
not yet recovered from vacation backlog
<danvet>
and I likely recover by just marking it all as read :-)
itoral has joined #dri-devel
<tzimmermann>
:D
<tzimmermann>
sounds familiar
_rgallaispou has quit [Remote host closed the connection]
_rgallaispou has joined #dri-devel
itoral has quit [Remote host closed the connection]
rellla has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
rellla has joined #dri-devel
<MrCooper>
jani: FWIW, AFAIK .mailmap doesn't affect the actual Git metadata (you can check e.g. with gitk), but only what's displayed by e.g. git show
<jani>
MrCooper: I just realized that myself. silly me didn't realize I was looking at the commit using tools that *do* translate the info using .mailmap *facepalm*
<jani>
git show --no-use-mailmap
<MrCooper>
yeah, it confused me for some time as well
<jani>
so the question becomes, how should our tools check that there's a Signed-off-by that matches the author?
<dolphin>
git show using .mailmap by default might be the biggest fail of this year so far
<dolphin>
nothing like changing appearance of historical patches based on new .mailmap contents :P
lumag__ has quit [Remote host closed the connection]
lumag__ has joined #dri-devel
<jani>
they've apparently flipped the default a couple of years back
<jani>
anyway, because a future (or historical, for that matter) can screw up the Sob check, we need to work around this in dim by checking the non-translated version
<jani>
if people want to use some authorship, and record it in .mailmap, why do they keep sending patches with something else? I mean it's trivial to send patches from a different address than the authorship From: in the commit message
thellstrom has quit [Remote host closed the connection]
rasterman has joined #dri-devel
<mripard>
jani: I'm not sure the main use case for mailmap is the one you have in mind
<jani>
mripard: I'm not sure what you have in your mind about what I have in my mind :p
<mripard>
my understanding was that it's there to work around people no longer having access to old email addresses
<mripard>
so it's not really about when you contribute, like you said, it's trivial, but it's about 5 years down the road and you left the company ages ago
<jani>
sure, and it's also nice for git shortlogs and whatnot to combine all the commits with different names/addresses to the single person
<jani>
my point was, if they've decided they want to use the single name and address they've recorded in .mailmap, why do they keep sending patches with some other authorship and sob?
<jani>
in any case, dim needs to look at the un-translated info to ensure the patch being applied is internally consistent
Guest230 has joined #dri-devel
Guest230 has quit []
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<MrCooper>
jani: in my case, I use my employer address for Git authorship, but .mailmap in Mesa has my private address, which will hopefully never change
kevinx has quit [Quit: Connection closed for inactivity]
mclasen has joined #dri-devel
flacks has quit [Quit: Quitter]
camus1 has joined #dri-devel
flacks has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
lumag__ has quit [Quit: Leaving]
mszyprow has joined #dri-devel
hch12907 has quit [Quit: Leaving]
hch12907 has joined #dri-devel
kevinx has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
vivijim has joined #dri-devel
kts has joined #dri-devel
<tango_>
hm is there a way to “disable” an egl platform? I only use my nvidia gpu for compute, but it's listed by eglinfo, and in fact this ends up causing issues with firefox
<ajax>
tango_: glvnd's libEGL has some environment variables you can use to force a specific vendor, iirc. not quite what you were asking for but maybe enough
<ajax>
something like __EGL_VENDOR_LIBRARY_FILENAMES pointed at the config file for mesa
<tango_>
ajax: I'll look into that thanks
<tango_>
for the time being it seems that forcin EGL_PLATFORM=gbm allows firefox to start
<tango_>
I guess I should do some testing to report this to firefox too
<danvet>
tzimmermann, dma_buf_map is for void * cpu pointers
<danvet>
willy wants to solve the phys_addr_t problem
<danvet>
iow, they're different
<tzimmermann>
danvet, ok.
<danvet>
there's dma_addr_t, phys_addr_t, void * and void __iomem *, and they're all different things
<danvet>
well the two void * are flavours of each another, hence why we combine them into dma_buf_map
<tzimmermann>
it was just looking similar enough so that dma_buf_map might be helpful
<danvet>
but the other two are completely different address spaces/kinds of addresses
<tzimmermann>
if not, ok
aravind has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
<agd5f>
should fixes go to drm-misc-fixes or drm-misc-next-fixes?
<danvet>
maybe the flowchart needs to be clarified, but you should end up with drm-misc-next-fixes
<agd5f>
danvet, yeah, just wasn't sure when things switched between drm-misc-fixes and drm-misc-next-fixes. I guess it's still drm-misc-next-fixes until -rc1?
<danvet>
(the finicky detail is that during the merge window there's no -rc, so you always answer "no" on that one)
<danvet>
agd5f, yup
<danvet>
but also there's generally a bit a confusion, so maintainers try to catch anything misplaced with extra merges
alyssa has left #dri-devel [#dri-devel]
<tzimmermann>
agf5f, if your bug is already in upstream it's drm-misc-fixes. if your bug is just in drm-misc-next, it's drm-misc-next-fixes
<tzimmermann>
i'd like to get a decision , but it's not moving ATM
<danvet>
ack on the naming bikeshed
<danvet>
drm_dp_helper seams reasonable, and cutting the helpers in half seems like actually something
<danvet>
clears my bar for "is it just silly busywork or real shrinking" :-)
<danvet>
also ack on the dp/ subdir, seems like a reasonable idea too from jani
<danvet>
maybe poke Lyude for an ack too
<danvet>
oh jani actually complained
<tzimmermann>
danvet, yes. that's why i'm asking for a decision. :)
* danvet
shrugs
<tzimmermann>
but drm_dp/drm_dp_*.c is so silly :/
<tzimmermann>
and we don't do that anywhere else
<danvet>
drm/helpers/dp/drm maybe
<danvet>
or drm/core/drm_dp_whatever.c
<danvet>
or
* danvet
dunno
<tzimmermann>
no please, no. everyone i ask comes with a new suggestion. i just want a decision on something
<tzimmermann>
or an a-b on the current patch
<danvet>
ack on dp/
<danvet>
atm we have i2c/ and lib/ (latter a bit underused)
<danvet>
everything else is drivers
<jani>
*sigh*
<tzimmermann>
danvet, thanks
<jani>
danvet: when did you last do a git grep on everything drm excluding drivers?
<jani>
git grep foo drivers/gpu/drm/drm_[*.ch]
<danvet>
jani, maybe I'm biased, but I tend to grep through all the drivers mostly
<tzimmermann>
jani, don't worry. several people suggested a reorganization of the drm code. we can come up with something that works for everyone
<jani>
my sarcasm radar is off
<danvet>
I can also ack drm_dp/, I don't find that too silly
<tzimmermann>
jani, 'git grep foo -- drm_*' works good enough most of the time for me
<danvet>
we dupe the drm_dp in the file anyway
<javierm>
jani: that's why I suggested a drivers/gpu/drm/core/{dp,foo,bar} but agreed with tzimmermann that it's orthogonal to the goal of making the built-in drm code smaller
<javierm>
and could be done as a follow-up series
<tzimmermann>
maxime didn't like drm_dp/ either
<danvet>
so maybe the non-silly compromise is drm_dp/ but then the drm_dp_ cut from filenames?
<danvet>
not sure that's any good
<tzimmermann>
danvet, but that's a differnt style than anything else
<danvet>
it's defo a good bikeshed, which is why I'll just ack about anything
<danvet>
paint the thing pink as long as there's paint on it
<danvet>
well $ping
<danvet>
damn, I meant $pink
<tzimmermann>
danvet, if we don't find a solution, we can also go back to an earlier rev and keep the displayport helpers in driver/gpu/drm/ where they are now
<jani>
I guess I like dp/drm_foo.* better than drm_dp/foo.*
<tzimmermann>
at least it wouldn't make anything worse for anyone
<danvet>
tzimmermann, 'git grep foo -- drm_*' <- how does this work without specifying the full directory?
<danvet>
ah 'git grep foo -- *drm_*[hc]$ works
<danvet>
well without the $
<tzimmermann>
danvet, i usually grep from within drivers/gpu/drm
* danvet
mixing up glob and regex
<danvet>
jani, ^^ acceptable?
<danvet>
tzimmermann, yeah but that still misses the dp/ stuff
<jani>
right, cd drivers/gpu/drm does not help here
<tzimmermann>
well, it takes two or three variations of the call to find everything
<jani>
danvet: how does that expand to subdirs?
<danvet>
git grep is magic?
<danvet>
it even finds everything when you leave out the entire drivers/gpu/drm
<danvet>
just slower
<danvet>
I tested with just drivers/gpu/*drm_*.[hc]
<danvet>
I guess underneath git just treats pathnames as strings, without special meaning for /
<javierm>
I believe is because git-grep has --recursive as default
mszyprow has quit [Ping timeout: 480 seconds]
<javierm>
probably won't work with --no-recursive
<tzimmermann>
coming back to my patchset...
<mripard>
if you use grep or git grep, you should give ripgrep a try
<mripard>
it's *much* faster
<jani>
oh, one other thing with the split. I forget if I mentioned it before. it does change a couple of module params
<jani>
dp_aux_i2c_speed_khz, dp_aux_i2c_transfer_size, drm_dp_cec_unregister_delay move to the new module
mbrost has joined #dri-devel
kevinx has quit [Quit: Connection closed for inactivity]
fxkamd has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
<jenatali>
Hm... any GL experts know if ARB_framebuffer_no_attachments supports fragment shaders executing at sample frequency? I don't see any caveats in specs to say it wouldn't, but for some reason it seems D3D doesn't support this
Duke`` has joined #dri-devel
nchery has joined #dri-devel
<tzimmermann>
jani, i'll add this to the commit message
<imirkin>
jenatali: MSAA no-attachment fb's are _definitely_ allowed (there's an explicit pname for it). i can't think of any reason why sample-rate (presumably that means "per-sample") fragment shading would not be allowed there.
<jenatali>
Yep, that's what I thought
<zmike>
pretty sure there's piglit tests for this
<jenatali>
sigh
<jenatali>
I didn't see them in either the framebuffer_no_attachments spec group or in the sample_shading spec group
<zmike>
I could be wrong
<jenatali>
There are tests in the framebuffer_no_attachments spec group that test MSAA, and the closest thing D3D can do to no-attachment MSAA rendering gets occlusion query results wrong compared to what GL requires
<zmike>
shame
<imirkin>
jenatali: dEQP tends to have a fairly complete thing like that
<jenatali>
And we can't do sample-rate no-attachment shading either. Otherwise that one maps pretty well...
<imirkin>
jenatali: fwiw the sample-shading tests came much earlier than the no-fb-attachment tests (in piglit), so i'd assume the latter could have something related to per-sample shading. but i really doubt that case was considered.
<jenatali>
Yeah, it's not. There's a test in the no-attachment group that does require the sample-shading extension, but only to retrieve sample count in the shader, not to execute at sample frequency
<jenatali>
Yeah, I saw a "pass" result locally and didn't pay attention to the fact that it included a skipped subtest. Thanks
macromorgan is now known as Guest249
macromorgan has joined #dri-devel
Guest249 has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<imirkin>
jenatali: skipped because you're not exposing GL_ARB_sample_shading?
<jenatali>
Yeah, not yet
<imirkin>
ahh ok
<imirkin>
just flip that on, and watch the failures roll in ;)
<imirkin>
esp the ARB_gpu_shader5 additions to it are pretty annoying
<jenatali>
I'm filling out our GLES3.1 and GL4.0 extension list, and each of those extensions are in those separate lists, so I'm looking at which ones we can easily flip on
<jenatali>
Looks like we could support either one I guess, if I hack around the occlusion query detail, but can't support both at the same time
<imirkin>
like ... gl_SampleMask is expected to be a single bit in per-sample mode
<imirkin>
but all the hardware provides coverage masks
<imirkin>
so you have to single it out by hand. and woe be unto you if you're doing e.g. 50% sample rate and the hw supports it. we force that to 100% on nouveau when there's a shader which reads gl_SampleMaskIn
<imirkin>
(since for e.g. 4x msaa, with glMinSampleShading(0.5) it would expect to see 2 bits set. but which 2?)
<imirkin>
(the hw does not provide that info)
<jenatali>
D3D only supports pixel-rate and sample-rate, no percentages
camus1 has quit [Ping timeout: 480 seconds]
<imirkin>
ah. well NVIDIA hw supports the fractional thing.
<imirkin>
dunno about other hw out there.
<imirkin>
AMD has that "advanced" msaa ext which exposes all sorts of things which tbh i've never taken the time to grok
<jenatali>
Yeah looking at our spec, we always have a mask even when running at sample frequency. That's fun
<imirkin>
jenatali: there's a lot of hw like that. there's a nir pass to lower it to be coverage_mask & (1 << sample id)
<jenatali>
Makes sense
<jenatali>
Hm... Looks like sample-frequency no-attachment rendering is actually just undefined behavior, not explicitly disallowed. Something tells me it actually works fine on most/all hardware :P
<imirkin>
jenatali: anyways, might not be an option for you, but sometimes when i hit issues like this i just throw up my arms and say "let's not worry about it"
<imirkin>
jenatali: i don't have concrete evidence, but i'm guessing that it's not _the_ most used feature available in GL...
<jenatali>
:P
<jenatali>
Yeah, but I don't want to claim support for stuff if it's completely broken
<imirkin>
esp given the lengths we have to go to in order to test it... heh
<imirkin>
well ... but it's not _completely_ broken. it works for the majority of the cases.
<imirkin>
advertising ARB_sample_shading without supporting per-sample shading at all would be a wee dodgy
<imirkin>
but missing some weird interaction that's not even explicitly supported by d3d? meh
<jenatali>
Yeah we support sample-rate shading in all cases except the no-attachment case where it's called out as UB
<imirkin>
tbh i'd be a lot more concerned about those failing tex-miplevel-selection tests :p
<jenatali>
Yeah, dunno what's going on there. I haven't seen it locally. The failure mode is a crash / segfault. Probably a WARP bug...
<jenatali>
Got a lot of those. Looks like WARP doesn't do occlusion queries correct for no-attachment rendering. Which is fun...
<imirkin>
afaik that's one of the major use-cases of no-attachment stuff
<imirkin>
along with having super-custom blending/etc and using images to store stuff
JohnnyonFlame has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.3]
frieder has quit [Remote host closed the connection]
oneforall2 has quit [Quit: Leaving]
<jekstrand>
jenatali: I'm pretty sure only NVIDIA supports fractional
<jekstrand>
Intel certainly doesn't
<jenatali>
Good to know
<jekstrand>
jenatali: For no attachments, you can always fake that case with a hidden attachment if you need to.
<jenatali>
Yeah, I really don't want to though :)
<imirkin>
blasphemy!
<jekstrand>
It's a waste of a perfecly good image but if it's just to make an edge case correct...
<jenatali>
Looks like NVIDIA's getting the occlusion query results wrong for MSAA according to D3D's spec, and it seems like WARP is optimizing the no-depth, no-stencil, no-attachment, and no-ssbo/no-image case and dropping the rasterizer invocations
<jekstrand>
woo!
<jekstrand>
IIRC, there might be something we do to force rasterizer invocations in some of those cases.
<imirkin>
in the hw, on nvidia, have to tell it there's 1 RT, but then bind the "null" surface to it
<jekstrand>
I know there are cases where we flip on UsesKill or similar to force stuff to dispatch.
<jekstrand>
imirkin: Yeah, we always have to bind a NULL surface until ICL, I think.
<jekstrand>
ICL added a "null RT" bit to the "RT Write" message
<jekstrand>
So we can just smash that in the shader
<imirkin>
[my knowledge is accurate as-of kepler, of course ... we do the same thing on later gens, but perhaps we don't have to]
camus1 has joined #dri-devel
<jekstrand>
We may have to bind a NULL surface even on ICL. Not sure.
camus has quit [Read error: Connection reset by peer]
<jekstrand>
We had a fun Dota2 stencil bug back in the day that came down to Vulkan not binding NULL surfaces.
<jekstrand>
Took me like 2 weeks to track down.
<zmike>
ANOTHER HINT
<jekstrand>
zmike: Ok, I'll bite. How is that one a hint?
<jekstrand>
And what does it hint at?
<zmike>
talking about valve games
<zmike>
JEKSTRAND COMING HOME TO HATLAND
<jekstrand>
Are there any other kind of games?
<zmike>
no
<zmike>
damn this means I need to blog again today?
<zmike>
I can't even keep up with the rumor mill anymore
* jekstrand
says that with a Switch sitting next to him on the couch
<zmike>
!
<jekstrand>
It's not my fault Valve hasn
<jekstrand>
It's not my fault Valve hasn't sent me a Switch2 yet.
oneforall2 has joined #dri-devel
<zmike>
you didn't buy enough hats
<zmike>
we didn't know you wanted one
* jekstrand
wants one of EVERYTHING
<jekstrand>
Ok, that is so not true. I had to sent my ILK back to Intel and I am NOT sorry. :-P
hch12907 has quit [Ping timeout: 480 seconds]
<imirkin>
jekstrand: that's still my desktop :)
lstrano has joined #dri-devel
Company has joined #dri-devel
<jekstrand>
imirkin: Cool. Then you can fix all the crocus bugs. :)
* jekstrand
just got around to replacing his venerable HSW desktop
<imirkin>
jekstrand: well, no GPU in the ironlake cpu
<jekstrand>
imirkin: No GPU in my new CPU either. :-)
<jekstrand>
The HSW does have a GPU, though.
gouchi has joined #dri-devel
<jekstrand>
zmike: I'm happy to see you spreading rumors to start off each new post. Your latest doesn't have one, though. I was a bit dissapointed.
<jekstrand>
Oh, no, you did. I just missed it. Pixar.
<zmike>
someone has to do real work while you're off
anujp has quit [Ping timeout: 480 seconds]
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
ahajda has quit []
pnowack has joined #dri-devel
ahajda has joined #dri-devel
LexSfX has joined #dri-devel
<jekstrand>
zmike: Hopefully, I'll be able to give a real answer soon. But, until then, keep spreading those rumors!
<zmike>
jekstrand: for real I hope you do manage to find a job, these are all great companies I'm trying to promote you to in my blog
<jekstrand>
Oh, I've had one lined up for more-or-less 2 months now.
<jekstrand>
I just haven't said what it is. :P
<bl4ckb0ne>
i bet its making games with unity
<dcbaker>
libre gpu
<cmarcelo>
wasn't it some wifi thing?
<zmike>
broadcom was so last week
<dcbaker>
turning on the 5G chips in our vaccines?
<jekstrand>
Check zmike's blog for the latest rumors
* dcbaker
prefers to spread his own rumors
<jekstrand>
dcbaker: Damn! You guessed it! I'm working on a new 5G vaccine chip mesh for mining DogeCoin.
<bl4ckb0ne>
mining dogecoin on humans seems rad
<zmike>
not even mining it on doges smh
<zmike>
get a real job
<kisak>
how do you keep the heat down enough to be non-lethal?
<bl4ckb0ne>
heat isnt an issue if you move your human farm to canada
<bnieuwenhuizen>
radiate the heat with hot takes
anujp has joined #dri-devel
<zmike>
hot takes are the only kind of take I know
<jekstrand>
kisak: Didn't you know. That's why some people get a fever after their shot. It's re-calibrating the thermal thresholds.
<jekstrand>
These AI-based human body heat dispersion systems take time to train.
<kisak>
for some reason, I'd be okay with that if you were calculating the ultimate question to the ultimate answer of life, the universe, and everything.
<bnieuwenhuizen>
... only a small step to go until we enter matrix-eque setups
<jekstrand>
That system has been running for millions of years already. My DogeCoin mining will be a tiny subprocess.
<dcbaker>
... this is starting to sound like real crypto bro talk
sdutt has joined #dri-devel
<jekstrand>
If I'm going to be a crypto bro, I'd better start sounding like one, right? :-P
<bnieuwenhuizen>
don't tell me you accepted a job to work on acominer :P
<danvet>
but figured maybe you want to add your paint choice too
<cwabbott>
bnieuwenhuizen: dschuermann: wow, now you can add blockchain to your CV
<Lyude>
I've actually thought about doing this myself for a while danvet so I think I'm fine with it :)
* Lyude
will respond to them
<jekstrand>
bnieuwenhuizen: Uh... neat?
<Lyude>
btw jani/vsyrjala : since I saw that payload start count patch go through, not sure if I mentioned this to you but I'm (-finally-) actively working on moving as much stuff as possible in MST into the atomic state
<cwabbott>
the ACO fanbase continues to surprise me
<Lyude>
haven't quite figured out what to do about radeon yet, but I'm going to ignore that for now and figure it out later
<Ristovski>
Ah, so Jasons new gig was cryptomining software all along!
mattrope has joined #dri-devel
<Kayden>
zmike: ngl I read the backlog and just burst out laughing at the comments this morning, nice work :D
<dschuermann>
ishitatsuyuki: why the mesa fork? does it contain some special sauce?
vivijim has quit [Quit: leaving]
<bnieuwenhuizen>
dschuermann: IIRC support for >4G buffers AFAIU
<dschuermann>
would that be reasonable for upstream?
<bnieuwenhuizen>
there was some stuff to be figured out because our buffer ranges really can only be 4G
camus1 has quit [Remote host closed the connection]
rsripada has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
cphealy has joined #dri-devel
<cphealy>
Is there a way to see the buffer formats supported by a DRM/KMS writeback connector? I ran modetest but don't see anything about the buffer formats supported by the writeback connector.
<imirkin>
cphealy: i don't think writeback is different than anything else
<imirkin>
cphealy: got the modetest output handy?
gawin has quit [Ping timeout: 480 seconds]
<cphealy>
imirkin: for writeback connector, the only line I even see for writeback is the following:
<cphealy>
id crtc type possible crtcs possible clones
<cphealy>
32 74 DSI 0x00000001 0x00000000
<cphealy>
38 0 Virtual 0x00000001 0x00000000
<cphealy>
Should there be other lines with modetest for writeback?
<imirkin>
now i'm starting to doubt whether formats are per connector
<imirkin>
they should be per crtc probably?
<cphealy>
I know with this HW that for sure the HW planes support many more formats than the writeback connector.
<imirkin>
cphealy: i don't _think_ that's directly representable in kms
<cphealy>
The word writeback doesn't even show up with modetest.
<cphealy>
Hmm, let me try with vkms on my PC as it supports writeback. Perhaps that holds a clue.
<imirkin>
you associate planes with crtc's
<imirkin>
and connectors with crtc's
<imirkin>
you could create a bizarro world where you create a writeback crtc
<imirkin>
and planes which can only be used with that crtc
<imirkin>
and make the writeback connector be attached to that crtc
<imirkin>
but otherwise there's no list of formats on a connector that i'm aware of
<vsyrjala>
there should be a prop on the writeback connector for the pixel format
<imirkin>
(as far as kms is concerned, that is. reality may choose to differ)
<imirkin>
vsyrjala: it doesn't pick it up from the attached plane's format?
<vsyrjala>
list of supported pixel foramats that is. the actual format should selected by the attached writeback fb i think
<cphealy>
vkms shows the same lack of writeback connector details with modetest.
<vsyrjala>
planes are input. nothing to do with the output format
<cphealy>
vsyrjala: agreed
<imirkin>
erm ... right
<imirkin>
sorry, i was turned around
<cphealy>
I'm still confused though, is there a way to query for the formats that the writeback connector supports from userspace? If so, am I just facing a limitation with modetest that is not showing it?
<imirkin>
i was thinking of the thing being displayed to be written back out
<anholt>
cphealy: no list exposed afaik, just have to atomic check with the format you want.
<cphealy>
OK, good, this means that I'm at least not missing something... ;-)
<anholt>
wait, no. there's a property on the connector. check the top of drm_writeback_connector_init().
<danvet>
yeah there's pixel formats
<danvet>
but we failed to make it the (format, modifier) one :-/
<anholt>
/o\
<cphealy>
Does this mean that the list of formats supported by writeback connector could be reported by modetest with just userspace code changes?
<zmike>
dcbaker: when is the next branchpoint? tomorrow or next week?
<cphealy>
userspace code changes to modetest that is.
<danvet>
cphealy, yup
<cphealy>
excellent, thank you!
* danvet
hunting for the doc link, any second now
minecrell has joined #dri-devel
<vsyrjala>
does some hardware support tiled writeback?
* danvet
no idea
<danvet>
I guess if none support it it would be nice to clarify that it's untiled
<danvet>
and maybe enforce that for now in the generic fb code
<danvet>
so that we fix this properly, if it ever change
<danvet>
scroll down until you see WRITEBACK_PIXEL_FORMATS
<danvet>
somehow the formatting is upside down from the usual stuff
* danvet
types patch
vivijim has joined #dri-devel
Haaninjo has joined #dri-devel
gawin has joined #dri-devel
<daniels>
cphealy: drm_info would probably tell you
<dcbaker>
zmike: tomorrow
<dcbaker>
at least, that's what the calendar says
<dcbaker>
Obviously, we can move that if there's consensus
<zmike>
I replied on the list
<zmike>
seems like at least a few drivers would benefit from pushing it back a bit
<dcbaker>
which list is that on?
<zmike>
mesa
<zmike>
replying to idr's mail about it
<dcbaker>
ah, I see it. thanks
<dcbaker>
How would people feel about branching on 2022/02/02 instead? I would say push it out two weeks, but I'm not going to be able to make a release on the 24-28th...
<Sachiel>
fine by me
<cphealy>
danvet: I see what you are talking about with WRITEBACK_PIXEL_FORMATS I'm not sure what you mean though by the formatting is upside down from the usual stuff.
<zmike>
sounds pretty reasonable
<jenatali>
Gives me a chance to maybe reach GLES3.1 by then :)
<cmarcelo>
dcbaker: sounds reasonable to me
<cphealy>
daniels: I'll give that a try too, tnx.
<danvet>
cphealy, the overview text should be right after the heading, before the structures and functions
<imirkin>
jenatali: you're not that far from it already, i think, no? you have images, ssbo, and compute
<imirkin>
that's like 99% of GLES3.1
<jenatali>
Yeah, framebuffer_no_attachments is almost done (but CI is going to make it look like it's broken because WARP bugs)
<jenatali>
And then I think just a little bit more
<imirkin>
jenatali: probably _very_ irrelevant to you (even more so than GLES 3.1), but if you have tess going, AEP is reachable too
<jenatali>
AEP? Is that the Android thing?
<imirkin>
yes
<imirkin>
ANDROID_extension_pack_es31a
<jenatali>
Not all that irrelevant TBH
<imirkin>
it's _basically_ ES 3.2
<imirkin>
there are some very minor differences between ES 3.2 and AEP
<imirkin>
(don't ask me what they are. i made that determination, remembered it, and forgot all the source material)
<jenatali>
But yeah, I'm hoping to hook up everything that D3D supports and see how far that gets us, I just really don't like getting stopped at GL3.3/ES3.0 for dumb things when we can support the majority of GL4.x
<pinchartl>
danvet: don't get used to it ;-) still trying my best
<imirkin>
jenatali: yeah, it really should just be a bit of elbow grease to get it all going. supporting new stages is hard. supporting some weird property somewhere - usually easy
<imirkin>
you should have a pretty smooth road to GL 4.6 now that you have tess done
<jenatali>
Yep, once tess lands, that's all the new stages (well, up to mesh/raytracing)
<imirkin>
(and compute)
<jenatali>
Yep, depending how much tolerance we're willing to accept for claiming an extension is supported even if we violate spec when you go near the edges
<jenatali>
And unfortunately images is not going to be universally supported, doing reads requires the D3D driver to report a set of capabilities that are not baseline/universal
<imirkin>
well, e.g. NVIDIA happily advertises GL 3.2+ on all their D3D10 GPUs even though some don't support seamless cubemaps (a required feature of GL 3.2). it's pretty common to cut corners.
<jenatali>
I just really want to be able to get fixed versions of WARP into CI. I hate that we have 800+ failures baselined in the CI results because of bugs that I've already fixed
<imirkin>
jenatali: look at it this way ... WARP cuts corners, and it's the reference renderer. you can too ;)
<jenatali>
Heh
<FLHerne>
jenatali: d3dpipe
<FLHerne>
then deprecate WARP
sdutt has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<zmike>
kinda wish the original env vars had been replaced with stubs to print errors
ahajda has quit []
boistordu has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
<Kayden>
oh ouch
<Kayden>
I don't think I realized that had been dropped
<Kayden>
or renamed rather
<Kayden>
thanks!
<imirkin>
on the bright side, NIR_VALIDATE=true is _way_ faster now...
<imirkin>
[or not... it was on-by-default. nevermind]
<jenatali>
I do like the new print scoping though, that's pretty nice
* Kayden
just tried to shuffle his mesa-dev email around and triggered an OOM killer rampage, hahahahah
sdutt has joined #dri-devel
* Lyude
is about to delete a lot of MST code :)
<jenatali>
Hm... looks like the only thing we're missing from ES3.1 once indirect and framebuffer_no_attachments lands will be the gpu_shader5 extended texture gather
<jenatali>
Oh and maybe gl_HelperInvocation
<HdkR>
Lyude: Is this the time for MST to depart from the world? :D
<Lyude>
HdkR: nah lol, but I'm finally managing to be productive again this year so I've been ripping out legacy MST code to make it less painful to maintain
<Lyude>
and so far it seems like the atomic version of things is going to be a lot simpler :)