ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
glennk has quit [Ping timeout: 480 seconds]
The_Company has joined #dri-devel
Company has quit [Ping timeout: 480 seconds]
alane has quit []
alane has joined #dri-devel
The_Company has quit []
Company has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
cphealy has joined #dri-devel
davispuh has quit [Ping timeout: 480 seconds]
sadlerap has quit [Read error: Connection reset by peer]
Company has quit [Quit: Leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
user21 has joined #dri-devel
<user21>
noob here, I want to compile from sources + apply some patches before compiling, how do I install and how do I tell all went well and the MESA is working as supposed
xroumegue has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
xroumegue has joined #dri-devel
<soreau>
user21: you probably want to install to a nonstandard prefix such as /opt/mesa/, apply the patches before running meson/ninja to configure+build it
<soreau>
Then at runtime, use LD_LIBRARY_PATH=/opt/mesa/lib/$libdir/ (actual path may vary) before starting an app that will use your patched mesa
<soreau>
check the configure output to make sure it's configured the way you expect
<soreau>
the runtime test will let you know it's working, e.g. `LD_LIBRARY_PATH=/opt/mesa/lib glxinfo | grep "OpenGL renderer string"`
<soreau>
this way, you can use your patched mesa on-demand and not mess with your system mesa installation in /usr
<user21>
thank you, I compiling on debian, having some config error like this `Run-time dependency libtizonia found: NO (tried pkgconfig and cmake)`
<user21>
where to install these from
<K900>
You don't need to install every single thing it asks for
<soreau>
you will have to work out the dependencies, yes.. though you can configure mesa to build without the things you don't need
<soreau>
check mesa/meson_options.txt for configure options
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
cphealy_ has joined #dri-devel
cphealy has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
Duke`` has joined #dri-devel
glennk has joined #dri-devel
fantom_ has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
fantom has quit [Ping timeout: 480 seconds]
dviola has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
diego has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
tzimmermann has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
jsa1 has quit [Ping timeout: 480 seconds]
jsa1 has joined #dri-devel
sima has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
diego has left #dri-devel [#dri-devel]
cascardo_ has joined #dri-devel
dviola has joined #dri-devel
apinheiro has joined #dri-devel
cascardo has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
f11f12 has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
akhilpo has joined #dri-devel
lynxeye has joined #dri-devel
sgerhold has joined #dri-devel
frieder has joined #dri-devel
<sima>
pinchartl, if you still need an ack for your renesas color mgmt patch: a-b: me
mehdi-djait3397165695212282475 has joined #dri-devel
<javierm>
tzimmermann: IMO tiny and simple-KMS are somewhat related and likely we would like to get rid of both
<javierm>
tzimmermann: thanks, I'll merged that patch then
<tzimmermann>
there's one major issue in the patch, i'll commenton it
<javierm>
tzimmermann: ah, Ok
<tzimmermann>
tiny is for everything that has only one source file
<tzimmermann>
so keeping it is preferred
<tzimmermann>
simple-kms can go
<javierm>
tzimmermann: yes I know but AFAICT it started as drivers (with one source file) but that were using simple-kms
<javierm>
then it seems that other small drivers were added too
<javierm>
anyways, no strong opinion to keep that dir
<tzimmermann>
IIRC noralf made mipi-dbi and simple-kms, and several one-file drivers using them. and we had a few other one-file drivers. eventually those drivers all ended up in tiny/
<tzimmermann>
simple-kms became independend from mipi-dbi and got adopted in other drivers.
<javierm>
tzimmermann: I see
<sima>
I think tiny/ just for one-file drivers independent of drivers using simple-kms makes sense
<tzimmermann>
i did some of that actually
<sima>
also promoting a pile of tiny drivers all from same vendor or otherwise related into their own dir/ makes sense too
<javierm>
tzimmermann: btw, I disagree with your comment about the Kconfig symbol. AFAIK that is not an ABI, just like is not a driver file name
<tzimmermann>
simple-kms should rathre go away or become a mipi-dbi thing again
<javierm>
if we are moving the drivers out of tiny/ there's no point on having their symbols a TINYDRM prefix
<javierm>
in fact, that prefix always looked weird to me and I noticed that newer tiny/ drivers don't have it
<tzimmermann>
if you run olddefconfig ith that patch, it'll disable these drivers then
<javierm>
tzimmermann: yes, but that is usually the case with new kernel versions and kconfig symbols change over time
<sima>
could probably keep the old config name around doing nothing as a hidden thing and for the new one default y if DRM_TINYDRM_FOO or something like that?
<tzimmermann>
yeah, TINY looks weird, that's why we don't use them any longer
<sima>
for one kernel release
<sima>
for build backwards compat
<tzimmermann>
sima, if we can go with such a workaround, i'm all for changing the names
<tzimmermann>
we just shouldn't do it 'because we can'
<sima>
imo entirely fine to do, but kconfig is sometimes a heated thing
<javierm>
sima: agreed with tzimmermann and I don't know of any case where old config symbols were kept for backward compat as you suggest
<sima>
wouldn't be the first thing where dri-devel goes first :-P
<javierm>
what I can tell from helping with the fedora kernel package maintanance is that both kconfig symbols and drivers .ko names change over time
<javierm>
sima: fair :)
<tzimmermann>
mripard, thanks for taking care of drm-misc-fixes last week
itoral has quit [Read error: Connection reset by peer]
<tzimmermann>
javierm, sure, but distro maintainers will curse you anyway
<sima>
javierm, yeah, but being friendly is still nice I guess
<javierm>
tzimmermann: yes, with my distro maintainer hat I will probably curse me but with my upstream developer hat I think that not keeping that TINYDRM prefix is the correct thing to do
<sima>
wrt simple-kms I'd look at it as "does it help with collaboration?" and not so much whether it's technically the best thing
<sima>
it's a midlayer, but at least the idea was to encourage the fbtft drivers to get into drm, or similar stuff
<tzimmermann>
javierm, it says "Userspace should not rely on the presence or absence of any particular Kconfig symbol"
<javierm>
sima: IMO having reusable helpers ease collaboration more than having a midlayer
<tzimmermann>
is that really what we discuss?
<sima>
javierm, yeah it's a tradeoff
<tzimmermann>
javierm, agree
<javierm>
for example, the panic handler can't be implemented with simple-kms
<sima>
just wanted to bring into the discussion that the goal of simple-kms was a lot more non-technical than maybe other helpers
<sima>
but if the more modular helps caught up, we can phase it out
<javierm>
sima: oh, yes I can see that and it was very helpful I would guess at the time to abstract the atomic helpers away
<javierm>
in fact, when I implemented the ssd130x driver I used it because for me was easier to wrap my head around
<tzimmermann>
sima, to me simple-kms teaches the wrong abstractions and the wrong way of thinking. hence, i've been slowly pushing to phase it out
<sima>
yeah it was a good sweet spot between yolo fbdev and the full atomic kms complexity
<javierm>
but then tzimmermann did a lot of work to clean up and provide better atomic helpers and migrating away from simple-kms lead to a cleaner driver
<javierm>
specially once I added support for other IC families from the same vendor
<sima>
tzimmermann, yeah I think a more gradual ramp between fbtft/simple-kms and the full complexity of atomic kms is better, probably
<javierm>
sima: we have now a lot of macros that drivers can use to define default helpers
<sima>
yeah it's much better than years ago
<sima>
it's just kinda hard to judge whether people can quickly whip up a driver or whether too many implied concepts are needed
<sima>
if you know atomic kms inside out having worked on it for years
<sima>
I'm even less qualified on that question :-/
<javierm>
e.g,: DRM_GEM_SHADOW_PLANE_HELPER_FUNCS, DRM_GEM_SHMEM_DRIVER_OPS or DRM_FBDEV_SHMEM_DRIVER_OPS. I believe none of these existed when I first used simple-kms
<javierm>
but tzimmermann should know since he wrote most of them :)
jfalempe has joined #dri-devel
<javierm>
tzimmermann, sima: going back to the kconfig symbol name discussion, I think what the ABI doc says is exactly what we are discussing:
<javierm>
Kconfig. Userspace should not rely on the presence or absence of any particular Kconfig symbol, in /proc/config.gz, in the copy of .config commonly installed to /boot, or in any invocation of the kernel build process.
<javierm>
tzimmermann: for me the last bit is related to kernel package maintainers
<tzimmermann>
yeah, could be. i made a lot of the more-reusable artifacts and put them behind initializer macros. makes it easy to copy-pase a simple driver
<tzimmermann>
javierm, fair point on that last part
<javierm>
tzimmermann: I know is a pita and as mentioned I've suffered myself, but still upstream development should not be constrained by these...
f11f12 has quit [Quit: Leaving]
<javierm>
tzimmermann: and on the other topic, absolutely agreed with your approach that reusable artifacts abstracted away behind initializer macros is much better than simple-kms
kasper93 has quit [Ping timeout: 480 seconds]
<javierm>
because it gives you both a simpler model while remaining flexible since a driver could implement its own helper(s) if needed
<tzimmermann>
can we have one realease where we change all our kconfig symbols? just for watching the fallout and the lulz? >:-)
rasterman has joined #dri-devel
<javierm>
tzimmermann: haha
feaneron has joined #dri-devel
Company has joined #dri-devel
fab has joined #dri-devel
dolphin has joined #dri-devel
sa7mfo has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
kts has joined #dri-devel
any1_ has left #dri-devel [#dri-devel]
kasper93 has joined #dri-devel
guludo has joined #dri-devel
aljazmc has joined #dri-devel
fab has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
guludo has quit [Quit: WeeChat 4.6.1]
guludo has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
aljazmc has quit []
coldfeet has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
guludo has quit [Quit: WeeChat 4.6.1]
guludo has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
coldfeet has quit [Quit: Lost terminal]
fab has joined #dri-devel
itoral has quit [Remote host closed the connection]
<mattst88>
I'd like to be able to move ppc/ppc64 to current mesa in Gentoo
<zmike>
not really, I don't have anything big endian to test with
fab has joined #dri-devel
<mattst88>
how about if you had ssh and root on an iMac G4? :)
<zmike>
uhhhhhhhh
<zmike>
I also don't really know how graphics work on big endian? 😬
<zmike>
it's like component reversal or whatever I guess
<zmike>
seems like probably it's using the wrong rgba variant or somesuch
<mattst88>
yeah, it's gotta be some nonsense like that
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
epoch101 has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
epoch101_ has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has quit []
mehdi-djait3397165695212282475 has joined #dri-devel
kxkamil2 has quit []
fab has quit [Ping timeout: 480 seconds]
amarsh04 has quit []
kts has joined #dri-devel
epoch101_ has quit [Ping timeout: 480 seconds]
kxkamil has joined #dri-devel
fab has joined #dri-devel
mehdi-djait3397165695212282475 has quit []
djbw has joined #dri-devel
coldfeet has joined #dri-devel
<enunes>
zmike: I think it breaks because util_framebuffer_init doesn't reset cbufs > nr_cbufs to 0, so if a new set_framebuffer_state goes with e.g. nr_cbufs=0 the previous ones remain there
lynxeye has quit [Quit: Leaving.]
<zmike>
enunes: oh you mean if the previous state had nr_cbufs>0 and the new state is nr_cbufs=0 it doesn't unref?
<zmike>
or ?
amarsh04 has joined #dri-devel
<enunes>
zmike: yes that, at least that fixed the test I was working on
<zmike>
that's the responsibility of the driver to handle
<zmike>
the driver should only access cbufs based on the size of nr_cbufs
jsa1 has quit [Ping timeout: 480 seconds]
<enunes>
can be, at least the existing code just checked if cbufs[0] is NULL rather than nr_cbufs so that is probably the bug
<zmike>
ah
epoch101 has joined #dri-devel
<zmike>
I mean you can always call framebuffer_unreference before init if you want to ensure your state is zeroed
<zmike>
the idea with this MR is to just get an initial implementation working on each driver and then everyone can optimize how they want
rpavlik2 has joined #dri-devel
<zmike>
austriancoder: maybe this is the same issue you have^
rpavlik2 has quit []
rpavlik has joined #dri-devel
<enunes>
zmike: I'm not sure if it needs to be unreferenced, but can't util_framebuffer_init set the remaining cbufs to NULL to avoid this? I think for zsbuf it already does
<enunes>
otherwise, I think the easiest way is to do that in the driver set_framebuffer_state
<zmike>
I suppose
<enunes>
I also want to just figure out how to unblock that MR and this all probably needs to be reworked later
<zmike>
okay, pushed an update which should handle that
<enunes>
thanks, my local piglit run is still ongoing, but I think it's worth to run that through CI again since now it should at least not crash/timeout
<zmike>
I wonder if you're hitting the same synchronization thing some other drivers have been hitting with u_blitter
maxzor has quit []
epoch101 has quit [Ping timeout: 480 seconds]
<enunes>
zmike: I think it is, I read the commends and added a flush in lima_blit and it seems to be fixed
<zmike>
oh great
<zmike>
you can push to the branch if you want
epoch101 has joined #dri-devel
<enunes>
I'll do some more tests with it and then add a commit on top
<zmike>
👍
<zmike>
thanks for figuring it out so quickly
Mangix has joined #dri-devel
asrivats has joined #dri-devel
aljazmc has quit []
epoch101 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
Nasina has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
hikiko has joined #dri-devel
hikiko_ has quit [Ping timeout: 480 seconds]
<abhinav__>
imre vsyrjala Hi, I had a question on https://patchwork.freedesktop.org/patch/394235/ . Can you pls point me to which section of the spec mentions "Besides power-saving, the advantages of this are that the maximum number
<abhinav__>
of LTTPRs can only be used in non-transparent mode"
<abhinav__>
I am unable to locate where it mentions, non-transparent mode is more power efficient and that it supports more number of LTTPRs in the DP 2.1a spec
sima has joined #dri-devel
asrivats has quit [Ping timeout: 480 seconds]
haaninjo has quit [Quit: Ex-Chat]
special has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
Nasina has quit [Read error: Connection reset by peer]
Nasina has joined #dri-devel
mattst88 has quit [Quit: leaving]
hikiko_ has joined #dri-devel
epoch101 has joined #dri-devel
hikiko has quit [Ping timeout: 480 seconds]
JRepin has quit []
JRepin has joined #dri-devel
hikiko has joined #dri-devel
Nasina has quit [Remote host closed the connection]
Nasina has joined #dri-devel
hikiko_ has quit [Ping timeout: 480 seconds]
apinheiro has quit [Quit: Leaving]
glennk has quit [Ping timeout: 480 seconds]
etehtsea has quit [Read error: Connection reset by peer]
etehtsea has joined #dri-devel
epoch101 has quit []
mattst88 has joined #dri-devel
hikiko_ has joined #dri-devel
hikiko has quit [Ping timeout: 480 seconds]
lion328 has quit [Quit: Leaving]
odrling has quit [Remote host closed the connection]