asriel_dreemurr has quit [Quit: Client limit exceeded: 20000]
The_Niz has quit [*.net *.split]
asriel has quit [*.net *.split]
The_Niz has joined #maemo-leste
asriel has joined #maemo-leste
joerg has quit [Killed (calcium.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
Twig has joined #maemo-leste
_inky has quit [Ping timeout: 268 seconds]
pere has quit [Ping timeout: 245 seconds]
_inky has joined #maemo-leste
pere has joined #maemo-leste
Pali has joined #maemo-leste
uvos has joined #maemo-leste
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #maemo-leste
System_Error has quit [Ping timeout: 276 seconds]
_inky has quit [Ping timeout: 246 seconds]
_inky has joined #maemo-leste
vectis has quit [Ping timeout: 260 seconds]
vectis_ has joined #maemo-leste
mighty17[m] has quit [Quit: Bridge terminating on SIGTERM]
calebtheythem[m] has quit [Quit: Bridge terminating on SIGTERM]
MartijnBraam[m] has quit [Quit: Bridge terminating on SIGTERM]
ungeskriptet[m] has quit [Quit: Bridge terminating on SIGTERM]
M1peter10[m] has quit [Quit: Bridge terminating on SIGTERM]
argon has quit [Quit: Bridge terminating on SIGTERM]
scops has quit [Quit: Bridge terminating on SIGTERM]
tvall has quit [Quit: Bridge terminating on SIGTERM]
tvall has joined #maemo-leste
scops has joined #maemo-leste
M1peter10[m] has joined #maemo-leste
mighty17[m] has joined #maemo-leste
argon has joined #maemo-leste
calebtheythem[m] has joined #maemo-leste
ungeskriptet[m] has joined #maemo-leste
MartijnBraam[m] has joined #maemo-leste
asriel_dreemurr has joined #maemo-leste
tvall has quit [Quit: Client limit exceeded: 20000]
scops has quit [Quit: Client limit exceeded: 20000]
<mighty17[m]>
freemangordon: i think i know why phosh doesnt work
<mighty17[m]>
`failed to load driver: omapdrm` even with `export MESA_LOADER_DRIVER_OVERRIDE=pvr` , so somehow its hardcoded to use omapdrm?
<mighty17[m]>
i uh dont understand what is going on, i copied omapdrm_dri.so to become pvr_dri.so and that works with kmscube with `export MESA_LOADER_DRIVER_OVERRIDE=pvr`
<mighty17[m]>
but if i do `export MESA_LOADER_DRIVER_OVERRIDE=omapdrm` that does not work
pere has quit [Ping timeout: 268 seconds]
<mighty17[m]>
yup def an issue with it not using pvr_dri.so but instead wanting omapdrm
<uvos>
its using the wrong render node probubly
tvall has joined #maemo-leste
scops has joined #maemo-leste
<uvos>
dosent phosh use wlroots?
<uvos>
ie are you using patched wlroots
<uvos>
also check if its not static linking
<mighty17[m]>
phosh does use wlroots (and phoc)
<mighty17[m]>
uvos: yes, as it works with chromeos mesa anyways
<mighty17[m]>
uvos: with ls -al?
<uvos>
?
<uvos>
if it dosent use wlroots its irellivant if it uses static linking for something else
<uvos>
oh i read that wrong
<uvos>
yeah check if it links to it dinamicly with ldd
<mighty17[m]>
<uvos> "also check if its not static..." <- i cant seem to find anything about it on phoc/wlroots source code
<uvos>
just ldd the wm
<uvos>
but that would not explain why it works with chomeos mesa anyhow.
<uvos>
other stuff dose work right?
<mighty17[m]>
static linking with omapdrm in source code?
<uvos>
no static linking wlroots therfore using some unpatched version
<mighty17[m]>
it does use wlroots
<uvos>
ldd /usr/bin/phoc or whatever will tell you
<mighty17[m]>
other stuff like kmscube, glmark2-es2-drm does work
<mighty17[m]>
`MESA-LOADER: failed to open omapdrm: Error loading shared library /usr/lib/xorg/modules/dri/omapdrm_dri.so: No such file or directory (search paths /usr/lib/xorg/modules/dri, suffix _dri)` uhm whaat?!
<mighty17[m]>
so its hardcoded somewhere to only use omapdrm and not pvr?
<uvos>
no pvr is failing for some reason so it trys to load omapdrm
<uvos>
probubly
<uvos>
maybe checkout the section where mesa decides what module to use with gdb
<mighty17[m]>
ah figured it out!
<mighty17[m]>
my starter session was being annoying
<mighty17[m]>
well phosh works now 🎉
pere has joined #maemo-leste
uvos has quit [Ping timeout: 256 seconds]
elastic_dog has quit [Ping timeout: 245 seconds]
pere has quit [Ping timeout: 256 seconds]
elastic_dog has joined #maemo-leste
<freemangordon>
mighty17[m]: hmm? it works with HW accelleration?
<freemangordon>
OTOH, seems sgx driver has issues with TILER memory
<freemangordon>
or, it is omapdrm driver that maps wrong addresses
<freemangordon>
tmlind: ^^^
<mighty17[m]>
freemangordon: Yess!!!
<freemangordon>
good :)
<mighty17[m]>
And no more crashes!! It's really amazing
<tmlind>
freemangordon: not following you, care to clarify on the wrong address part?
<freemangordon>
when I do xrandr rotate and use PVR for accelerated 2d, TILER allocated BOs are wrongly accessed
<freemangordon>
seems like either omapdrm provides wrong dma address to pvr driver or pvr driver gets wrong address mapping for this dma address
<freemangordon>
I guess PVR ends up in omap_gem_pin() when it needs DMA address, right?
<freemangordon>
tmlind: SGX should see TILER addresses, correct?
<tmlind>
no idea how that is supposed to work
<tmlind>
have you looked at the /sys/kernel/debug tiler output?
<tmlind>
that might provide some more info
<freemangordon>
sec
<freemangordon>
will do now
<freemangordon>
anything in particular to look for?
<freemangordon>
it seems there is tiler buffer at address 0x70100000
<dreamer>
man, we should get zmatt into here. he dived into TILER heavily some time ago
<freemangordon>
please ask him to join
<dreamer>
/invite zmatt
<dreamer>
I poked him in another channel :)
<freemangordon>
thanks
<tmlind>
freemangordon: i recall seeing some memory leak cases under the tiler debugfs entry after several rotations with ddk-1.9
<dreamer>
because the Pyra uses a phone screen they also needed to do some tiler tricks to get proper fb rotation going
<dreamer>
so yeah, need to get him in here. hope he reads the highlight I gave him :#
<tmlind>
freemangordon: hmms so why would 3d stuff work then and 2d not? tiler is being used the same way, no?
<freemangordon>
TILER is not used for 3d stuff
<freemangordon>
to allocate TILER BO one needs to call omap_bo_new_tiled()
<freemangordon>
and this is done only by omap-video driver for scanout buffers
<tmlind>
ok
<tmlind>
hmm but it sort of worked with ddk-1.9 and the same kernel tiler code more or less?
<freemangordon>
I guess it was not using PVR for accelerated 2D
<freemangordon>
you you work with mmap-ed memory only, tehre is no issue
<freemangordon>
*if you
<tmlind>
ok
<tmlind>
could it be some dma address issue where the rotated bit is left out of the address? if something is cast to 32-bit dma address for the tiler?
<tmlind>
see the tiler rotated view addresses int trm at "Table 2-1. Global Memory Space Mapping"
<tmlind>
hmm i guess it would then just not rotate though
<tmlind>
freemangordon: also not that for ddk-1.9 we had the legacy omapdrm ioctl stuff patched back in
<tmlind>
we should not need those ioctl hacks though hopefully at all
* tmlind
detaching from computer
<freemangordon>
sorry, phone call
uvos has joined #maemo-leste
<uvos>
i gues dumping the sgx's mmu table and checking if it has the tiler space mapped is not an option
<uvos>
since no documentation
<freemangordon>
actually driver dumps the table
<freemangordon>
lemme see if I will be able to understand something
<uvos>
it might just be broken - since ti themselves dont use pvr for 2d for anything since ddk1.14 and more modern omaps (-60 and omap5) have a dedicated 2d engine. one of the ddk1.9 ioctls might have been this.
<uvos>
ah
<freemangordon>
so, omap_gem_rotated_dma_addr() is called only by the framebuffer code
<freemangordon>
based on the rotation that is set to the framebuffer
<uvos>
ah wait
<uvos>
why would sgx want to use the 90deg view? should it not be using 0deg and dss use 90deg view?
<uvos>
or is it the other way around?
<freemangordon>
that's one of the questions I dont; have answers to
<freemangordon>
or, maybe for tiler bos I shall transpose?
<freemangordon>
lemem try
<freemangordon>
*lemme
<freemangordon>
uvos: I think it shall see rotated TILER address, how it is supposed to draw a line (rotated) if not.
<uvos>
freemangordon: you draw a line using the non rotated view and the rotated view is then scanned out?
<uvos>
freemangordon: how else is it supposed to work?
<freemangordon>
hmm
<uvos>
freemangordon: if you draw a line into the rotated view and also scann it out you get no change no?
<freemangordon>
but then why I see it draw mostly out of screen
<freemangordon>
lemme take a picture to show what I mean
<uvos>
the buffer your allocating is the wrong size maybe?
<freemangordon>
not, it is fine
<freemangordon>
if you acces it through mmap it is ok
<freemangordon>
only pvr2d sees it wrong
<freemangordon>
ok, seems we have negative offset on y
<uvos>
the header pvr gets might be wrong? sees a 540x960 buffer in landscape?
<uvos>
i gues the line would be more than ofset then (it would be spread all over the place)
<uvos>
negavtive y in what space? native display or rotated buffer?
<freemangordon>
I see only top (maybe) 256 pixels painted in the fill color
<uvos>
top being the top in native orientaion?
<freemangordon>
no, top in rotated orientation
Twig has quit [Ping timeout: 240 seconds]
<uvos>
ok that excludes the possible pvr thinks its drawing into a 540x960 buffer
<uvos>
*possibility
<freemangordon>
yeah
<uvos>
no idea then, fun :)
<freemangordon>
if I hardcode X size, it is ok, like if I hardcode 512, I have 512x? blue rectangle
<freemangordon>
but I cannot extend on vertical
<freemangordon>
so it seems to try to draw correct thing
<freemangordon>
hmm, maybe this is 64 lines
<calebtheythem[m]>
heyo, my Photon Q arrived, it's in amazing condition, super chuffed. Anyway it looks like it exposes UART in the same way as the droid 4, the Android kernel has some sysfs bits you can poke to put the mux into UART mode manually, but I wasn't able to get it to spit out any data, any ideas?
<calebtheythem[m]>
I did manage to find some info about the Moto X which uses almost the same SoC and released soon after the Photon Q, it isn't a slider phone unfortunately. But I found out that it exposes UART on the unpopulated JTAG header, I would guess the Photon Q uses the same pinout there. So I should be able to get UART that way
<uvos>
on the d4 the android kernel never dose anything with the uart (iirc its not even configured in dts)
<uvos>
so you have to kexec somewhere else if you want to use it
<uvos>
like los maybe
zmatt has joined #maemo-leste
<dreamer>
freemangordon: ^
<zmatt>
I was summoned?
<dreamer>
:)
<dreamer>
freemangordon: can you summarize the tiler issue for zmatt? :)
<freemangordon>
zmatt: hi!
<zmatt>
are we talking omap4 or omap5 btw?
<freemangordon>
well, I am having hard time trying to correctly accelerate 2d operations by using PVR @D ops on TILER buffers
<freemangordon>
omap4
<freemangordon>
but should be the same, no?
<freemangordon>
beside cache flags, IIUC
<zmatt>
they're *mostly* the same yes... iirc main difference is that omap5 tiler has separate pagetables for 2d and 1d
<freemangordon>
the same is for omap4, IIUC
<freemangordon>
DMM vs TILER 2d
<freemangordon>
but, I don;t think it makes any difference in the particular scenario
<freemangordon>
so, basically
<freemangordon>
I am implementing xorg EXA that is supposed to accelerate 2D ops by using SGX
<freemangordon>
in 'native' view it is fine
<freemangordon>
BTW, so far I have implemented basic SolidFill only
<freemangordon>
but as POC it should be ok
<zmatt>
right, since omap4 didn't have the separate 2d gpu
<freemangordon>
however, as soon as a TILER bo is allocated (for rotated view), only the upper (maybe) 64 lines are filled
<calebtheythem[m]>
I'm running LOS 14.1 now (i previously tried in TWRP), from what i've seen /dev/ttyHSL0 is the right UART, but nothing
<calebtheythem[m]>
Someone else suggested it might be that the wires I'm using are too long and the signal is getting lost, is that something the droid 4 suffers with?
<freemangordon>
zmatt: to me SGX MMU seems to be correctly setup
<zmatt>
uvos: 4470 you mean
<uvos>
calebtheythem[m]: not really
<freemangordon>
DMA address of the buffer looks fine to me, to the extend I understand how all this is supposed to work
<zmatt>
freemangordon: how many bits/pixel ?
<freemangordon>
unfortunately the extend is not as wide as I would like it to be :D
<freemangordon>
32bpp
<freemangordon>
960x544
<freemangordon>
motorola droid4 that is
<freemangordon>
native orientation is portrait
<uvos>
zmatt: right -70
<freemangordon>
I am using PVR2DBlt for drawing
<freemangordon>
if that makes any difference
<freemangordon>
zmatt: so, SGX core should see *unrotated* DMA address, right?
<uvos>
calebtheythem[m]: very unlikely, but check with a scope/la if you have one
<freemangordon>
BTW, the same BO, when accessed by userspace (mmap-ed) is ok
<calebtheythem[m]>
uvos: I'll take a look with a multimeter, I'm just worried to go chasing hardware issues if it turns out the UART port is just disabled lol
<uvos>
calebtheythem[m]: where do you get the idea that the uart is multiplexed to the usb port btw?
<calebtheythem[m]>
I did some initial mainline porting here - https://github.com/calebccff/linux/commits/asanti-bringup, device just sits on the bootloader splash screen though, probably figuring out how UART works on the downstream kernel is the best place to start
<zmatt>
freemangordon: the orientation seen by masters other than DSS and IVA-HD is configurable per master, but afaik linux always leaves those in normal orientation and just asks DSS to scan the buffer out in whatever orientation is needed
<freemangordon>
mhm
<freemangordon>
my understanding as well
<uvos>
that also makes the most sense
<freemangordon>
but that, why it provides DMA address in TILER address space and not in DMM?
<freemangordon>
I guess the align here is incorrect
<zmatt>
to avoid having to properly align the buffers themselves
<zmatt>
for the pyra kernel I just hacked in proper alignment, at the cost of wasting some tiler virtual space (but that's less a problem on omap5 than omap4)
<freemangordon>
but, how do you setup SGX MMU then?
<freemangordon>
I mean - obviously ATM it uses wrong stride
<zmatt>
never got to that point
<freemangordon>
no 3d acceleration for rotated BOs?
<zmatt>
in fullscreen mode it's more efficient to let sgx do the rotation anyway
<freemangordon>
SGX like glamor?
<freemangordon>
or rather - like GL (rotate through shader)?
<zmatt>
(the ideal solution is to have the sgx wsegl layer report the orientation to the driver which then transparently performs the rotation for you, which is how it's done on android)
<freemangordon>
which driver? kernel mode?
<zmatt>
no the userspace libs
<zmatt>
the API to the (window-)system glue layer includes the ability for that glue layer to report back the desired orientation
<freemangordon>
but how do they rotate? I mean - who is the one that performs the real rotation? 3D core?
<uvos>
wsegl dosent exist in ddk1.17
<uvos>
it was droped with 1.14 no
<uvos>
?
<freemangordon>
that doesn;t really matter
<zmatt>
freemangordon: that's an internal detail but presumably it just applies a rotation to the coordinate system
<zmatt>
uvos: uhh what?
<freemangordon>
most of the functions are still there (for 2D and 3D blits)
<freemangordon>
zmatt: yeah, no longer WSXXX_EGL.so libs
<freemangordon>
everything is done through dma_buf/DRI in 1.17
<freemangordon>
zmatt: it could be a detail, but an important one. on OMAP5 you might not care about the performance, but we aim omap3 here :p
<zmatt>
"might not care about the performance" ? what?
<freemangordon>
I mean - omap5 has 2d core, afaik
<zmatt>
right sgx isn't used for 2d there
<freemangordon>
also, it is times more powerful than omap3, so even if you rotate in SW, FPS will drop by 2-3
<uvos>
but the rotation is perfomed on 3d engine
<uvos>
if it "works like on android"
<freemangordon>
that's what I am asking :)
<freemangordon>
uvos: 3d engine like shader?
<uvos>
no idea how its implemened but on los the tiler data debug data dosent change with rotation. on android the exact implementation is in the propriatary hwcomposer plugin.
<zmatt>
uvos: I was describing how sgx can be asked to do the rotation itself instead (for fullscreen 3d) of using a rotated fb, but that would require a custom wsegl layer
<zmatt>
I'm not sure what solution has been used, I've been out of the loop for a while now
<uvos>
zmatt: sure but how do you rotate the output of the 2d core?
<freemangordon>
so, to sum it up - it seems SGX MMU is not set-up to access the whole rotated BO, given that stride in native orientation for the particular BO is 32 KiB
<zmatt>
uvos: sgx isn't used for 2d
<zmatt>
on omap5
<uvos>
right thats what i mean
<freemangordon>
zmatt: whatever is used, how do you rotate it?
<uvos>
on pyra you draw x elements with the sperate 2d core
<uvos>
how do you rotrate that?
<uvos>
upload it to sgx as a texure and transform it?
<uvos>
or what
<zmatt>
freemangordon: if you did a blit instead of a fill you probably would have noticed the issue of the wrong stride ;)
<zmatt>
freemangordon: (rotation of 3d) 21:02 < zmatt> I'm not sure what solution has been used, I've been out of the loop for a while now
<freemangordon>
zmatt: yeah, but it is more complicated to implement, that's why I started with simple fills
<freemangordon>
and most-probably that's our issue
<zmatt>
freemangordon: a row is indeed not a single BO
<freemangordon>
ok, this explains it
<freemangordon>
at least partially
<zmatt>
but if the buffer is forced to be page-aligned (start address and width in bytes) then you can make it *appear* contiguous using the mmu, that's what I said earlier
<zmatt>
then the stride will seem to be the width rounded up to a multiple of 4KB, same as in userspace
<zmatt>
(or rather, the actual width *will be* the requested width rounded up to a multiple of 4KB)
<zmatt>
each line is then an integral number of pages, so the scatterlist can deal with that and the importer doesn't need to know the details
<freemangordon>
hmm, I guess I shall ask Tomi about that
<freemangordon>
what about allocating the full row for a line?
<zmatt>
(and the stride perceived by sgx is then the same as the stride perceived by userspace)
<zmatt>
that would be even more wasteful without any benefit
<freemangordon>
we will waste TILER space, but so what
<uvos>
tiler space is 128mb
<zmatt>
and it would make the stride different for sgx and for userspace, which sounds like it'll bite you in the ass
<uvos>
and on android the video decoding uses lots of it
<freemangordon>
yeah, right
<freemangordon>
but, userspace stride I see is 4096
<zmatt>
width rounded up to multiple of 4KB
<freemangordon>
so something lies SGX driver about the size of th buffer
<freemangordon>
BTW, we'll have the same issue for VRFB on omap3
<zmatt>
when combined with forcing page-alignment of buffer, it'll mean that if the importer uses the MMU to make the scatterlist seem contiguous, the result is a contiguous buffer with a stride equal to width rounded up to a multiple of 4KB, same as linux userspace
<freemangordon>
mhm
<freemangordon>
I have to verify how is BO imported by SGX driver
<zmatt>
yeah, I don't remember if this patch was tested *at all* yet
<freemangordon>
because all I see is that it receives only TILED address and a size
<freemangordon>
*TILER
<zmatt>
so it's not using dma_buf ?
<freemangordon>
no idea what it does :)
<zmatt>
or does it just fail if given a scatterlist with more than one element?
<freemangordon>
have to check
<freemangordon>
I have a blob function called PVRSRVMapFullDmaBuf()
<zmatt>
that sounds like it would need to be fixed anyway, dma buffers do not generally come with a promise of being contiguous
<freemangordon>
yeah
<freemangordon>
also, I was not able to find a way to allocate TILER GDB BO
<freemangordon>
*GBM
<freemangordon>
zmatt: ok, thanks for the help, I think I now have a better understanding on what is going on
<zmatt>
since the mainline mechanism is excruciatingly slow
<freemangordon>
why not send those for upstreaming?
<zmatt>
because these are hacky patches that basically undo trade-offs mainline chose deliberatley
<zmatt>
*deliberately
<zmatt>
mainline's hack conserves tiler virtual memory space
<freemangordon>
I see
<zmatt>
that had to do with iva-hd iirc
<zmatt>
and omap4 also uses tiler/dmm as a general iommu to make non-contiguous buffers appear contiguous, and on omap4 that uses the same virtual memory space
<freemangordon>
yeah
<zmatt>
which is really awkaward since it caves out awkward non-rectangular chunks of the tiler space
<zmatt>
potentially at least, depends a bit on where it allocates
<zmatt>
on omap5 there's a separate page table used for page mode
<zmatt>
to avoid that problem
<zmatt>
so the patches I did were to maximize performance with little care about wasting tiler virtual space
<freemangordon>
ok, I will have to teach SGX driver to correctly set its MMU for such buffers
<zmatt>
it shouldn't require anything tiler-specific though, just support for non-contiguous dmabufs
<zmatt>
which shouldn't be a problem since it has an MMU to make these appear contiguous to the SGX core
<zmatt>
those kernel messages you pastbinned earlier showed "MMU_MapScatter" which sounds to me like the functionality is there already in the MMU code at least?
<freemangordon>
yeah, will have to look into it
<freemangordon>
"Create a linear mapping for a range of pages at a specified"
<freemangordon>
not really what we need :)
<zmatt>
so why is there "Scatter" in its name then? :P
<freemangordon>
no idea
<freemangordon>
but there is MMU_MapPages with exactly the same comment :)
<zmatt>
oh wait, *list* of pages
<zmatt>
that's scatter indeed
<freemangordon>
where do you see *list*?
<zmatt>
in the mmu.h header
<freemangordon>
I see *range*
<freemangordon>
hmm
<freemangordon>
maybe they copied wrong comment in mmu.c
<zmatt>
oh huh, weird, this patch series didn't get in?
<zmatt>
well, at least it describes the reason
<freemangordon>
yeah
<freemangordon>
any reason why you didn;t send scaterlist fix for upstreaming?
<zmatt>
this was work in progress and that work got interrupted
<freemangordon>
so you work on that no more?
<freemangordon>
shall I take it from here?
<zmatt>
I haven't done anything with this for years
<zmatt>
(I think the relatively recent commit date was because I committed my old uncommitted work in progress for someone else)
<freemangordon>
I see
<zmatt>
and indeed feel free to pick it up
<freemangordon>
ok, I will pick this up, test it and send a proper patch for upstreaming
<zmatt>
it'll need to be rebased first anyway, I see it's committed on top of other hacks/patches
<zmatt>
but that's hopefully not too difficult to unravel
<freemangordon>
I will not cherry-pick, would rather copy/paste. Will see how to give a credit to you when it comes to sending for upstreaming
<freemangordon>
If you don;t mind
mrkrisprolls has quit [Ping timeout: 256 seconds]
<zmatt>
I don't care how it's used or whether/how I'm credited... if it manages to find good use that's already better than it just collecting dust :)
<uvos>
i gues the suggested-by tag is for this case.
<freemangordon>
ok
<zmatt>
be sure to sanity-check it, I'm not particularly experienced with kernel development
<freemangordon>
me neither, so I count on the maintainers to verify :)
<zmatt>
hehe
<freemangordon>
also, we have tmlind here on the channel :p
<freemangordon>
ok, lets try to quickly hack this code in my tree
<zmatt>
it looks like this code is correct even if the BO is not page-aligned, though that obviously can't work with typical importers which want to map entire pages.... so to make this work in practice you'd still need to combine it with forcing page-alignment
<freemangordon>
hmm, why? I mean - in scatterlist you have len and offset for each page?
<zmatt>
yes the scatterlist can specify it, and my code does, which is why I said it looks like this code handles that correctly
<freemangordon>
mhm
<zmatt>
but the SGX mmu can only map entire pages, not part of a page
<freemangordon>
lets see
<zmatt>
(or any MMU for that matter)
<freemangordon>
what about DMM? can it map partial pages only?
<zmatt>
so such buffers are fine if the importer simply uses the scatterlist directly and is trusted to not exceed bounds, but any importer that wants to enforce this using an MMU will need a page-aligned BO
<zmatt>
so, obviously DMM works with entire pages, however due to TILER those become 32x32 pixel blocks (in 32-bit mode)
<zmatt>
so BOs are 128-byte aligned, not 4096-byte aligned
<freemangordon>
Y see
<freemangordon>
*I see
<zmatt>
which can be fixed by passing PAGE_SIZE as the last argument to tiler_reserve_2d()
<zmatt>
instead of 0
<freemangordon>
yeah
<freemangordon>
but I want to see what will happen iw I just pass correct scatterlist to SGX driver
<freemangordon>
*if
<freemangordon>
before changing that
<zmatt>
well there's no possibility (from a hardware point of view) for that to actually work correctly
<freemangordon>
agree, but lets see how wxactly it will fail :)
<freemangordon>
because now it does not fail
<freemangordon>
I mean - does not crash
<zmatt>
be sure to try with a buffer whose misalignment makes it touch more pages than it would if it were aligned ;)
<freemangordon>
most of the times
<zmatt>
no but right now it's certainly clobbering random buffers
<freemangordon>
yes
<zmatt>
*hopefully* graphics buffers and not one of the other users of dmm
<freemangordon>
we don;t have details on SGX MMU
<zmatt>
well in theory the kernel driver source should tell you all you need to know right :)
<freemangordon>
yeah, but SGX driver is not easy to read, you know
<freemangordon>
anyway, lets try to hack some code
<zmatt>
it's a bit gauge-eye-out-with-spoon inducing
<freemangordon>
rebooting the device, lets see :)
<freemangordon>
well, at least display still works :)
<freemangordon>
oopsed on xrand rotation
<dsc_>
are there any QML apps for maemo that work 'well' (in terms of performance)
<dsc_>
maemoleste*
mrkrisprolls has joined #maemo-leste
<uvos>
dsc_: well depends on the hardware
<dsc_>
pretty sure QML will run better than embedding a QWebEngineView (chromium)
<dsc_>
im doing some UIs currently, think ill go with QML right now
pere has joined #maemo-leste
<dsc_>
for practical reasons :P
<dsc_>
we'll have to see how well it performs on hardware
<dsc_>
I think it'll be fine tbh
<dsc_>
I'm not doing crazy shit
<uvos>
Currently qml perfoms farily bad on droid 4
<freemangordon>
YAY!!!
<freemangordon>
it works :)
<uvos>
because it renders in gl and the cpu ends up copying the buffer to the display
<dsc_>
uvos: But ... QWebEngineView worse ;) ?
<uvos>
freemangordon: what works?
<dsc_>
ah ok
<freemangordon>
landscape 2D PVR accelleration :)
<uvos>
dsc_: sure probubly, but a qwidgets app will work mutch better
<uvos>
freemangordon: YAY!!! :P
<uvos>
freemangordon: so everything works now?
<freemangordon>
noo
<uvos>
freemangordon: or what remains?
<freemangordon>
but we are one step closer
<uvos>
ok
<freemangordon>
well, I had to patch both omapdrm and pvr driver
<dsc_>
uvos: for sure, but I'm time limited I suppose. But it is easy to swap out QtQuick for QtWidgets at a later point
<uvos>
not a big deal or? better than how we patch ddk1.9 in...
<freemangordon>
in ddx I ahve to implement accel for copy and composite
<uvos>
ok
<uvos>
copy what?
<freemangordon>
and we need dri3
<uvos>
blit
<freemangordon>
yes
<uvos>
ok
<freemangordon>
blit
<freemangordon>
copy == blit
<uvos>
well for images :P
<freemangordon>
also, XV needs blit accel too
<uvos>
ok great :)
<freemangordon>
oh, lemme see if h-d works now
<uvos>
w/o dri3?
<freemangordon>
sure, we have dri2
<uvos>
that works?
<uvos>
thats suprising to mo
<freemangordon>
yes, it works
<freemangordon>
because of pvr_dri ;)
<freemangordon>
actually, if I implement blit accel it may turn out we don't need dri3
<uvos>
*me
<uvos>
ok hmm i thought mesa needed some special stuff for dri2 in the dri plugins
<uvos>
but maybe im mistaken/out of date
<freemangordon>
omap driver supports dri2
<freemangordon>
well, no idea but it works
<uvos>
no i mean on the mesa side
<uvos>
but its fine
<uvos>
if it works :)
<freemangordon>
hmm, h-d still does not work in landscape
<freemangordon>
PVRRenderBufferInitFromFd: Failed to import device memory for render buffer (PVRSRV_ERROR_INVALID_PARAMS)
<freemangordon>
which is weird, given that glmark-es2 works
<freemangordon>
maybe clutter 0.8 misbehaves
<uvos>
or maybe not glmark-es2 allocates few buffers, a compositor holds a buffer for eatch window