Wizzup has quit [Read error: Connection reset by peer]
Wizzup has joined #maemo-leste
<Wizzup>
ok, should be done
<Wizzup>
(isp switch)
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 264 seconds]
<freemangordon>
tmlind: seems there is some coherency issue on mmaped BOs, no matter what I do, x11perf tests show terrible tearing. this happens on both d4 and n900
<freemangordon>
I think what I am doing is correct:
<freemangordon>
unless I am missing something, this should assure coherency between CPU and GPU
<freemangordon>
but it does not :(
<freemangordon>
at least this is my understanding
<freemangordon>
or, something else happens
<tmlind>
freemangordon: ok, care to upload some vid on the tearing?
<freemangordon>
the same happens with omap driver though
<freemangordon>
ok
<freemangordon>
tmlind: BTW, I modified omap_gem_is_cached_coherent to always return false and am testing with that on d4
<tmlind>
hmm so with the reverted 33bc43 we at least need to check OMAP_BO_WC and OMAP_BO_UNCACHED masks separately as OMAP_BO_UNCACHED is 0
<freemangordon>
bma_buf gems are allocated with OMAP_BO_WC flag IIUC
<tmlind>
yeah and on n900 it should be DMABUF
<freemangordon>
isn;t it dma_buf on d4 too?
<freemangordon>
despite the tiler?
<freemangordon>
sec, to provide link to the video
<tmlind>
no, it's shmem write-combine on omap4, OMAP_BO_MEM_DMA_API on n900 afaik
<tmlind>
weird if both n900 and d4 have the same tearing.. i confirmed that hdmi enabled does not remove the tearing i'm seeing with wlroots and termite
zhxt has quit [Ping timeout: 264 seconds]
<tmlind>
so i thought this was tiler mapping related issue, but maybe what you see on n900 and d4 is something different then
<freemangordon>
I didn't try omap driver on n900 though, but the issue looks the same with glamor replacement driver
<freemangordon>
3. DDX starts drawing that rectangle on the back buffer
<freemangordon>
4. somehow, in the middle of the drawing MS flips
<freemangordon>
uvos: is this what happens?
<uvos>
freemangordon: no
<freemangordon>
ok, call me stupid, but I don;t get it then :)
<dreamer>
freemangordon: you're stupid
<freemangordon>
thanks
<dreamer>
:)
<dreamer>
y/w
<uvos>
freemangordon: application wants to draw 3 lines
<uvos>
freemangordon: applicaiton calls XDrawLine, x draws line on back buffer, application calls XDrawLine, line finishes drawing, ms flips buffer, application calls XDrawLine
<freemangordon>
uvos: they decompose, but the particular test case draws 4000 dots
<uvos>
modesetting on amdgpu
<uvos>
freemangordon: right so some frames have dots
<uvos>
some dont
<uvos>
some have some
<freemangordon>
but they are drawn in a single pass, I can provide call stack
<Wizzup>
(what I linked adds tearfree to modesetting, but not for rotated display and also is not merged in xserver)
<freemangordon>
uvos: video seems to be broken
<uvos>
use mpv
<freemangordon>
45k
<Wizzup>
it works for me
<uvos>
thats correct
<freemangordon>
ok
<uvos>
ff dosent like it on my end ether
<freemangordon>
omg
<freemangordon>
this is awful
<uvos>
well it goes away if you enable compositing
<uvos>
because then every application has its own back buffer
<uvos>
and draw calls just accumulated
<uvos>
but this is just how x is desinged
<uvos>
its also largly irrelivant because modern applications ussualy just flip the whole window as one pixmap
<freemangordon>
stock xorg + omap driver draws nothing :D
<Wizzup>
right, x11perf might not be the best test case for tearing
<uvos>
accualy what is concerning about the dots video on d4
<uvos>
is that is changes so slowly
<freemangordon>
this is omp driver
<uvos>
ok
<freemangordon>
*omap
<freemangordon>
with glmaor replacement is it waaaay faster
<freemangordon>
but still, we should not have that black rectangle
<uvos>
right
<uvos>
there is something wrong there for sure
<uvos>
maybe same thing as missing tiles on ddk1.9
<uvos>
but idk
<uvos>
just spculating
<uvos>
*speculating
<freemangordon>
no tiles on n900
<uvos>
no tiler on n900
<uvos>
sgx is sill a tile based renderer
<uvos>
but that dosen pass though gpu dose it
<uvos>
hmm
<freemangordon>
and there the black rectangle is on lower-left corner
<freemangordon>
it doesn't
<uvos>
no idea
<uvos>
sorry
<freemangordon>
that why I think there is something wrong with either cache or mmap
<Wizzup>
is this also visible outside of x11perf?
<uvos>
it might make sense to try your dri3 non glamor modesetting on some very stable drm driver
<uvos>
like amdgpu or intel
<uvos>
just to ensure that its not that
<freemangordon>
uvos: hmm, lemme try MS without glamor
<uvos>
yeah just NoAccel glamor might be a good test too
<uvos>
*modesetting
<freemangordon>
mhm
<bencoh>
considering how people complain about tearing issues on various pc setups, it might be just that, yeah
<freemangordon>
the same happens on NoAccel glamor
_inky has quit [Ping timeout: 264 seconds]
<uvos>
*modesetting
<uvos>
:P
inky_ has quit [Ping timeout: 260 seconds]
<freemangordon>
yea
<freemangordon>
but it happens with omap too
<uvos>
so some buffer sync thing between cpu and dss or something
<uvos>
like that
<freemangordon>
so I would say it is a kernel thing
<uvos>
yeah
<uvos>
tmlind is your fault :P
<freemangordon>
heh, upstream xorg has font sizes broken :D
<uvos>
freemangordon: might make sense to try omapdrm with NoAccel modesetting on a mainline kernel with no sgx patches
<uvos>
and see if it sill happens & report a bug on linux
<uvos>
ml
<uvos>
i can do so if you like
<freemangordon>
yeah, maybe
<freemangordon>
uvos: if you can
<uvos>
ok
<freemangordon>
that'd help a lot
<freemangordon>
but I think I didn;t see the same issue with ny test applications
<uvos>
do any of your test applicaitons
<uvos>
oh ok
<uvos>
nvm then
<uvos>
freemangordon: wrt font sizes
<uvos>
freemangordon: xorg is probubly just reporting correct dpi
<uvos>
freemangordon: i noticed that the display size porparty in x is wrong on current leste setup
<uvos>
freemangordon: setting it to be correct breaks gtk2 fonts
<uvos>
amoung others
<uvos>
so check that
<freemangordon>
ah, I see
<uvos>
xdpyinfo | grep resolution
<tmlind>
freemangordon: here are hopefully better version of two patches to replace the reverted 33bc43 commit: muru.com/linux/d4/omapdrm-flush/
<tmlind>
seems to fix my termite on wlroots issue better than 33bc43 based on quick testing
<freemangordon>
tmlind: shall I test?
<tmlind>
heh well based on about 1 minute of testing :)
<tmlind>
yeah please do, hopefully it won't hang n900 any longer
<freemangordon>
ok, will try in a couple of minutes
<tmlind>
well if n900 hangs then would be good to know which of the two patches causes it
_inky has joined #maemo-leste
uvos has quit [Quit: Konversation terminated!]
<tmlind>
so far no tearing here :)
<tmlind>
oh also the weirdness around the sun in stellarium seems to be gone now
<tmlind>
ok saw some tearing on the hdmi panel, so there's at least some issues remaining
<tmlind>
bbl
xes has quit [Ping timeout: 260 seconds]
xes has joined #maemo-leste
pere has joined #maemo-leste
<tmlind>
uvos: maybe also take a look and see if those help with the tearing you're seeing?
<freemangordon>
uvos: resolution: 264x265 dots per inch
_inky has quit [Ping timeout: 265 seconds]
<tmlind>
hmm running glmark2-es2-wayland nowadays produces a sgx lockup, i guess that must be the mesa vs blobs issue
<freemangordon>
mhm
<freemangordon>
tmlind: with both patches applied n900 seems to boot fine
<freemangordon>
glmark runs fine too, so it seems nothing got broken :)
<tmlind>
ok great
<tmlind>
did these help with your tearing issues at all?
<freemangordon>
lemme check
<freemangordon>
no
<freemangordon>
this black square is still there on both devices
<tmlind>
ok
<tmlind>
seems like a separate issue so i'll push out these two fixes if no comments
<freemangordon>
yeah
elastic_dog has quit [Ping timeout: 252 seconds]
<tmlind>
ok pushed out updated droid4-pending-pvr-omapdrm-v5.15
Twig has joined #maemo-leste
elastic_dog has joined #maemo-leste
<tmlind>
looks like rm /dev/dri/renderD128; ln -s /dev/dri/card0 /dev/dri/renderD128 can be used to work around the omapdrm/pvr render node limitations
<tmlind>
we should somehow fix omapdrm to allow the standard calls on /dev/dri/renderD128 also with only allocation happening on /dev/dri/card0
uvos has joined #maemo-leste
<tmlind>
i guess the /dev/dri/renderD128 is created automatically by the kernel based on some flag?
<uvos>
freemangordon: yeah thats correct
<uvos>
freemangordon: so upstream fixed it
<uvos>
on current leste its resolution: 96x96
<tmlind>
ah DRIVER_RENDER i guess creates /dev/dri/renderD128
<uvos>
annoingly nokia just decided its ok to just scall up the fonts
<uvos>
and leave it set wrong at 96x96 (before kms xorg had no way to know the display size without being told in xorg.conf)
<uvos>
this is also why scaling in qt5 and gtk3 is broken in leste
<uvos>
well part of the reason anyways
<uvos>
even if xorg reports correctly scaling is still pretty broken
<uvos>
because the toolkits (esp gtk3) dont do this well
<uvos>
(and gtk2 dosent scalle at all besides fonts)
<uvos>
and everyone blames "X" for scaling being broken on linux... but im getting into a rant here again
<uvos>
and now in wayland mutter they report lie to applications to about the window size and then do bliniear scaling on gpu to make things the right size.. grrr
elastic_dog has quit [Ping timeout: 260 seconds]
elastic_dog has joined #maemo-leste
<tmlind>
uhh i guess nothing wrong with omapdrm for /dev/dri/renderD128, we somehow need to translate /dev/dri/renderD128 to /dev/dri/card0 for the pvr mesa or blobs :(
Pali has joined #maemo-leste
* tmlind
goes to build mesa again on d4
xes has quit [Ping timeout: 265 seconds]
<freemangordon>
tmlind: doess dss support HW rotation?
<freemangordon>
I remember there was something called vrfb
<tmlind>
i think rotation is there only for the tiler and there was something in omap1 that used the sdma
<freemangordon>
do you know if dss driver supports it?
<tmlind>
don't think so, i think only tiler is supported
<freemangordon>
:(
xes has joined #maemo-leste
<uvos>
portrait n900 will be hella slow with roation working in sw no?
<tmlind>
not sure if later omaps even have the sdma support for rotation any longer since omap1
<freemangordon>
uvos: yeah
<uvos>
:(
<uvos>
well pvr2d could do it
<freemangordon>
but, fremantle somehow manages to do it
<tmlind>
hmm so what was nokia using on fremantle then?
<uvos>
pvr2d proubly can rotate the surface on pvr or?
<freemangordon>
don;t know
<freemangordon>
but, I think omapfb was able to rotate
<freemangordon>
so I guess it was somthing in the kernal
_inky has joined #maemo-leste
<tmlind>
oh there is some roation support in omapdrm for framebuffer with the rotate command line, not sure if it's all software without tiler
sunshavi_ has joined #maemo-leste
sunshavi has quit [Ping timeout: 260 seconds]
* tmlind
has 472/1150 of mesa compiled..
<uvos>
weeee
<uvos>
we need a big arm server or something
<uvos>
(yeah i know expensive)
<Wizzup>
I had that, but it broke down
<uvos>
yeah i know a amd one
<freemangordon>
hmm, why modesetting does not rotate through GL?
<uvos>
it dosent with the glamor path?
<uvos>
in the non glamor path should be obvious why..
<freemangordon>
it doesn;t
<uvos>
i gues that they never needed it
<freemangordon>
it seems it does SW rotation even with glamor
<uvos>
since desktop gpus can rotate in drm
<freemangordon>
yeah
<freemangordon>
I am starting to wonder if it makes sense to continue waste time on that
<freemangordon>
that == modesetting
<uvos>
i dont see why your wasting time?
<freemangordon>
because it is broken all over the place
<uvos>
the plan is to create a acell plugin that uses pvr2d right?
<uvos>
ok
<freemangordon>
yes, but we have nasty bug in modesetting
<freemangordon>
*bugs
<uvos>
what is it?
<uvos>
maybe list the ones you found
<freemangordon>
let me record a video, you might have an idea what it might be
<uvos>
i can try repoducing them later
<uvos>
on amdgpu or plain omapdrm w/o sgx
<freemangordon>
BTW h-d scrolls with 58-59 fps
<freemangordon>
on n900
<uvos>
neat
<freemangordon>
yeah
<uvos>
what about gtk2 scrolling lists and sutch?
<uvos>
(ie non gl accelerated rendering)
<freemangordon>
but, there is some 'frames repetition", you'll see in the video
<uvos>
ok
<freemangordon>
I want ^^^ fixed first
<uvos>
any you have evidence that this is ms fault?
<uvos>
or why are you unhappy with it
<freemangordon>
it happens with glamor as well
<uvos>
sure but that dosent mean its not omapdrms fault...
<freemangordon>
'real' galmor
<freemangordon>
wait for a video :)
<uvos>
ok ok
<uvos>
also any bugs you find in ms upstream might fix
<uvos>
since ms is also the base of xwayland....
<uvos>
...and wildy used still on bare metal x too
<freemangordon>
I have the feeling that wrong pixmaps is being drawn to
<uvos>
freemangordon: well i dont see anything that couldent be cause by the kernel messing up buffer allocation or setting up the mmu for dss usage
<uvos>
but im prediposed to think modesetting is not buggy beacuse i have used it for like 10+ years on various devices....
<uvos>
the fact that ddk1.9 with vidoe-omap allso has kinda simmular looking artifacts
<uvos>
altho they are less bad
<uvos>
also makes me suspect the kernel...
<freemangordon>
most-probably because it is slower :)
<freemangordon>
yeah, could be
<freemangordon>
but have no idea how to debug
<uvos>
well first i would try mainline kernel no patches with mainline modesetting no patches on a d4 and see if it artifacts
<freemangordon>
either the driver draws to wrong framebuffer or MS asks kernel to flip to wrong framebuffer or kernel displays wrong framebuffer :)
<uvos>
i will do this soon i promise
<uvos>
tomorrow
<uvos>
and then ask on the kernel m-l
<uvos>
and maybe report a bug against xorg
<uvos>
if so
<freemangordon>
this happens with hildon-desktop only
<freemangordon>
hmm, I will start it with SW rendering, lets see
<uvos>
oh so the problem with black sections in core x rendering is gohne
<uvos>
sorry if i missed it in backscroll
<tmlind>
yeah maybe the two patches i pushed today fixed the black sections that don't get refreshed
<freemangordon>
no, it isn't
<tmlind>
you still see some black squares that don't get refreshed?
<freemangordon>
only with x11perf
<freemangordon>
but I guess this is to be ignored
<uvos>
no
<uvos>
freemangordon: try something else that renders in 2 in a loop
<uvos>
like resizing xeyes or something
<freemangordon>
hmm, it seems like ms without glamor works fine
<uvos>
also sutch artifacts i also sometimes encounter on wayland (sway, weston) too
<uvos>
again makeing me suspect kernel...
<freemangordon>
I see
inky_ has joined #maemo-leste
<uvos>
like bits black bits of missing frame mostly at the top right
<uvos>
can hapen in qt applications on sway
<freemangordon>
by kernel you mean omapdrm I guess
<uvos>
yeah
<freemangordon>
tmlind: can we have tomi on the channel somehow?
<freemangordon>
:)
<freemangordon>
oh, so what we have working now on n900 is omapfd, right?
<freemangordon>
*omapfb
<uvos>
yes
<uvos>
on d4 its omapdrm
<uvos>
and its artifacting
<freemangordon>
yeah
<uvos>
again the common bit is omapdrm
<freemangordon>
mhm
<freemangordon>
I wonder how to debug that
<uvos>
no idea
<Wizzup>
if you take a screenshot using X, I guess the artifacts are not there?
<uvos>
totaly over my head
<freemangordon>
Wizzup: did you watch the video?
<Wizzup>
yes
_inky has joined #maemo-leste
<uvos>
freemangordon: yeah but if scrot also shows the problem is interesing question
<uvos>
on ddk1.9 scrot is fine
<freemangordon>
I wouldn;t say these are artifacts, rather wrong framebuffers
<freemangordon>
what is scrot
<uvos>
x11 screenshot tool
<Wizzup>
freemangordon: yeah, I was wondering around the xterm
<freemangordon>
Wizzup: it is like it renders every line to a different framebuffer/pixmap
<tmlind>
i uploaded the omapdrm flush debug patch i used too to muru.com/linux/d4/omapdrm-flush/
<freemangordon>
hmm, maybe I shall trace what FB memory it renders to
<tmlind>
i just looked at the flushing path taken after starting sway and termite and pressing keys, maybe there are other paths that are unhandled too
<tmlind>
however, afaik n900 is not using this code path at all since it's not shmem write-combined
* tmlind
has 1096/1150 of mesa built now..
<freemangordon>
but it is WC, no?
<tmlind>
hmm actually yeah, but not shmem mapped so should not need anything there
<freemangordon>
hmm, whith h-d running I see no black box
<uvos>
freemangordon: well the artifacting is highly timeing dependant
<uvos>
freemangordon: on ddk1.9
<uvos>
freemangordon: you can mess with the sgx clocks and make it better or way worse
<uvos>
freemangordon: generaly longer frame rendering times makes the problem explode
<uvos>
so the missing boxes might just be a timeing fluke
<uvos>
(if the ddk1.9 problem and yours is related in the first place - but it suspect it is)
* tmlind
has mesa finally built
<tmlind>
looks like the render node checks are in the blobs
inky_ has quit [Ping timeout: 260 seconds]
_inky has quit [Ping timeout: 244 seconds]
_inky has joined #maemo-leste
_inky has quit [Ping timeout: 244 seconds]
<freemangordon>
any idea what "omapdrm omapdrm.0: atomic complete timeout (pipe 0)!" is?