<freemangordon>
tmlind: also, it seems there is some issues with caching of BOs. Even without TILER and SGX rendering (so, pure 2D on non-rotated scanouts) I see wrongly rendered parts when doing x11perf
<freemangordon>
I wonder if I shall map/unmap on every start/end CPU access, but that seems like an overkill to me
<freemangordon>
I think WL has the same issue, at least by judging on your description
<tmlind>
freemangordon: sure i can pull, will need to catch train so not sure if i can do that before sunday night
<tmlind>
freemangordon: i'll also continue rewriting the interrupt handler stuff to get rid of the remaining ocp code as that probably won't work at all for other architectures
<tmlind>
yeah for sure there's some need to flush stuff somewhere, maybe give the patch i posted last week a try. if that helps, mabye we can optimize it some more
<tmlind>
that was the omapdrm-flush-on-pin-unpin.patch
<tmlind>
freemangordon: also, are you also seeing the wrongly rendered parts on n900, or only on d4?
<Wizzup>
freemangordon: ok, do we need anything else or can things somehow 'work' ?
<freemangordon>
tmlind: I think I see on n900 too
<freemangordon>
Wizzup: I don;t hink so
<freemangordon>
*think
<freemangordon>
but, we shall not enable PVR EXA as of now
<freemangordon>
as it gives rendering artifacts
<freemangordon>
some cache issues again
<freemangordon>
I'll investigate during the weekend
<Wizzup>
ok, so we can build latest kernel with ddk 1.17, mesa, and the ddx
<freemangordon>
yes
<Wizzup>
and I will have to work on the headers split, getting it from the kernel package somehow
<freemangordon>
yes
<Wizzup>
I am still not sure if it that makes more sense but ok
<Wizzup>
np
<Wizzup>
not enabling exa is probably the default in the config?
<freemangordon>
Wizzup: no
uvos has joined #maemo-leste
<uvos>
if you can see it on n900 at all but less its probubly the same as on d4 but with a hdmi display
<uvos>
on d4 its really obvious because sometimes the last frame that stays is wrong
<uvos>
if you plug in hdmi you can still see the errors flickering on animation, but it dosent stay
<freemangordon>
this is different issue
<uvos>
ok
<freemangordon>
'flickering' is what I see on n900
<uvos>
not sure its a differetn issue
<uvos>
if its in dss
<uvos>
the d4 just displays it differently on dsi because the dsiplay stops refeshing during the flicker
<freemangordon>
yeah
<uvos>
so whats a flicker on n900 and d4 hdmi becomse a constant black/wrong rectangle on d4 dsi
<Wizzup>
but fmg says it only happens with exa I think?
<uvos>
is that so fmg?
<uvos>
it happens on wayland too
<uvos>
and ddk1.9 ofc
<freemangordon>
no, it happens without exa too
<freemangordon>
sec (phone call)
<uvos>
ok so that would suggest dss is broken as the only difference between refreshes on d4 hdmi is that dss re reads the same buffer again.
<freemangordon>
so:
<uvos>
so that would suggest caheing
<freemangordon>
we have 3 different issues:
xmn has joined #maemo-leste
<freemangordon>
1. d4 does not update correctly because of manual update dusplay. this is fixed by flushing after scanout has been changed
<freemangordon>
2. n900 (and I guess d4 with hdmi) flickers - on n900 what flickers is the right 1/3 of the display. We have no clue what is this but tmlind has a patch for us to test
<freemangordon>
3. with PVR EXA we have rendering artefacts when hildon-desktop runs. THis is something I sahll take care of
<scops>
hmm is it planed to support the n9 more actively?
<scops>
(i got one in the meantime)
<uvos>
we would be happy if someone picked it up
<freemangordon>
I guess yes, once we have SGX running
<uvos>
but atm no one works on it
<freemangordon>
and yes, ut needs someone to work on it
<freemangordon>
I plan to work on n950
<freemangordon>
but it is different and also have no idea when I will start
<freemangordon>
too much on the plate already
<scops>
if there is an image sometime for testing... i'm here ;)
<Wizzup>
we had a n9 image a long time ago I think contributed by dderby
<freemangordon>
Wizzup: so, I think tmlind and uvos are talking about issue 2
<uvos>
there was a bug that it dident boot some time ago i think
<Wizzup>
but we are trying to focus on a few devices and support those well before expanding to many more, but we'd love for others to take that up
<Wizzup>
freemangordon: right
<uvos>
freemangordon: yeah thats the only one that shows in sway
<freemangordon>
but, only when hdmi is connected, right?
<uvos>
no allways
<freemangordon>
ah
<uvos>
with hdmi its _harder_ to see
<uvos>
but it happens
<uvos>
this is why i suspect dss
<freemangordon>
well, I see no such flickering on d4 with omap-video
<uvos>
because when the display is merly re-refeshed (with same image)
<uvos>
freemangordon: even with slow or hevly loaded sgx?
<freemangordon>
yes
<uvos>
ok
<uvos>
wierd
<freemangordon>
I can run glmark2 within h-d and it will render corecctly (without pvr exa)
<freemangordon>
actually it renders correctly with pvr exa too
<uvos>
its mostly 2d on 3d engine stuff that shows it for me
<uvos>
ie sway windows
<freemangordon>
but some other things are rendered incorrectly (styatus menu for example)
<uvos>
ok
<uvos>
neat about you having exa working allready :)
<uvos>
well partally anyways
<freemangordon>
*almost* working :)
<freemangordon>
yeah
<freemangordon>
I need to fix CPU/GPU sync and to RE the composite part
<freemangordon>
ttyl, luch
inky has joined #maemo-leste
uvos has quit [Read error: Connection reset by peer]
inky_ has quit [Ping timeout: 264 seconds]
<tmlind>
freemangordon: i agree on the 3 different issues you listed, except for issue 2 my test patch only hides the d4 command mode lcd issue so it too shows as flicker most likely
uvos has joined #maemo-leste
<freemangordon>
tmlind: ah, I see
<tmlind>
so my patch is likely wrong, just a workaround to force refresh the d4 command mode lcd, it does nothing on n900 or on hdmi
inky has quit [Ping timeout: 268 seconds]
<tmlind>
afaik the flicker only shows with pvr, so likely it needs to flush somewhere
<tmlind>
or has anybody seen it without pvr in play?
<uvos>
freemangordon: claims so above lets
<uvos>
wait until he is back
<tmlind>
yeah gotta go soon, connection will be spotty over the weekend
<uvos>
"tmlind: also, it seems there is some issues with caching of BOs. Even without TILER and SGX rendering (so, pure 2D on non-rotated scanouts) I see wrongly rendered parts when doing x11perf" <--- unless he was using the pvr exa moudle that dosent touch pvr at all
<tmlind>
interesting, that test case might be easiest to trace
<uvos>
actually let me thy this on ddk1.9 without hildon
<uvos>
that uses the cpu to render too
<tmlind>
ok
zhxt has quit [Ping timeout: 265 seconds]
<freemangordon>
yes, this doesn't involve SGX
<freemangordon>
it is like reading from a WC memory reads stale data
<freemangordon>
I don't know how's that possible
<uvos>
honestly x11perf is so flickery i cant tell if its wrong
<uvos>
i blacklisted pvr module on an otherwise usual leste 5.11 kernel
<uvos>
freemangordon: what test did you use
<freemangordon>
x11perf -copywinwin500
<uvos>
indeed
<uvos>
its wrong on modesetting with no pvr and noAcell
<freemangordon>
mhm
<uvos>
it shows the top right missing rendering very well
<freemangordon>
yes
<uvos>
great find
<freemangordon>
lemme see if it happens on TILER BO
<freemangordon>
bottom-left part is affected
<uvos>
same thing on 5.14 sway droid 4 (on xorg noaccel modesetting)
<freemangordon>
tmlind: have a look at p, li { white-space: pre-wrap; } d6f544f6b
<freemangordon>
"Now that the driver supports synchronization through fences..."
<freemangordon>
searching for "fence" in the driver doesn't result in anything useful
<freemangordon>
uvos: ok, but what potentially is not being flushed with CPU access only?
<freemangordon>
not enough pages being mapped should result in segfault, no?
xmn has quit [Ping timeout: 256 seconds]
Twig has joined #maemo-leste
inky has joined #maemo-leste
<freemangordon>
ok, the same x11perf mis-rendering happens on n900 with modesetting and no acceleration
<freemangordon>
so, something is wrong with mmap()-ed memory. or with DSS
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 256 seconds]
vectis has quit [Ping timeout: 240 seconds]
<uvos>
freemangordon: cpus cache would come to mind, but this allso seams to happen with pvr rendering into omapdrm buffers, so that leaves dss missbehaving really unless im missing something.
vectis has joined #maemo-leste
<Wizzup>
scops: are you up for doing development and testing, or just testing?
<freemangordon>
uvos: but, we have the issue when pvr renders too
<scops>
testing ... i dont have the time to development atm
<scops>
s/to/for
<uvos>
freemangordon: right thats why it leaves dss misbehaving
<freemangordon>
ah, you mean "dss behaves correctly"
<freemangordon>
yeah, agree
<freemangordon>
it is something with cache coherency I think
<freemangordon>
but I lack the details
freemangordon has quit [Quit: Leaving.]
freemangordon has joined #maemo-leste
<freemangordon>
gnome crashed :(
pere has quit [Ping timeout: 264 seconds]
<mighty17[m]>
can we get openpvrsgx with 5.15 full release instead of the rc? (i'd be happy to do it myself as well but the last commit/MR from the tree is confusing)
<mighty17[m]>
also #2 can we trouble TI to get info about ducati to make it run in mainline?
<freemangordon>
mighty17[m]: hmm, we are already on 5.15.2
<freemangordon>
mighty17[m]: re 2 - feel free to do it, if you know who shall be pestered :)
<mighty17[m]>
uvos: Ah that's tmlind's tree, always forget to check it 😅
<mighty17[m]>
freemangordon: I was going to make an account on their website but they need my zip code smh
<uvos>
mighty17[m]: i would pretty much just track droid4-pending-* with an omap4 device
<uvos>
there isent a reason not to
<mighty17[m]>
I keep forgetting that my bad
<mighty17[m]>
Will probably package it in pmos as well then
<mighty17[m]>
Esp coz tab uses 4430 like d4
<mighty17[m]>
freemangordon: e2e.ti.com?
<freemangordon>
noidea
<sicelo>
mighty17[m]: i don't think you'll get anywhere with TI. if you want to test the waters, maybe ask in libera/#linux-ti
<mighty17[m]>
Ah I can ask in linux-omap mailing list as well? But I assume only tmlind is active
<freemangordon>
linux-omap ML is active
<freemangordon>
but this is in no way related to TI, AFAIK
<mighty17[m]>
Who else to pester than for ducati, it's TI who kept it a blob
Guest97 has joined #maemo-leste
<uvos>
the firmware for the dsp is a blob
<uvos>
but i mean thats fairly irelivant
<uvos>
the kernel space drvier is in ti's tree
<uvos>
the android userspace is a blob too
<uvos>
but i think there were sources for the gstreamer plugin? not sure tho
<uvos>
what parts are you missing?
<uvos>
also what are you trying to achive here
<uvos>
video playback or encoding and the alogrithums needed for dumb camera sensors?
<freemangordon>
we have gst-dsp for C64x
<freemangordon>
but, we lack drivers
<uvos>
sure but not sure what he wants from ti
Guest97 has quit [Quit: Client closed]
<freemangordon>
though, I had that working with 4.9, iirc
<uvos>
they have drivers
<freemangordon>
yeah
<uvos>
they are just not in mainline
<mighty17[m]>
uvos: Preferably video playback, but in android that fw blob is needed
<mighty17[m]>
I thought it was the same case for mainline
<uvos>
the android userspace blob is just a translator for the kernel interfaces to the android hal
<uvos>
its not realy relevant
<freemangordon>
isn't that supported by remoteproc?
<mighty17[m]>
uvos: Ooooh didn't know that
<uvos>
freemangordon: on android vendors write closed source accelerator plugins for its hal, im not sure what kernel interfaces the motorola one ends up using.
<uvos>
yes it should use remoteproc if its sane
<freemangordon>
uvos: yes, it is the same on fremantle (closed source gst plugins), but interface was REed and gst-dsp came out
<mighty17[m]>
<freemangordon> "though, I had that working with..." <- So basically search ti's git for commits, add to my tree and magic?
<Wizzup>
scops: ok
<uvos>
i think magic is farily rare in this particular universe
<Wizzup>
hehehe
<freemangordon>
mighty17[m]: yeah, you need diskworld for that :)