<uvos>
that very likely uses xdg-mime and xdg-open to execute the right app
<Wizzup>
right
<freemangordon>
the fuck! running glmark through ltrace does not hang
<Wizzup>
heisenbugs
inky_ has joined #maemo-leste
<tmlind>
freemangordon: does also glmark with -d option work just fine? i think i saw that earlier after switching to chromeos mesa, not that no longer works for me
<freemangordon>
what -d is for?
<freemangordon>
ah, debug
<freemangordon>
lemme try
<freemangordon>
it doesn;t, but it doesn't without -d as well
<uvos>
freemangordon: since its timeing related
_inky has quit [Ping timeout: 245 seconds]
<uvos>
maybe it will hang with ltrace if you change 0x4A008164 register
<freemangordon>
hmm?
inky has quit [Ping timeout: 260 seconds]
<freemangordon>
what is this register?
<uvos>
sgx clock
<freemangordon>
ok, what value to write?
<freemangordon>
hmm, wait
inky_ has quit [Ping timeout: 260 seconds]
<freemangordon>
I am not sure I will be able to
<freemangordon>
PM is enabled
<uvos>
works fine
<freemangordon>
ok
<freemangordon>
what value?
<uvos>
the clock is just disabled
<uvos>
sec im reading datasheet
<uvos>
so default should be 2a
<uvos>
d4 here
<freemangordon>
yeah, d4
<uvos>
just increase the value
<uvos>
bits 0-4 are the devider ratio
<uvos>
(greping in irc.txt here
<uvos>
)
<uvos>
looks like i used to use omapconf write 0x4A008164 0x1f to maximize the amount of artifacting on ddk1.19
<uvos>
for testing
<uvos>
*ddk1.9
<uvos>
freemangordon: yeah still works omapconf write 0x4A008164 0x1f makes it very artifact happy
_inky has joined #maemo-leste
<freemangordon>
uvos: seems to be a timing issue, there is absolutely no difference in calls between blob and chromeos when it comes to call to libpvr_dri_support.so
<freemangordon>
so I don't see how tweaking sgx regs could help
<uvos>
well any call that touches sgx will take longer
<uvos>
so if you slow down the cpu effectivly by adding a debuger the issue would reemerge if you slow sgx too, unless the problem is in omapdrm ofc
<uvos>
and the artifacting on ddk1.9 IS a timeing issue too
<uvos>
and is effected by sgx render time
<Wizzup>
would be nice if we can get tomi involved somehow I think
<uvos>
did anyone email him?
<Wizzup>
don't think we did
LjL^ has joined #maemo-leste
LjL has quit [Ping timeout: 268 seconds]
inky_ has joined #maemo-leste
LjL^ is now known as LjL
<tmlind>
uvos: ack, rwmem 0x4a008164=0x1f brings back a variant of my sway + termite not refreshing problem
<freemangordon>
tmlind: what is PVR_QUIRK_OMAP4 used for?
<tmlind>
freemangordon: nothing any longer, was used with ddk-1.17 for the ioctl proxying
<tmlind>
sorry i mean was used with ddk-1.9 for the ioctl proxying
<freemangordon>
but it is still enabled
<freemangordon>
shall I disable/remove it
<tmlind>
yeah i don't think there code is there any longer?
<tmlind>
yeah let's get rid of it
<freemangordon>
as I am going to test with ocp management disabled, on d4
<tmlind>
ok great, sounds like we should not need it on omap4 and later
<freemangordon>
ok
<tmlind>
it might be that we only need it for 36xx
<freemangordon>
and it might be the reason for the hangs
<freemangordon>
the same way it was on 3430
<freemangordon>
but, lets see
<tmlind>
ok good to check for sure
<freemangordon>
kmscube still works, glmark2 still hangs :D
<freemangordon>
uvos: hmm, there is 'final' not 'beta' version too
<uvos>
so is abook is finised enough for me to wirte an sphone pluginn that uses it?
<freemangordon>
no
<uvos>
ok
<uvos>
freemangordon: would only need OssoABookContactChooser to work at first most likely
<tmlind>
freemangordon: heh that looks like a fancy way of saying null pointer exception
Pali has joined #maemo-leste
<uvos>
tmlind: am i reading that correctly some non null address in (invalid) page table entry maps to 0x0?
<tmlind>
probably everything is zero, maybe after memset or something like that?
<tmlind>
maybe the dropped mutex freemangordon noticed?
<tmlind>
or rather additional mutex in the blobs?
<uvos>
yeah thats the question the mutex might be guarding against something else causing the memory region to be swaped to some other space in mmu
<uvos>
(for the cpu to mess with it)
<uvos>
ofc that makes no sense if everything is 0
<freemangordon>
but, that mutex makes sense in case of MT
<freemangordon>
I don't see MT in glmark
<freemangordon>
also, if something is being memset to zero, it shouldn't make any difference if I run through ltrace/valgrind or not, it should fail despit
<freemangordon>
but it does not
<uvos>
freemangordon: right
<freemangordon>
I mean - it never fails if it is run through valgrind or ltrace
<freemangordon>
with chromeos blob that is
<uvos>
freemangordon: so random scenario: sgx renders something, there is a fence missing in drm
<freemangordon>
I think rendering hasn't started yet
<uvos>
omapdrm grabs the buffer for dss, by adjusting mmu depending on timeing we get a half renderd frame with stuff missing, also depending on timeing sgx ends up rendering to a buffer thats unmaped
<freemangordon>
I have pvr driver debug traces
<freemangordon>
uvos: wait, I think we have 2 MMUs involved here
<freemangordon>
at least SGX has its own MMU
<freemangordon>
but, it is not controlled by omapdss driver, afaik
<uvos>
ok yeah
<uvos>
i have no idea about exact intenrals
<freemangordon>
me neither
<freemangordon>
:(
<uvos>
but the above description would in pricinal have the abillity to cause all issues
<uvos>
ie missing bits of frame and the exception
<freemangordon>
but, we may again hit some coherency issue
<uvos>
right missing drm fence
<freemangordon>
hmm, we still not render
<freemangordon>
it faults while stuff is still being prepared
<uvos>
before the first frame?
<freemangordon>
yes
<uvos>
hmm ok
<freemangordon>
i compared pvr traces with and without fault, nothing obviously wrong
<uvos>
could it be an interaction with a different drm client? like omapdrmfb?
<freemangordon>
gpu on d4 is single-core, right?
<uvos>
i think so dual core was added in -70 no?
<freemangordon>
no idea
<freemangordon>
but, just pulled latest driver from chromeos
<freemangordon>
building mesa ATM
<freemangordon>
not that I hope it will work :)
<freemangordon>
doesn;t seem like userspace issue to me
<uvos>
only omap5 is MP2 variant of sgx540 it seams
<freemangordon>
ok
cockroach has quit [Quit: leaving]
<uvos>
freemangordon: hmm so where is chomeos kernel with pvr source
<freemangordon>
dunno, but why?
<uvos>
maybe they carry some commit like: fix null pointers in pvr driver