<DavidHeidelberg[m]>
I'm for almost every choice, if there will be choice which will stick for few years and not make people confused :)
fxkamd has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
stuart has quit []
lemonzest has joined #dri-devel
<DavidHeidelberg[m]>
mupuf: busybox doesn't handle zstd. Any idea what to do with that? We distribute the mesa build in zstd for some time and I want to enable it too for *valve* jobs, but cannot decompress.
Kayden has quit [Quit: go home]
<airlied>
jekstrand: okay I left a patch in the MR that fixes the template entries, if you are okay with that I'll squash it
rsjw has left #dri-devel [#dri-devel]
ngcortes has quit [Read error: Connection reset by peer]
elongbug has quit [Read error: Connection reset by peer]
rmckeever has joined #dri-devel
vsyrjala_ has joined #dri-devel
vsyrjala has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
libv has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<Lynne>
airlied: src/vulkan/util/vk_format.c:370, VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 isn't strictly compatible with VK_FORMAT_R16_UNORM
<Lynne>
the bottom bits are described as undefined by the spec
<Lynne>
so it should be VK_FORMAT_R10X6_UNORM_PACK16
cdochufe^ has joined #dri-devel
<jenatali>
That name is an abomination
<airlied>
Lynne: for all our internal handling I think it's fine
<airlied>
but I'll dig in and see
<airlied>
since I don't see any hw support for R10X6 anywhere
<airlied>
but maybe I should map R10X6 to R16 in drivers then
<airlied>
Lynne: fixed it to map to that for now, will have to fix up radv
<Lynne>
I think it would be fine to leave it as R16, assuming you're not aware of any hardware mesa supports that happens to put junk in the LSBs
<Lynne>
I have zero clue why they defined padding in the LSBs for video formats
<Lynne>
from a hardware perspective, having data in the LSBs is benefitial, especially in the case where it's used for reference frames
<Lynne>
as h264 was designed such that 10bit decoding needs 16-bit intermediates if your ref+current frame data is in the LSBs
<Lynne>
rather than 32bits, halving throughput
mbrost has quit [Ping timeout: 480 seconds]
<airlied>
Lynne: i dont think the hw actually cares about the vk format at that level
<airlied>
at least the decode hw doesnt have a lot of format opts
<airlied>
it has some 8/10 bit bits
mbrost has joined #dri-devel
<Lynne>
maybe it's because the 2-plane p010/p012/y210/y212/etc are LSB padded
<Lynne>
so they continued that for the 3-plane formats
<Lynne>
(which is the one I'm wondering about, the 2-plane LSB padding has been ossified since time immemorial by microsoft)
<airlied>
yeah the hw doesn't even have 3 plane options from what I can see
<Lynne>
nvidia's does, I think, for 444, reading our vdpau/nvdec, I'm seeing 3-plane yuv444 rather than 2-plane
<Lynne>
though it could be the driver doing it for some odd reason, like 2-plane 444 not being very popular
<airlied>
yeah I noticed that in their decoder as well
<airlied>
they pretty much demanded the 444 extension to even run at one point
<airlied>
I think I'm pointlessly carrying code for that in radv actually
Kayden has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<airlied>
Lynne: I've refined that commit to convert to R10X6 and convert that to R16_UNORM
<Lynne>
yeah, looks fine
<airlied>
I wonder what V_00A004_GFX10_FORMAT_MM_10_IN_16_UNORM is in the hw
<airlied>
sounds like it might be related
<airlied>
but it's gfx10+
<Lynne>
sounds tiling-related?
<airlied>
agd5f, mareko : what does MM in those?
pallavim__ has joined #dri-devel
pallavim_ has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
<mupuf>
DavidHeidelberg[m]: You mean for tar? It's weird since it is extracted by the mesa test container
<mupuf>
Do you have a failed job I can look at?
<mupuf>
Never mind, I saw your mail
camus1 has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
camus has quit [Read error: Connection reset by peer]
pallavim__ has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
sarnex has quit [Quit: Quit]
sarnex has joined #dri-devel
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
kts has quit [Quit: Leaving]
bgs has joined #dri-devel
camus1 has quit []
camus has joined #dri-devel
cdochufe^ has quit [Remote host closed the connection]
itoral has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Nyaa has joined #dri-devel
fab has joined #dri-devel
libv has joined #dri-devel
bgs has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
macromorgan is now known as Guest939
macromorgan has joined #dri-devel
Guest939 has quit [Ping timeout: 480 seconds]
ahajda has joined #dri-devel
fab has quit [Quit: fab]
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
<airlied>
anholt: is there any cts 1.3.4.0 uprev in progress?
aravind has quit [Ping timeout: 480 seconds]
rmckeever has quit [Quit: Leaving]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
frieder has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
agd5f has quit [Remote host closed the connection]
aravind has joined #dri-devel
kts has joined #dri-devel
rszwicht has joined #dri-devel
rasterman has joined #dri-devel
tursulin has joined #dri-devel
sgruszka has joined #dri-devel
mvlad has joined #dri-devel
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
dcz_ has joined #dri-devel
fab has left #dri-devel [#dri-devel]
fab has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
frankbinns1 has quit []
frankbinns has joined #dri-devel
danvet has joined #dri-devel
MajorBiscuit has joined #dri-devel
jkrzyszt has joined #dri-devel
lynxeye has joined #dri-devel
swalker__ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest945
swalker__ has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
ManDay has joined #dri-devel
<ManDay>
Could someone refresh my mind why Mesa will only provide OpenGL with X11? (and if that premise is wrongly phrased: Why does virtual/opengl depend on mesa[X] on Gentoo?)
alatiera has joined #dri-devel
<ManDay>
I apologize for repeating this questions over the course of years (?) - I actually wrote down the answer to it but lost it in a data crash.
jlawryno has joined #dri-devel
<psykose>
it doesn't depend on x11, you can get libGL libEGL libGLES .. without x, no?
<psykose>
glx and vdpau require it, but not opengl
a1batross has quit [Ping timeout: 480 seconds]
<ManDay>
yes, i think it has something to do with GLX being the only (full) OpenGL header, was that it?
<psykose>
ah, maybe i'm mistaken
<ManDay>
Like I said, I'm not very sure I phrased that question correctly - the only thing that's sure is that OpenGl depends on Mesa w/ X support (on Gentoo)!
dos1 has quit [Quit: Kabum!]
dos1 has joined #dri-devel
<psykose>
i build with -Dplatforms=wayland and no x deps and i didn't get a libGL so maybe it's true :p
<ManDay>
I'm not sure -Dplatforms=wayland is enough to not depend on X11 headers
<MrCooper>
that's because libGL includes GLX APIs
<ManDay>
I also build for pure wayland and I have no libGl (only libglapi, whatever that one is)
<MrCooper>
libOpenGL doesn't require X
<MrCooper>
it sounds like a Gentoo packaging issue
<ManDay>
MrCooper: Yes, I think it's a bit of a confusing set of terms with "OpenGL" not necessarily being libGL etc.
<psykose>
hmm, where does libOpenGL come from
<MrCooper>
GLVND
<psykose>
ah
<psykose>
ok makes sense
<psykose>
thanks
ice9 has joined #dri-devel
dos1 has quit []
<MrCooper>
no worries
junaid has joined #dri-devel
dos1 has joined #dri-devel
<MrCooper>
there is of course the practical issue that the vast majority of apps using OpenGL still use libGL & GLX
<ManDay>
MrCooper: Sorry if that's too much of a Gentoo specific but what would you say is the best possible terminology then? Blender, for example, they say they need "OpenGL" (as opposed to GLES) and the Gentoo ebuild depends on "virtual/opengl", but that in turn depends on Mesa with X support.
<ManDay>
MrCooper: As opposed to? Using libGlVnd?
<MrCooper>
it depends whether blender uses libGL (likely) or libOpenGL
<MrCooper>
both provide the OpenGL API
<ManDay>
So, speculation: The correction could look something like "OpenGl" -> "libGlVnd" instead of "Mesa[x]"?
<MrCooper>
libglvnd is an implementation detail, it's either libGL or libOpenGL
<ManDay>
MrCooper: blender uses glVnd, so that would mean libOpenGL, meaning it would do without mesa[X]?
<MrCooper>
blender doesn't use glvnd directly
<ManDay>
...i'm actually not sure I'm understanding the situation entirely
<MrCooper>
blender uses either libGL or libOpenGL
<MrCooper>
the Debian blender package uses libGL FWIW
<ManDay>
Which version is that? From the related blender bugs I think they must have moved to libOpenGl for pure wayland support like they ought to, since 3.4.1?
<MrCooper>
the Fedora package uses libOpenGL though
<MrCooper>
makes sense, it's 3.3 vs 3.4
kts has quit [Quit: Leaving]
<ManDay>
all right, my grasp of this is still a bit foggy but I think I got the gist - taking it to #gentoo
<ManDay>
thank you very much!
<MrCooper>
so blender 3.4 uses libOpenGL for the OpenGL API, plus libEGL on Wayland, and possibly libGLX on X
<MrCooper>
no worries
<enunes>
eric_engestrom: hi, did you have some chance to look into the egl tests timeout?
<enunes>
one thing I found so far is that if we run only the wayland ones (or worse, change the order and run the wayland tests before the x11 ones), the long list of timeouts is gone...
<enunes>
trying to find some sense in that
pcercuei has joined #dri-devel
junaid has quit [Remote host closed the connection]
jkrzyszt has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
<daniels>
enunes: can you please clean up the Lima runner? -ENOSPC trying to unpack containers
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
enunes: ^ this time it isn't my fault (since yesterday I didn't run any new big pipeline) :D
<enunes>
daniels: I'll take a look - it happened yesterday and it was because new jobs were taking significantly more space
<DavidHeidelberg[m]>
mupuf: for runners in FDO farms it doesn't such a big impact, but it means we don't have to store the file twice (artifacts + s3)
<mupuf>
DavidHeidelberg[m]: I'm all for it, I'm just confused by the code. Let me comment there
<DavidHeidelberg[m]>
mupuf: np, that part was created around 3am; so if there is confusion, it make sense :D
itoral has quit [Remote host closed the connection]
<enunes>
daniels: DavidHeidelberg[m]: should be good now, it was the runner this time not LAVA, docker-free-space did not act for some reason
rszwicht has quit [Read error: Connection reset by peer]
jlawryno has joined #dri-devel
<daniels>
enunes: aha, thanks
jlawryno has quit [Remote host closed the connection]
jlawryno has joined #dri-devel
<daniels>
enunes: appreciate the quick fix :)
<psykose>
DavidHeidelberg[m]: where can you not decompress zstd (i.e. which platform doesn't have the zstd util installable separately while having busybox)
<DemiMarie>
Does the Xe driver map the GuC submission queues into userspace, or does the kernel ensure that only valid commands reach the GuC?
<daniels>
tanty: is there something weird going on with the igalia-rpi network? if you look closely at https://gitlab.freedesktop.org/mesa/mesa/-/jobs/34440806 it takes 14 minutes to go from the artifacts having finished downloading to the board booting, which should only be rsync and nothing else
<daniels>
same thing for every other job in that pipeline
<DavidHeidelberg[m]>
psykose: it just about the container setup, it can be imported as standalone zstd or busybox patches with zstd support
<karolherbst>
ls
<daniels>
enunes: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/34443210 also has a flood of failures to create high-version GL contexts - I wonder if that suggests that a bunch of tests should be moved from xfail to skip?
<psykose>
DavidHeidelberg[m]: you mean, you have a container i.e. dockerfile and one of the build steps is tar xf artifact.zst ?
<psykose>
sure, i would just install zstd for that :)
devilhorns has joined #dri-devel
<psykose>
last i checked busybox there was some abandoned zstd patch a year or so ago, not sure if anyone made any progress
<psykose>
(it is also much easier to install zstd than do weird patching of anything)
devilhorns has quit []
aravind has quit [Remote host closed the connection]
<jenatali>
daniels: Might've been the switch to PowerShell core?
<jenatali>
Dunno, my eyes just skip past it to the stuff that matters
<daniels>
haha
nchery has quit [Read error: Connection reset by peer]
<mairacanal>
danvet: hi! about the debugfs clean-up, I'm trying to work on removing the late register helper by adding support for debugfs files on crtc, connectors, and encoders. I just have a doubt if you meant adding the files to the device minor folder or the kms component folder. Have you had any thoughts about it?
junaid has joined #dri-devel
maxzor has joined #dri-devel
<enunes>
daniels: about the failures to create high GL version, I guess we could try to identify which ones need it and add to skip, just last time I checked it was not just in the lima job so I started wondering if we could have a shared solution
junaid has quit [Remote host closed the connection]
fab has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
<mareko>
airlied: MM=multimedia
gawin has quit [Quit: Konversation terminated!]
junaid has joined #dri-devel
ice99 has joined #dri-devel
kts has joined #dri-devel
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
TheDisruptiveCollective|JoinOu has left #dri-devel [#dri-devel]
ice9 has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
ManDay has quit [Quit: WeeChat 3.6]
ice9 has joined #dri-devel
ice9 has quit []
ice9 has joined #dri-devel
djbw has joined #dri-devel
junaid has quit [Remote host closed the connection]
ice99 has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
Haaninjo has joined #dri-devel
<eric_engestrom>
enunes: no, I haven't looked into it more beyond just "run these tests on my local wayland rpi" where nothing timed out; I think I would need to unroll everything the CI does (env mostly, but also which service runs in which job) and repeat it locally to see where it starts behaving weird
<danvet>
mairacanal, not really, I also don't have a good idea about names
<eric_engestrom>
enunes: your mention that it times out when "running the x11 tests before the wayland ones" -> sounds like we're running both in the same job? in that case maybe we're not cleaning up correctly between the two?
<danvet>
i.e. whether it should be drm_connector_add_debgufs_file
<danvet>
or drm_debugfs_add_connector_file
<danvet>
roll a dice if you can't decide :-)
<danvet>
mairacanal, I think the bigger question is whether we can sneak in more typesafety
<danvet>
so that drivers get a struct drm_connector * pointer instead of void * that they need to cast in their show() callback
<danvet>
but that's more bikeshed ...
<mairacanal>
danvet, I see. So, I guess a similar structure from the current debugfs for the crtc, connector and encoder would be fine, right?
<danvet>
yeah
<danvet>
unfortunately C is not very good at type generic stuff
<danvet>
you could strictly speaking store the right type in seq_file->private
<danvet>
and force cast every function pointer to (show)(seq_file *, void*, void*) from (show)(seq_file*, drm_device*, void*)
<danvet>
but that violates the C standard in a big way
<danvet>
despite that it should work on everything gcc supports :-)
<danvet>
mairacanal, if you feel creative you might be able to instantiate the different variants with cpp, but that tends to end up rather ugly
<enunes>
eric_engestrom: yes we are running both in the same job. lima also hits the same timeouts if I run the tests as in vc4 -- but if I invert the tasks to run wayland egl and then x11 egl, it goes well on both platforms
<danvet>
so I'd just copypaste, since it's really not much code
<mairacanal>
danvet, yeah, I'm creating a couple of macros to avoid copying and pasting a lot
<mairacanal>
thanks for the answer!
<enunes>
eric_engestrom: so I guess it's some shared mesa bug or weston or cts bug (?)
aravind has joined #dri-devel
ybogdano has quit [Read error: Connection reset by peer]
<enunes>
last I checked our VK-GL-CTS version even uses wl_shell rather than xdg_shell , which is something to look into next
<eric_engestrom>
yeah that's been fixed in the cts, it finally uses xdg_shell now (although I have no idea which release has that)
<enunes>
I had the same version as CI built locally so unless it's been bumped in the past week or so, mesa CI is still using wl_shell
<eric_engestrom>
can you check to make sure that x isn't still running (or has pipes/sockets left around or things like that)?
mbrost has joined #dri-devel
<eric_engestrom>
it really feels like missing cleanup after X & before weston
yuq825 has left #dri-devel [#dri-devel]
<enunes>
CI doesn't kill X so I think it's expected it will still be running, things should work anyway I think
<enunes>
unfortunately I can't reproduce it locally either but maybe I can check if bumping VK-GL-CTS to a version supporting xdg_shell has any effect
<eric_engestrom>
sure, worth a shot
<eric_engestrom>
(although obviously you should expect tons of other failures related to new/changed tests)
jkrzyszt has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
fab has quit [Quit: fab]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
<eric_engestrom>
daniels: one of the two runners was having IO issues apparently, rebooted now
<eric_engestrom>
*rebooting now
ice9 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
<daniels>
thanks!
iive has joined #dri-devel
<eric_engestrom>
(it's not coming back up, I'm working with someone physically in the office to see what's going on; our CI will be operating at half capacity until that's resolved)
junaid has joined #dri-devel
ybogdano has joined #dri-devel
Duke`` has joined #dri-devel
junaid has quit [Remote host closed the connection]
aravind has quit [Ping timeout: 480 seconds]
<eric_engestrom>
our CI should be fully back up now
jewins has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
<daniels>
mupuf: you might want to either prune results.csv or pre-compress it before uploading; it's 103MB per job which hurts a bit, but more importantly, the artifacts somehow took 7 minutes to upload from when the CTS run actually finished
<daniels>
that pushes pipeline completion from build+14min (roughly where stoney is atm) to build+21min
<jenatali>
jekstrand: I'd love an ack from you on !16200, I think it's good to go unless you've got objections
<jekstrand>
We're not currently carrying dma-buf.h but we've got bits of it duplicated in the Vulkan WSI code now thanks to the new sync_file import/export ioctls.
<jekstrand>
jenatali: Sure. Give me a few minutes.
jkrzyszt has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
bgs has joined #dri-devel
jkrzyszt has joined #dri-devel
mbrost_ has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
jluthra has joined #dri-devel
<anholt>
airlied: not that I know of
pendingchaos_ has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
Guest945 has quit [Remote host closed the connection]
pendingchaos_ is now known as pendingchaos
pallavim__ has joined #dri-devel
<anholt>
bnieuwenhuizen: any ideas about the d/s fails in radv-stoney-aco-fails?
<jekstrand>
jenatali: there you go
<jenatali>
jekstrand: TYVM
<bnieuwenhuizen>
anholt: wow, that is a lot of failures
<bnieuwenhuizen>
no I haven't looked at them
<mupuf>
daniels: da heck, it wasn't like this before :o
<mupuf>
sure thing, will compress it! This is ridiculous
<anholt>
some could be stale, because of test list changes plus fractional run
<anholt>
but apparently at least some d/s fail is being caught by android cts now.
<bnieuwenhuizen>
anholt: if it is in ChromeOS that is likely by the recent 22.2.0 uprev, which might've hit the "100% dynamic rendering" stuff Jason added to the fail list?
<anholt>
sounds likely. but I'm also confused how previous android cts vulkan testing didn't catch the existing fails
jkrzyszt has quit [Remote host closed the connection]
<tango_>
oh updated mesa and got rusticl
<tango_>
no devices though 8-D
<tango_>
which hw is supposed to be supported by it?
maxzor has quit [Ping timeout: 480 seconds]
<eric_engestrom>
tango_: it's not ready yet so by default it exposes nothing; there's an env var to enable it
<tango_>
eric_engestrom: interesting, thanks. I assume radeonsi: driver missing means that it was built without support for it? or is it supposed t not work on amdgpu-controlled devices?
<MrCooper>
not yet, there's a pending MR for that
tursulin has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
apinheiro has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
djbw has joined #dri-devel
nchery has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<siddh>
<danvet> "but that violates the C standard..." <- Though I don't know the specifics of implementation, this sounds like a choice based on types.
<siddh>
Since C11 (and kernel is now on C11), there is a compile time _Generic macro which is like a switch case for non-variable types, allowing for us a kind of overloading. Only the correct argument is evaluated.
<siddh>
There is apparently also a GCC and clang extension __auto_type, analogous to auto in c++ but not exactly the same (only can be used for single variables, so ideally in a macro).
mbrost has joined #dri-devel
gouchi has joined #dri-devel
wv has joined #dri-devel
<wv>
Hello, I have this setup where only the upper part of my screen, connected to a imx53 is visible. To maximize the performance, I was thinking if I could reduce the rendering area to only the visible part, keeping hardware acceleration at place. Is there a way I can achieve this?
<wv>
flow is linux 5.15 -> drm -> wayland -> cog -> wpewebkit
gbelgurr has quit [Ping timeout: 480 seconds]
<wv>
exact same setup on an imx6 too. but imx6 is using etnaviv where imx53 is using freedreno implementation
gawin has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
pa has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
wv_ has joined #dri-devel
wv_ has quit []
wv_ has joined #dri-devel
wv has quit [Ping timeout: 480 seconds]
wv_ has left #dri-devel [#dri-devel]
gouchi has quit [Remote host closed the connection]
wv has joined #dri-devel
gouchi has joined #dri-devel
wv has quit [Remote host closed the connection]
pendingchaos has quit [Ping timeout: 480 seconds]
wv has joined #dri-devel
gbelgurr has joined #dri-devel
gouchi has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
pendingchaos has joined #dri-devel
gouchi has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
paulk-bis has quit [Ping timeout: 480 seconds]
ice9 has joined #dri-devel
pendingchaos has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
eukara has joined #dri-devel
pendingchaos_ has quit [Ping timeout: 480 seconds]
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
pendingchaos_ has quit [Ping timeout: 480 seconds]
jhli has quit [Remote host closed the connection]
cphealy has quit [Remote host closed the connection]
flto has quit [Remote host closed the connection]
cphealy has joined #dri-devel
jhli has joined #dri-devel
flto has joined #dri-devel
robink has quit [Remote host closed the connection]
robink has joined #dri-devel
mvlad has quit [Remote host closed the connection]
junaid has joined #dri-devel
srslypascal is now known as Guest1006
srslypascal has joined #dri-devel
fab has quit [Quit: fab]
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
Guest1006 has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
pendingchaos_ has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Leopold_ has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<danvet>
siddh, pointer types are not all equally (at least the standard allows that)
mbrost has quit [Ping timeout: 480 seconds]
<danvet>
so in theory you have a different function call contract if you pass a void* or a different type
<danvet>
in practice, it's all the same
<danvet>
so in theory you can't cast function pointers from the specific to the generic on
<danvet>
is at least my understanding of the entire mess
<danvet>
and I don't think we can use auto in a struct, where we'd need it :-)
<danvet>
you'd need generics for this
mbrost has joined #dri-devel
Didgy has joined #dri-devel
<siddh>
<danvet> "you'd need generics for this" <- Oh okay, thanks for explaining!
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Didgy has quit [Quit: Konversation terminated!]
Didgy has joined #dri-devel
apinheiro has joined #dri-devel
<siddh>
danvet: I was also looking at doing some of the things mentioned in DRM TODO list to start out and also go for EVoC. I couldn't really get what the "Backlight Refactoring" TODO is trying to say. Can you tell me about that? Also, it seems the TODO list isn't fully updated? For example, the TODO with heading "Convert drivers to use simple modeset suspend/resume" seems to be already done, as I can only find 21 matches for
<siddh>
drm_atomic_helper_resume/suspend in drm folder.
junaid has quit [Ping timeout: 480 seconds]
ahajda has joined #dri-devel
gouchi has quit [Remote host closed the connection]
a1batross has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
<danvet>
siddh, for backlight refactoring talk to sravn
<danvet>
but also I think it's now fairly well advanced, not sure what's left to do
<danvet>
but sravn should know
<danvet>
siddh, some of these have been ongoing for a while
<danvet>
it might be that there's no open coded modeset suspend/resume left (at least for atomic drivers, for legacy onces these helpers don't work)
<danvet>
siddh, if you want maybe check driver's suspend/resume function for how they suspend/resume modeset state
<danvet>
well check first whether it's an atomic driver
<danvet>
and if all are converted, then just submit a patch to delete this todo
<danvet>
if you find some, maybe submit a patch which list these drivers which are left, so that your audit work did not go to waste (ideally mentioning the relevant suspend/resume function that needs work for each)
dcz_ has quit [Ping timeout: 480 seconds]
ice9 has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
<DavidHeidelberg[m]>
Can I create LTO label in Mesa project? (would be used for issues with LTO involved and most likely not occurring on regular builds)