macromorgan has quit [Read error: Connection reset by peer]
shashank1202 has joined #dri-devel
thellstrom has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
unsolo has joined #dri-devel
mlankhorst has joined #dri-devel
tursulin has joined #dri-devel
zzag[m] has joined #dri-devel
rasterman has joined #dri-devel
frieder has joined #dri-devel
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
zzag has left #dri-devel [#dri-devel]
lynxeye has joined #dri-devel
rbrune has joined #dri-devel
slattann has quit []
jcristau has quit [Remote host closed the connection]
jcristau has joined #dri-devel
hansg has joined #dri-devel
slattann has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
thellstrom1 has quit []
ppascher has joined #dri-devel
pcercuei has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
<vsyrjala>
airlied: thanks. hopefully there's a silver lining in improving the ci a bit here
gawin has joined #dri-devel
shashank1202 has quit [Quit: Connection closed for inactivity]
<jani>
vsyrjala: yeah, I think I've fallen to this particular trap before
<jani>
vsyrjala: I mean everything else is go, but some machines just fail to boot completely, and the report is "success"
elongbug has joined #dri-devel
tarceri has joined #dri-devel
Ahuj has joined #dri-devel
<gawin>
mareko: in case of UB in `vstream->vap_prog_stream_cntl_ext[i >> 1] |= swizzle << 16;` where swizzle is uint16_t, do you prefer casting to uint32_t or changing type of variable?
<vsyrjala>
jani: yep. oh, looking at the fix, this nuked hsw/bdw too? looks like it did indeed
xexaxo has quit [Ping timeout: 480 seconds]
rbrune has quit [Remote host closed the connection]
<mdnavare>
vsyrjala: Requested crtc is 0x1 for requesting a modeset on crtc 0, but then in bigjoiner case, it sets the crtc mask even for slave crtc and hence affected rtc = 0x3 and it doesnt match, how can we change the requested crtc calculation to make these match?
<mdnavare>
vsyrjala: Here the problem was in drm_atomic_check_only() call where there was a mismatch in requested crtc and affected crtc
<mdnavare>
vsyrjala: You had suggested changing requested crtc calculation but can you help me fill the gaps?
<mdnavare>
vsyrjala: This is how we caculate requested crtc at the beginning: for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
<mdnavare>
requested_crtc |= drm_crtc_mask(crtc);
<mdnavare>
vsyrjala: How can we make sure it accounts for the slave crtc here itself
<mdnavare>
vsyrjala: I have sent the patch again but its still checking for crtc_state->enable in affected crtc calculation, can you suggest how to change the requested crtc calculation to match affected crtc
<vsyrjala>
you just do the crtc_state->enabled check when calculating both masks
<mdnavare>
vsyrjala: But would that be reflected at the beginning when we calculate requested_crtc() ?
<vsyrjala>
yes. uapi state is uapi state. internal junk isn't allowed to change it
<mdnavare>
vsyrjala: Oh so if userspace tries to then request CRTC 1, then it wont be able to
vivijim has joined #dri-devel
<mdnavare>
vsyrjala: Who decides the uapi crtc_state->enable value?
<mdnavare>
vsyrjala: In atomic check when we add the slave crtc then it gets registered?
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
<mdnavare>
vsyrjala: Added that and sent
slattann has joined #dri-devel
<mdnavare>
vsyrjala: Can you review that?
<mdnavare>
vsyrjala: Needed to fix a customer WARN on
<vsyrjala>
did you do the test i suggested?
slattann has quit []
Ahuj has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
<pq>
Company, as you can see, we are still in the middle of "things that do not need any protocol"
<pq>
IOW, no protocol implementation at all in upstream. swick's old branch may be the only thing that does things with protocol.
<pq>
no protocol means the only things clients can produce is sRGB SDR.
<pq>
Company, what do you mean by color management in GTK? What will GTK be doing?
<Company>
ah yes, the "need to first refactor everything" stage I'm in with GTK, too
<pq>
Does GTK aim to support widgets of different color spaces in the same, err, framebuffer?
<Company>
pq: we want to associate a color profile with all input (images etc) and output (wl_surface) and then make sure our compositing can composite all that stuff properly
idr has joined #dri-devel
<pq>
Company, alright, so essentially the same thing as a Wayland compositor will do.
<Company>
so no, not per-widget, but per-wl_surface
<Company>
yes
<pq>
oh, so something like an image would be a sub-surface?
<Company>
no, we don't do that
<pq>
then I do not understand "so no, not per-widget, but per-wl_surface" - what do you mean by that?
<Company>
dialogs, popovers, menus would get a different color profile potentially
<Company>
but we could use it for images, if we wanted to.
<Company>
I just pointed out that it's per-surface to be clear about our API design
<pq>
what is per-surface?
<Company>
as I said: multiple toplevel windows and popups can each have their own color management
<pq>
what do you mean by "have their own color management"?
<Company>
own color profile, pixel format, etc
<pq>
oh color profile, ok
<Company>
i suppose you could use that with 2 windows on 2 monitors
jessica_24 has quit [Quit: Connection closed for inactivity]
<pq>
from Wayland point of view, all you need to do is to ensure that a single wl_surface has exactly one color profile or color space, and everything in that wl_surface in converted correctly to the one profile or space.
<Company>
We're also thinking about switching the compositing to a linear colorspace - ie convert all the inputs from sRGB and back to sRGB for the buffer we send to Wayland
<Company>
right, that's the plan
<pq>
if the users allow you to do that's cool :-)
<pq>
but it's also completely internal to the app/client
<Company>
they do more or less, because GTK4 has its own compositing pipeline
<Company>
so we can just add a check that does a conversion on all the entry points to that pipeline
<pq>
so yeah, Weston is still in the middle of laying out the mechanisms so that gl-renderer can do any convertion that might be necessary.
<Company>
right
<Company>
so it's not yet really useful for my GTK work
<Company>
I basically want it for testing, so that I can see if what I'm doing does indeed work
<pq>
no, but you can have a look at the abstractions
<pq>
Weston can't call into a CMS to convert, I assume that would be too slow - also wants to convert in flight during composition to avoid temporary copies of surfaces.
<halfline>
Plagman, i noticed as i was closing things up that the offset of the images was wrong, so i just hammered out a rotate_90 function you can crib: https://paste.centos.org/view/69fab155
<pq>
I suppose GTK has the same problem, cannot let a CMS convert stuff?
nroberts has joined #dri-devel
<pq>
Company, for you testing, what exactly do you want to see? As in, make use of your monitor's full gamut?
<Company>
pq: I started out with a cairo software implementation that does the srgb <=> linear transition and it's good enough for testing
<Company>
pq: exactly - take some HDR content and see it on my full gamut's monitor
<pq>
oh HDR, not just gamut
<Company>
pq: because that would mean the pipeline does all the steps right - with steps like choosing fp16 over u8 buffers and such that's hard to see with sRGB
<Company>
yeah, both at the same time
<Company>
I just assumed wide gamut color profiles would compress srgb to too few bits
<pq>
Company, my opinion: don't trust your eyes or monitor. Write automated tests to be sure.
<Company>
and I don't want my SDR content to look like back in the days when I had 16bit monitors ;)
<Company>
I don't trust automated tests in 2 ways: They miss stuff, and they're hard to develop against
<pq>
You know the math; write the math the slow way in the test, and check it agrees with what GTK produces.
<pq>
of course they miss *some* stuff, but being sure that at least some special cases are mathematically correct is really valuable.
<pq>
you don't have to do point color tests, you can test whole images that way
<pq>
that's what I do in weston
<Company>
it's not like I don't write tests - but I use tests to check, not to drive my work
<pq>
e.g. there is already a test that ensures blending in light-linear works as expected over a gradient.
<pq>
me too, really
<Company>
pq: do you have figured out a way to write shaders for transforms from icc profiles?
<Company>
I've been looking for some GLSL I can just copy from somewhere, but haven't found any
<pq>
ajax, still very WIP those shaders, but would that matter?
<ajax>
probably best to not add them to shaderdb until they're Right
<pq>
right :-)
<pq>
Company, that's pretty much the abstractions I mentioned earlier: weston'c color.h has a weston_color_transform that we implement in GL-renderer and color-lcms plugins comes up with what to pulg into that.
<pq>
Company, the abstraction is loosely derived from KMS, so that we have a chance of off-loading some stuff to display hardware sometimes.
<Company>
right
<pq>
Company, !640 add the 3D LUT, and we want a matrix alternative at that spot as well.
<Company>
is the idea for fullscreen surfaces that you could just pass that through?
<pq>
Company, there is a proposal to per-plane degamm/CTM/gamma IIRC as well, that would help for windowed things. Yeah, being able to put client buffers into scanout is a goal.
<pq>
proposal for KMS, that is - that I should look into soon
<Company>
i'll keep that in mind then
<pq>
I'm roughly a month behind on dri-devel and linux-media emails.
<Company>
hehe
<Company>
I have no idea who's working on this stuff anyway - apart from you guys
<Company>
we just more or less accidentally stumbled into that whole topic when arguing about font rendering
<pq>
I think there are some intel guys putting HDR into Mutter.
<Company>
and then I insisted that if we do it, we do it properly
<Company>
and here I am
<pq>
good call
idr has quit [Ping timeout: 480 seconds]
<Company>
it seems the whole stack is actively refactoring and taking things apart so it's all in flux atm and we need to watch that we all act in a way that smoothly fits when we put it back together
<Company>
pq: what's your estimate for how long it'll take to get this settled on the Wayland/Weston side?
<Company>
trying to judge if we have lots of time or if it's real soon now
<pq>
I think Wayland will act as a nice separator, so even though the theory is the same on both side, there is not much to entangle otherwise.
<Company>
yeah, but I don't need to add much API to GTK as long as it doesn't work anyway
<pq>
Company, um, working up to how far? I'm not sure if I can get back to the protocol design this year yet.
<pq>
the protocol was kind of left WIP when we wanted to have something to test on and focused on Weston for "a while"
<Company>
GTK/GNOME thinks mostly in 6 month steps for the releases
<pq>
Company, I don't think the Wayland protocol extension is going to change any fundamental way. Clients declare per-surface color properties and the compositor makes the best of it.
<Company>
so the question is March 2022 release or September 2022 or March 2023 or...
<Company>
yeah, and mutter needs to implement it anyway for it to work in Gnome
<pq>
Company, so you could already put all the GTK API apps might want for WCG and HDR, but just a) report that display is always sRGB SDR, and b) convert everything to sRGB SDR.
<Company>
and nobody minds if the protocol changes, we just bump it internally
<Company>
pq: that's not a good selling point for apps though, if I want to convince them to make use of those APIs
<pq>
it's not a selling point, but a point that you don't have to wait with the GTK development.
<gawin>
anholt_: I've found something what can be used for r300's CI, do you perhaps live in eu or know someone in eu who can host old terminal?
<Company>
pq: oh neat - I should definitely put those on my podcast queue
<pq>
Company, there were also Q@A sessions that I'm waiting to be published.
<pq>
now I need to go, till tomorrow \o.
<Company>
hf
pcercuei has quit [Quit: brb]
nchery has joined #dri-devel
<swick>
Company: like pq mentioned, my weston branch has a somewhat working active color management implementation with a protocol that can be used and a single test client
<swick>
if you have a wide gamut display that actually might be a good demo but otherwise it is really unimpressive
<swick>
also no HDR whatsoever
<Company>
I do not have a ide gamut monitor yet - but I'm working on that, too
<Company>
once I do, I guess I have 2 options: either use your branch or just use a Wayland with no color management and do the management client-side
<Company>
ie put the monitor into HDR mode, let the compositor pretend it's sRGB and do everything in GTK for the time being
<Company>
good enough for testing I guess
<Company>
oh, speaking about HDR mode
<swick>
well, you still have to change your compositor to enable HDR and get fp16 scanout
<swick>
and then sRGB content will mess up your whole image if the HDR content is not fullscreen
<Company>
Mesa doesn't advertise fp16 formats in EGL unless you add a driconf config option
<ajax>
which is: dumb
<Company>
can we change that?
<ajax>
you have to ask for float configs explicitly to match them, it's not like there's any risk of an old app accidentally using them
<ajax>
sure
<karolherbst>
is there a nice way of checking if patches already made it upstream on patchwork? I know we had those git hooks for mesa once, but I'd like to check that for all the nouveua patches we have
<Company>
should I file an issue about it somwhere to make that happen?
<Company>
or is me complaining here enough?
<ajax>
sorry, not trying to be flippant there. it's a change i've wanted to make already but it's not top of the todo list for me
<ajax>
if you filed an issue it'd get fixed whenever i or someone else got around to it. if you had a merge request that worked i'd give it to marge to handle
<Company>
I have roughly zero clue about anything Mesa
<pepp>
Company: I think so (or removing the setting completely)
pcercuei has joined #dri-devel
jessica_24 has joined #dri-devel
ybogdano has joined #dri-devel
sagar_ has quit [Ping timeout: 480 seconds]
muhomor has quit [Remote host closed the connection]
muhomor has joined #dri-devel
shashank1202 has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
gdevi has quit [Ping timeout: 480 seconds]
<shashank1202>
Hello everyone, I wanted to know if I could apply for EVoC ?
<shashank1202>
if yes, is there a potential mentor I can contact to?
<jekstrand>
Anyone know off-hand what the minimum alignment of malloc() is on 32-bit?
<jekstrand>
Can I assume 8?
atulu[m] has quit [Ping timeout: 480 seconds]
ServerStatsDiscoverertraveler4 has quit [Ping timeout: 480 seconds]
<nroberts>
“The malloc() and calloc() functions return a pointer to the allocated memory, which is suitably aligned for any built-in type.”
<jekstrand>
Yeah... not nearly as helpful as one would like. :)
<nroberts>
jekstrand, you can surely assume it will be aligned to at least a double = 8
robertmader[m] has quit [Ping timeout: 480 seconds]
<jekstrand>
Right. Doubles.
frieder has quit [Remote host closed the connection]
go4godvin has quit [Ping timeout: 480 seconds]
demarchi has quit [Ping timeout: 480 seconds]
unrelentingtech has quit [Ping timeout: 480 seconds]
_alice has quit [Ping timeout: 480 seconds]
<jenatali>
Pretty sure Windows defines 8 for x86 and 16 for x64 as well
ybogdano has quit [Ping timeout: 480 seconds]
<clever>
jekstrand: `void *memalign(size_t alignment, size_t size);` is also part of libc, and ensures you always get the alignment you want
DrNick has quit [Ping timeout: 480 seconds]
Newbyte has quit [Ping timeout: 480 seconds]
<jekstrand>
jenatali: Cool. Trying to sort out some weird possible interactions between user data pointers and our blob writer in vkGetPipelineCacheData().
<jekstrand>
As long as I can assume 8 everywhere, I think that's good enough.
LaughingMan[m] has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
cmarcelo has quit [Ping timeout: 480 seconds]
Eighth_Doctor has quit [Ping timeout: 480 seconds]
icecream95 has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
cleverca22[m] has quit [Ping timeout: 480 seconds]
<jenatali>
dj-death: FYI I fixed your CL kernel arg parsing problem, in case you didn't see !13177 yet
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
slattann has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
<Plagman>
halfline: thanks a lot! will test, looks like that'll work
mclasen has joined #dri-devel
<Plagman>
i guess changing the c side to also rotate the dimensinos and take the new axis-aligned size would be good so we don't have to do any of that - worth a bug to track it?
<halfline>
yea, we should fix it, so a bug would be good
<halfline>
i'm a little concerned it might be break existing themes, will have to think about that
aura[m] has quit [Ping timeout: 480 seconds]
<halfline>
odd this bug has never come up before, i guess people don't rotate images much...
<halfline>
so maybe it won't break anyone if we fix it
reactormonk[m] has quit [Ping timeout: 480 seconds]
gdevi has joined #dri-devel
iive has joined #dri-devel
slattann has quit []
pendingchaos_ has joined #dri-devel
T_UNIX has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
<dj-death>
jenatali: ah cool, let me see
tintou has quit [Ping timeout: 480 seconds]
hadack has joined #dri-devel
tobiasjakobi has quit [Ping timeout: 480 seconds]
<dj-death>
jenatali: works for me \o/ thanks a bunch
<jenatali>
dj-death: Great :)
pendingchaos_ is now known as pendingchaos
slattann has quit []
PiGLDN[m] has quit [Ping timeout: 480 seconds]
<jenatali>
I'd like to land that sooner rather than later, because I built LLVM 13 now and I don't want to switch back :)
<anholt_>
gawin: not in eu, no.
<dj-death>
jenatali: heh, fine by me
<dj-death>
jenatali: there are no other user atm anyway right?
<jenatali>
Yep, just us so far until your MR lands
xexaxo has quit [Ping timeout: 480 seconds]
<jenatali>
karolherbst: Want me to wait for you to do some more research before I merge? It doesn't impact clover right now
<karolherbst>
ohh, if you want to merge then go ahead
lemonzest has quit [Quit: WeeChat 3.2]
<jenatali>
Thanks :)
<dj-death>
jenatali: now I'm wondering whether the base extensions you listed should be added to the caller's list
<dj-death>
jenatali: it shouldn't prevent you from merging it, but just wondering if the listed is a baseline
<jenatali>
dj-death: I'd be okay with that - want me to cancel the current marge?
<dj-death>
jenatali: nah, I'll just replace the change in my MR
<jenatali>
Sounds good
Dylanger has quit [Ping timeout: 480 seconds]
sagar_ has joined #dri-devel
gouchi has joined #dri-devel
cmarcelo has joined #dri-devel
cmarcelo has quit []
cmarcelo has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
demarchi has joined #dri-devel
xexaxo has joined #dri-devel
demarchi has quit []
demarchi has joined #dri-devel
cmarcelo1 has joined #dri-devel
pnowack has quit [Quit: pnowack]
gnustomp[m] has quit [Ping timeout: 480 seconds]
<ngcortes>
guess it goes without saying but intel mesa ci is back online after the drive replacement on friday :)
<eric_engestrom>
thanks nico!
<eric_engestrom>
btw, quick reminder that the branchpoint for mesa 21.3 is next wednesday (oct 13th); if you have issues or MRs that _need_ to be in there, please add them to this milestone: https://gitlab.freedesktop.org/mesa/mesa/-/milestones/27
<eric_engestrom>
(thanks to whoever created the milestone btw, probably someone working on amd given the issues/mrs added to it)
<ajax>
i think that was me, and that only because someone asked why there wasn't one
<eric_engestrom>
yeah, I forgot, and when I remembered to do it a couple days ago it was there ^^'
adjtm is now known as Guest1810
<eric_engestrom>
anyway thanks :)
adjtm has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<ajax>
np
Guest1810 has quit [Ping timeout: 480 seconds]
<Venemo>
eric_engestrom: yes we added a bunch of stuff to that so we don't forget
lynxeye has quit []
hadack has quit [Remote host closed the connection]
jekstrand[m] has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
HayashiEsme[m] has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
pnowack has joined #dri-devel
lyudess has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
Lyude has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
ybogdano has joined #dri-devel
shashank1202 has quit [Quit: Connection closed for inactivity]
gdevi has quit [Ping timeout: 480 seconds]
<gawin>
is lxde using xrender for accelaration? if yes, then can someone give me link to source code of driver r300 for xrender? thx
<gawin>
I'm witnessing weird bug on r300 (r480): on opengl's apps the textures are sometimes missing on first run, on xrender the textures are missing almost always
idr has joined #dri-devel
atulu[m] has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
<ajax>
anyone brave enough to look at !13179 for me
<Company>
ajax: should you also remove the option from the config file?
<zmike>
ajax: gonna get to it this week for sure 👍
zzoon[m] has quit [Ping timeout: 480 seconds]
<zmike>
prob get MrCooper to give it a look too tho
<jekstrand>
bnieuwenhuizen: Wrote a new pipeline cache in the common code. It's running in Jenkins now. Tomorrow, I'll try moving other drivers to it and we'll see how that goes. :)
<ajax>
Company: yeah probably. i was avoiding doing that because i965 still honors it and we still haven't deleted i965 yet
pnowack has quit [Quit: pnowack]
Duke`` has quit [Ping timeout: 480 seconds]
anholt_ has quit [Quit: Leaving]
ybogdano has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<idr>
ajax: Looking at the other commit messages around f4703f1c1024, I don't see any reason why that config option was ever necessary. Work around possibly buggy apps?
<idr>
I'd delete it from i965 too.
<idr>
Unless maybe it makes the CTS doing something bad...
<ajax>
idr: i'm sure buggy app was the motivation, i'm just not sure it was justified with an actual buggy app
<ajax>
you have to ask for float pixels, it's not like you can get them by accident
<idr>
Yeah, that's what I thought.
anujp has quit [Ping timeout: 480 seconds]
libv_ has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
libv has quit [Ping timeout: 480 seconds]
chivay has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
ybogdano has joined #dri-devel
gouchi has quit [Remote host closed the connection]
anholt has joined #dri-devel
robertmader[m] has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
ServerStatsDiscoverertraveler4 has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
go4godvin has joined #dri-devel
go4godvin is now known as Guest1819
ybogdano has joined #dri-devel
MrCooper has quit [Read error: Connection reset by peer]
MrCooper has joined #dri-devel
Hi-Angel has quit [Ping timeout: 480 seconds]
demarchi1 has joined #dri-devel
fxkamd has quit []
<Venemo>
Can I create a new label on the mesa gitlab for the AMD common code? Not sure if I have the rights to do that
<ajax>
you should be able to
rbrune has quit [Ping timeout: 480 seconds]
<Venemo>
done, thx
unrelentingtech has joined #dri-devel
adjtm is now known as Guest1823
adjtm has joined #dri-devel
Guest1823 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
_alice has joined #dri-devel
pcercuei has quit [Quit: dodo]
ybogdano has quit [Ping timeout: 480 seconds]
tursulin has quit [Remote host closed the connection]
<jekstrand>
bnieuwenhuizen: I looked at a couple other drivers and I'm quite scared at the idea of digging in and trying to figure out how to port them all on my own. :-/
MrCooper__ has joined #dri-devel
MrCooper_ has quit [Remote host closed the connection]