sarnex has quit [Remote host closed the connection]
sarnex has joined #dri-devel
<javierm>
tzimmermann: jwerner from Google suggests that in Coreboot systems, the Coreboot table isn't the single source of truth, in contrast to DT systems so the same solution doesn't apply
<javierm>
tzimmermann: for example, one can use edk2/UEFI as Coreboot payload (https://doc.coreboot.org/payloads.html#edk2) in that case the payload can decide to pass a different mode in the EFI-GOP table
<javierm>
or SeaBIOS a VESA mode as is the case on the reported bug. I've proposed a different patch then that just checks whether the screen_info video type is VLFB or EFI and bail in that case
<tzimmermann>
javierm, i see. let me read and proces that email. my morning coffee has yet to kick in :)
LeviYun has joined #dri-devel
<javierm>
tzimmermann: :)
avolmat has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, makes sense to me
<tzimmermann>
let me comment on the actual patch
LeviYun has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
fab has joined #dri-devel
<tzimmermann>
javierm, thanks a lot for handling the bug report
frankbinns has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: you are welcome
LeviYun has joined #dri-devel
jsa has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
glennk has joined #dri-devel
zzoon_back_on_19th[m] has joined #dri-devel
soreau has quit [Ping timeout: 480 seconds]
soreau has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
frankbinns has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
sima has joined #dri-devel
lynxeye has joined #dri-devel
kxkamil2 has quit []
Lucretia has joined #dri-devel
kts has joined #dri-devel
kxkamil has joined #dri-devel
LeviYun has joined #dri-devel
<tzimmermann>
jfalempe_, hi, have a minute?
jfalempe_ has quit []
jfalempe has joined #dri-devel
<jfalempe>
tzimmermann: Hi, yes. Sorry due to network glitch I wasn't registered.
<jfalempe>
unfortunately no, I don't know the internal of aspeed chips.
<jfalempe>
looks like only ASTDP_DPMCU_TX is used.
<tzimmermann>
these constants can be read from vgacrd1
<tzimmermann>
so i assume that each of them is meaningful in some way
<tzimmermann>
right, astdp is used
<tzimmermann>
there's also sil164
<tzimmermann>
dp501 and embedded_fw
<tzimmermann>
but some are mysterious
<tzimmermann>
for example that ite chip does HDMI
<tzimmermann>
CH7003 appears to be a TV output (?)
<tzimmermann>
i'm not even aware of such ast devices
kts has quit [Quit: Leaving]
<jfalempe>
Yes, it might refer to some internal products that were never release.
<tzimmermann>
jfalempe, right now, these odd cases seem to be reported as vga or sil164. when refactoring, should i make it fail? or something else?
<tzimmermann>
i'm slightly confused about this
<jfalempe>
I'm not sure either. There is tradeoff between following the spec and having clean code, and not breaking things that already works.
LeviYun has joined #dri-devel
<tzimmermann>
i guess i could make something up
<jfalempe>
Maybe put a warning first, if we get unconsistent value for this register, and wait a bit before failing.
<tzimmermann>
in some cases, the driver looks at the hightes bit in vgacra3 to detect analog (vga) from digital (sil164) outputs. i'd assume that this implicitly covers these odd chips as well
<tzimmermann>
the ite chip is likely digital (hdmi) and would be handled like the sil164
<tzimmermann>
and the ch7003 (tv) is likely analog and would be handled as vga
benjaminl_ has joined #dri-devel
<tzimmermann>
and it works because these tx chips are programmed by ast's firmware. driver support doesn't seem to be required.
<tzimmermann>
(if they even exist in real devices)
rasterman has joined #dri-devel
<jfalempe>
I think I would first merge a patch that warn if this register reports values that would break, and wait a few release before using it for real.
benjaminl has quit [Ping timeout: 480 seconds]
<tzimmermann>
jfalempe, ok. what kind of warning would be appropriate? i'd like to here from people that own such a device. so maybe a drm_WARN_ON() for the odd values?
<jfalempe>
tzimmermann: yes a real kernel warning, so that people will notice.
<tzimmermann>
ok, great. i'll send out a patch to do that
<tzimmermann>
thanks a lot
<jfalempe>
When a hw register is not used by the software, it tends to be less reliable, so at least we will be careful on this.
pq has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
jkrzyszt has joined #dri-devel
kts has joined #dri-devel
benjaminl_ has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
fab has quit [Quit: fab]
ellyq_ has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
LeviYun has joined #dri-devel
luc has joined #dri-devel
fab has joined #dri-devel
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
nerdopolis has joined #dri-devel
davispuh has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
heat has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
epoch101 has joined #dri-devel
heat is now known as Guest3364
heat has joined #dri-devel
Guest3364 has quit [Read error: Connection reset by peer]
f11f12 has joined #dri-devel
guludo has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
atiltedtree has quit [Read error: Connection reset by peer]
sumoon has quit [Read error: Connection reset by peer]
mainiomano has quit [Write error: connection closed]
mainiomano has joined #dri-devel
alethkit has quit [Read error: Connection reset by peer]
alethkit has joined #dri-devel
pitust has quit [Read error: Connection reset by peer]
kchibisov has quit [Read error: Connection reset by peer]
kchibisov has joined #dri-devel
pcercuei has joined #dri-devel
jsa has joined #dri-devel
Schrostfutz_ has joined #dri-devel
pcercuei has quit []
luc has quit []
aperezdc has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
coldfeet has joined #dri-devel
jewins has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
aperezdc has joined #dri-devel
jsa has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
atiltedtree has joined #dri-devel
pitust has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
bolson has joined #dri-devel
LeviYun has joined #dri-devel
Company has quit [Remote host closed the connection]
Company has joined #dri-devel
hummer12007 has quit [Ping timeout: 480 seconds]
rpigott has quit [Ping timeout: 480 seconds]
alethkit has quit [Ping timeout: 480 seconds]
atiltedtree has quit [Ping timeout: 480 seconds]
pitust has quit [Ping timeout: 480 seconds]
cmarcelo has quit [Ping timeout: 480 seconds]
kuruczgy has quit [Ping timeout: 480 seconds]
ifreund has quit [Ping timeout: 480 seconds]
nucfreq has quit [Ping timeout: 480 seconds]
kennylevinsen has quit [Ping timeout: 480 seconds]
ella-0 has quit [Ping timeout: 480 seconds]
rosefromthedead has quit [Ping timeout: 480 seconds]
mainiomano has quit [Ping timeout: 480 seconds]
kchibisov has quit [Ping timeout: 480 seconds]
aperezdc has quit [Ping timeout: 480 seconds]
jsa has quit [Ping timeout: 482 seconds]
aperezdc has joined #dri-devel
dridev has joined #dri-devel
dridev has quit []
alethkit has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
kennylevinsen has joined #dri-devel
mainiomano has joined #dri-devel
kchibisov has joined #dri-devel
kuruczgy has joined #dri-devel
ella-0 has joined #dri-devel
aperezdc has quit [Ping timeout: 480 seconds]
ifreund has joined #dri-devel
sumoon has joined #dri-devel
hummer12007 has joined #dri-devel
rpigott has joined #dri-devel
atiltedtree has joined #dri-devel
nucfreq has joined #dri-devel
rosefromthedead has joined #dri-devel
cmarcelo has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
MrCooper has joined #dri-devel
pitust has joined #dri-devel
<MrCooper>
hmm, seeing a lot of cycles spent in mesa_db_update_index during a piglit run
LeviYun has quit [Ping timeout: 480 seconds]
Schrostfutz_ has quit [Read error: Connection reset by peer]
LeviYun has joined #dri-devel
yshui has joined #dri-devel
epoch101 has quit []
aperezdc has joined #dri-devel
kzd has joined #dri-devel
Haaninjo has joined #dri-devel
epoch101 has joined #dri-devel
<jfalempe>
tzimmermann: I'm trying to rebase drm_log with your series with the client setup helper. One issue is that drm_client_setup.o is part of the kms helper module.
<tzimmermann>
jfalempe, is there a linker conflict?
<jfalempe>
drm_log and the drm client api is part of the drm module, so it would be better to have the setup here too ?
<jfalempe>
I think it's just that it makes drm_log depends on kms helper, even if it doesn't need to.
mohan43u has quit [Quit: WeeChat 4.4.0]
f11f12 has quit [Quit: Leaving]
mohan43u has joined #dri-devel
<tzimmermann>
drm_client calls into the fbdev client, which is in drm_kms_helper
<tzimmermann>
drm_client_setup calls into the fbdev client, which is in drm_kms_helper
<jfalempe>
ok, I though it wouldn't work, because kms helper also depends on drm.
<tzimmermann>
the thing is: most of the client code is called from drm drivers. so it should be in a selectable module
<tzimmermann>
only a small part of the client api is called from the drm core
<tzimmermann>
this needs to go into drm.ko
<tzimmermann>
i think
<tzimmermann>
but that is a bit of a rework of the dependencies; so it belongs into a separate series
<tzimmermann>
why does drm_log need ot be in drm.ko ?
<jfalempe>
yes, it can be done as a separate step
<jfalempe>
drm_log is to show the early boot log, it doesn't make sense to have it as a module, because at that time your userspace could do the same.
Guest3306 has quit [Remote host closed the connection]
<tzimmermann>
if you need a short-term solution; i'd suggest to link drm_log into kms-helpers. we should likely add a drm_client.ko module that contains the client code
<tzimmermann>
but all your drivers are in modules. you cannot run drm_log before the driver started
<jfalempe>
simpledrm usually is built-in
<vsyrjala>
is there anything that doesn't actually depend on drm_kms_helper? just wondering why we insist on hanging on to it and getting things messed up all the time
<tzimmermann>
that's not my the point. even if simpledrm is linked in. it is still a separate module
<tzimmermann>
i915 didn't use kms-helper. but i'm not sure these days
<tzimmermann>
but kms helper is something else then drm code. even if everything uses it
<jfalempe>
and kms helper are usually built as a module in distribution.
<tzimmermann>
likely not
<vsyrjala>
even drm_rect seems to be in kms_helper these days, and everyone should depend on that on account of plane clipping
<jfalempe>
hum no, it's not in fedora, I think I was confused by other helper modules.
<vsyrjala>
i would think a full kms vs. no kms would be a better split that some arbitrary "helper" vs. "not helper" idea
yuq825 has left #dri-devel [#dri-devel]
<tzimmermann>
vsyrjala, drm.ko is for core code. kms_helper.ko is for implementing drivers. it's two separate things. how do you split full-kms vs no-kms?
dsimic is now known as Guest3381
dsimic has joined #dri-devel
<tzimmermann>
well, drivers/accel does not depend on kms helpers
kts has joined #dri-devel
<tzimmermann>
jfalempe, we should make a client module that has all the clients
Guest3381 has quit [Ping timeout: 480 seconds]
bolson has quit [Ping timeout: 480 seconds]
<jfalempe>
looking at the dep chain, simpledrm depends on kms helper, so if simpledrm is built-in, kms help would be too.
pa has joined #dri-devel
<tzimmermann>
yes
<tzimmermann>
but drm_log is not part of the DRM core api. it should not be part of drm.ko
<tzimmermann>
and this will likely break as soon as someone builds simpledrm as a module
<jfalempe>
It doesn't call directly simpledrm, so should be safe, but I agree it's not a core drm api.
Haaninjo has quit [Quit: Ex-Chat]
<tzimmermann>
because drm_client is also in drm.ko, i assume (?)
<vsyrjala>
does anyone have an actual defintion for "core code"? "code that can be called via standard entrypoints without going through a driver" maybe?
<tzimmermann>
that's why i said that there should be a drm_client.ko module that contains all the client code.
<tzimmermann>
vsyrjala, my definition is that core is anything that is required for ioctls to work
<jfalempe>
Just looking at my drm_log patch, it is a separate "module" but it's a bool, so cannot be built as a .ko
<javierm>
jfalempe, tzimmermann: IMO drm_log should be part of drm (which should be built-in along simpledrm) since we want that output even when initrd fails to be loaded (which could contain the DRM modules)
<javierm>
unsure about the drm_client module dep though
<tzimmermann>
jfalempe, drm used to be quite large whne linked in. i've spend several patch series on reducing the impact of drm modules and making it possible to like them as modules if wanted. it's usually better to split things up into modules and let the kconfig figure out linking.
<javierm>
tzimmermann: yes, agree. jfalempe why is drm_log a bool and not tristate ?
<tzimmermann>
javierm, iff you select a driver to be built-in it's dependenceies will be built-in as well. but why make this mandatory. let the client code sit in a separate module and let kconfig decide when to link it into the kernel
<jfalempe>
for drm_log it doesn't make sense as a module, but I think it should still work
<javierm>
tzimmermann: yes, completely agree. Most distros would set drm, simpledrm, drm_client and drm_log as =y but others could have it as a module
<tzimmermann>
jfalempe, you're confusing general kernel configuration and your specific usecase
<javierm>
jfalempe: I think that's the distinction that tzimmermann is making and makes sense indeed. Forcing vs allowing users to choose
gouchi has joined #dri-devel
<jfalempe>
I think the reason is that I call drm_log_register() from the main drm_register() code
<javierm>
jfalempe: maybe a compromise is maing it tristate but default y ?
<tzimmermann>
most distros will make simpledrm=y and have alomost everything built in. but not everyone whants that
<javierm>
tzimmermann: yeah
<tzimmermann>
jfalempe, drm_log_register() should later go into drm_client_setup()
<jfalempe>
but with the client setup patch from tzimmermann, that is not needed anymore, so drm_log can be built as a module.
<tzimmermann>
right
<jfalempe>
so I just need to select kms_helper from drm_log and that should be ok.
<javierm>
jfalempe: cool, then yes I agree that making it tristate is better and let distros chose their default
<javierm>
but if someone doesn't want drm_log, then shouldn't increase their drm.o size
<tzimmermann>
jfalempe, what exactly does drm_log_register() do?
<jfalempe>
it calls drm_client_init(), drm_client_register() and register_console()
<tzimmermann>
all this should then happen from drm_client_setup()
<jfalempe>
yes, that's what I'm doing, adding a kernel module parameter to choose the drm client, between fbdev or drm log
<tzimmermann>
for testing, drm_log should go into kms-helpers. just like fbdev
<tzimmermann>
and before you merge it we should have a drm_client.ko module that contains all the clients
<tzimmermann>
so your kernel parameter can be something like drm_client.default=log (i'm just making up some names)
<tzimmermann>
or drm_client.default=fbdev
<tzimmermann>
alternatively, we could split drm_client and fbdev into it's own drm_client.ko *now*
<tzimmermann>
before i merge drm_client_setup()
<jfalempe>
Yes, either looks good to me.
<jfalempe>
as you have a lot of reviews, maybe merge your long series first
<jfalempe>
then we can split drm_client and fbdev into it's own drm_client module.
<jfalempe>
and then merge drm_log on top of that.
<jfalempe>
We have plenty of time before the next merge window, so no need to rush.
<tzimmermann>
ok, that would work. i'll also try to come up with some RFC patches that split off client code, so that we have some actual cod eto discuss. (IRC discussions are stressful and confusing to me)
<tzimmermann>
it's friday afternoon here. see you next week
<jfalempe>
tzimmermann: thanks that's fine.
<javierm>
tzimmermann: have a nice weekend
Duke`` has joined #dri-devel
coldfeet has joined #dri-devel
<MrCooper>
yikes, piglit gpu takes ~20 minutes with the default Mesa-DB shader cache, just 7:30 minutes with MESA_DISK_CACHE_MULTI_FILE=1
<ishitatsuyuki>
any idea why? does it slows down driver initialization?
<ishitatsuyuki>
hmm, iirc it does scan over all the hash indexes on startup, so maybe it's O(n^2) if you reinitialize a lot
frankbinns has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
disabling it for piglit sounds like the short-term workaround
<ishitatsuyuki>
maybe we should have went for a sqlite db as the format after all :/
<MrCooper>
yeah, it burns a lot of CPU cycles reading the cache indices
<MrCooper>
and initializing the hash tables
<MrCooper>
looks like CI is "lucky" in that it still preserves only the old mesa_shader_cache directory between jobs, so the Mesa-DB cache always starts empty
<MrCooper>
seems like the Mesa-DB cache really shouldn't be enabled by default yet though
bolson has joined #dri-devel
mbrost has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
<DemiMarie>
SQLite is great so long as one either does not use NFS home directories or has a way to prevent the same user logging in on multiple machines at once. I suspect Mesa is often used on compute clusters where both assumptions fail miserably.
<daniels>
MrCooper: you think it would be better with MULTI_FILE?
<daniels>
having the cache is definitely a win over no cache
<daniels>
or at least, it was when we measured it
<MrCooper>
daniels: not sure about all the ramifications yet, but .gitlab-ci/deqp-runner.sh & .gitlab-ci/piglit/piglit-runner.sh still use tmpfs for ${SHADER_CACHE_HOME}/mesa_shader_cache, which is the multi-file cache directory
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
frankbinns has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
raoul^ has quit [Ping timeout: 480 seconds]
raoul^ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
heat is now known as Guest3388
Guest3388 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
coldfeet has quit [Remote host closed the connection]
anujp has quit [Remote host closed the connection]
jewins1 has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
ellyq_ has joined #dri-devel
anujp has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
LeviYun has joined #dri-devel
Kayden has joined #dri-devel
cyrinux has quit []
cyrinux has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
vliaskov_ has quit [Ping timeout: 480 seconds]
<Ermine>
Do I understand correctly that simpledrm is implemented on top of fbdev?
<javierm>
Ermine: no, it's the opposite. Using the DRM fbdev emulation layer you could have an fbdev on top of simpledrm
LeviYun has joined #dri-devel
kts has quit [Quit: Leaving]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
grillo_0 has joined #dri-devel
<Ermine>
javierm: ok, thank you
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<llyyr>
could someone take a look at !31122? Should be relatively simple
iive has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
mbrost has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
nocentyvar has quit [Remote host closed the connection]
jmnemoniqueueanon has joined #dri-devel
jmnemoniqueueanon has quit [Remote host closed the connection]
jmnemoniqueueanonce has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
odrling_ has quit [Remote host closed the connection]
odrling has joined #dri-devel
guludo has quit [Quit: WeeChat 4.4.2]
rasterman has quit [Quit: Gettin' stinky!]
jfalempe has quit [Quit: jfalempe]
Duke`` has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
<Lyude>
I assume you can have multiple read-only mappings to a GEM object yeah?
benjaminl has quit [Read error: Connection reset by peer]
mohan43u has quit [Quit: WeeChat 4.4.0]
sima has quit [Ping timeout: 480 seconds]
benjaminl has joined #dri-devel
mohan43u has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<emersion>
i don't see a reason why not
gouchi has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
<Lyude>
yay
avolmat has quit [Remote host closed the connection]
<Lyude>
Not sure if I'll have the time before XDC, but I -think- I might have a general idea now of how I can implement CRC generation for rvkms
LeviYun has quit [Ping timeout: 480 seconds]
bolson has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
ellyq_ has quit []
anujp has joined #dri-devel
vliaskov_ has joined #dri-devel
ellyq_ has joined #dri-devel
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
Company has quit [Quit: Leaving]
LeviYun has joined #dri-devel
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
vliaskov_ has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
psykose has quit [Remote host closed the connection]