| mighty17[m] | freemangordon: i think i know why phosh doesnt work | 14:18 |
|---|---|---|
| mighty17[m] | `failed to load driver: omapdrm` even with `export MESA_LOADER_DRIVER_OVERRIDE=pvr` , so somehow its hardcoded to use omapdrm? | 14:18 |
| 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` | 14:21 |
| mighty17[m] | but if i do `export MESA_LOADER_DRIVER_OVERRIDE=omapdrm` that does not work | 14:21 |
| mighty17[m] | yup def an issue with it not using pvr_dri.so but instead wanting omapdrm | 15:01 |
| uvos | its using the wrong render node probubly | 15:03 |
| uvos | dosent phosh use wlroots? | 15:03 |
| uvos | ie are you using patched wlroots | 15:03 |
| uvos | also check if its not static linking | 15:04 |
| mighty17[m] | phosh does use wlroots (and phoc) | 15:08 |
| mighty17[m] | uvos: yes, as it works with chromeos mesa anyways | 15:08 |
| mighty17[m] | uvos: with ls -al? | 15:09 |
| uvos | ? | 15:10 |
| uvos | if it dosent use wlroots its irellivant if it uses static linking for something else | 15:10 |
| uvos | oh i read that wrong | 15:11 |
| uvos | yeah check if it links to it dinamicly with ldd | 15:12 |
| mighty17[m] | <uvos> "also check if its not static..." <- i cant seem to find anything about it on phoc/wlroots source code | 15:12 |
| uvos | just ldd the wm | 15:12 |
| uvos | but that would not explain why it works with chomeos mesa anyhow. | 15:13 |
| uvos | other stuff dose work right? | 15:13 |
| mighty17[m] | static linking with omapdrm in source code? | 15:13 |
| uvos | no static linking wlroots therfore using some unpatched version | 15:14 |
| mighty17[m] | it does use wlroots | 15:14 |
| uvos | ldd /usr/bin/phoc or whatever will tell you | 15:14 |
| mighty17[m] | other stuff like kmscube, glmark2-es2-drm does work | 15:19 |
| mighty17[m] | and so does weston | 15:19 |
| uvos | what about something else using wlroots | 15:19 |
| uvos | eg sway | 15:19 |
| mighty17[m] | <uvos> "ldd /usr/bin/phoc or whatever..." <- https://paste.debian.net/1219289/ | 15:21 |
| mighty17[m] | weston does use wlroots doesnt it? | 15:22 |
| uvos | no | 15:22 |
| uvos | so it loads libwlroots.so.7 => /usr/lib/libwlroots.so.7 | 15:23 |
| uvos | did you patch libwlroots? | 15:23 |
| mighty17[m] | anyways for sway i'll need to patch another version of wlroots (0.14) instead of 0.12 that phosh uses | 15:25 |
| mighty17[m] | uvos: https://gitlab.com/antoni.aloytorrens/p-wlroots/-/tree/master/apkbuild | 15:25 |
| 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?! | 15:42 |
| mighty17[m] | so its hardcoded somewhere to only use omapdrm and not pvr? | 15:42 |
| uvos | no pvr is failing for some reason so it trys to load omapdrm | 15:54 |
| uvos | probubly | 15:54 |
| uvos | maybe checkout the section where mesa decides what module to use with gdb | 15:54 |
| mighty17[m] | ah figured it out! | 15:58 |
| mighty17[m] | my starter session was being annoying | 15:58 |
| mighty17[m] | well phosh works now 🎉 | 16:01 |
| freemangordon | mighty17[m]: hmm? it works with HW accelleration? | 18:00 |
| freemangordon | OTOH, seems sgx driver has issues with TILER memory | 18:00 |
| freemangordon | or, it is omapdrm driver that maps wrong addresses | 18:01 |
| freemangordon | tmlind: ^^^ | 18:01 |
| mighty17[m] | freemangordon: Yess!!! | 18:02 |
| freemangordon | good :) | 18:02 |
| mighty17[m] | And no more crashes!! It's really amazing | 18:03 |
| tmlind | freemangordon: not following you, care to clarify on the wrong address part? | 18:11 |
| freemangordon | when I do xrandr rotate and use PVR for accelerated 2d, TILER allocated BOs are wrongly accessed | 18:15 |
| freemangordon | seems like either omapdrm provides wrong dma address to pvr driver or pvr driver gets wrong address mapping for this dma address | 18:16 |
| freemangordon | I guess PVR ends up in omap_gem_pin() when it needs DMA address, right? | 18:17 |
| freemangordon | tmlind: SGX should see TILER addresses, correct? | 18:21 |
| tmlind | no idea how that is supposed to work | 18:22 |
| tmlind | have you looked at the /sys/kernel/debug tiler output? | 18:22 |
| tmlind | that might provide some more info | 18:22 |
| freemangordon | sec | 18:23 |
| freemangordon | will do now | 18:23 |
| freemangordon | anything in particular to look for? | 18:28 |
| freemangordon | it seems there is tiler buffer at address 0x70100000 | 18:29 |
| dreamer | man, we should get zmatt into here. he dived into TILER heavily some time ago | 18:29 |
| freemangordon | please ask him to join | 18:29 |
| dreamer | /invite zmatt | 18:29 |
| dreamer | I poked him in another channel :) | 18:32 |
| freemangordon | thanks | 18:32 |
| tmlind | freemangordon: i recall seeing some memory leak cases under the tiler debugfs entry after several rotations with ddk-1.9 | 18:33 |
| dreamer | because the Pyra uses a phone screen they also needed to do some tiler tricks to get proper fb rotation going | 18:34 |
| dreamer | https://en.wikipedia.org/wiki/DragonBox_Pyra | 18:34 |
| dreamer | btw he also noticed recent merges over @ TI SGX branches. however couple SoCs where left out which seemed odd | 18:34 |
| dreamer | I lost the link to that | 18:35 |
| freemangordon | tmlind: I don;t think we have memleak, seems like another issue to me | 18:35 |
| tmlind | ok, the memory leak was clearly visible with stuff never getting freed in the debug output for tiler | 18:36 |
| freemangordon | it seems like sgx accesses the backing memory addresses, not the tiler addresses] | 18:36 |
| freemangordon | or, the address it gets (how?) is wrong | 18:37 |
| tmlind | heh the "how" part again :) | 18:37 |
| freemangordon | well, what I think happens is: | 18:37 |
| freemangordon | there is PVRSRVMapFullDmaBuf() function in the blobs, which gets BO fd as one of the parameters | 18:38 |
| freemangordon | so I think PVR driver imports this BO, (using some kernel gem_import() or whatever function) into its mmu | 18:39 |
| freemangordon | however, my theory is that this gem_import provides wrong address to SGX driver for TILED BOs | 18:39 |
| dreamer | Pyra is on omap5 so maybe not applicable. only thing I can find currently is: https://www.pyra-handheld.com/wiki/index.php?title=Display#Tiler | 18:41 |
| dreamer | so yeah, need to get him in here. hope he reads the highlight I gave him :# | 18:42 |
| tmlind | freemangordon: hmms so why would 3d stuff work then and 2d not? tiler is being used the same way, no? | 18:44 |
| freemangordon | TILER is not used for 3d stuff | 18:45 |
| freemangordon | to allocate TILER BO one needs to call omap_bo_new_tiled() | 18:45 |
| freemangordon | and this is done only by omap-video driver for scanout buffers | 18:46 |
| tmlind | ok | 18:46 |
| tmlind | hmm but it sort of worked with ddk-1.9 and the same kernel tiler code more or less? | 18:47 |
| freemangordon | I guess it was not using PVR for accelerated 2D | 18:47 |
| freemangordon | you you work with mmap-ed memory only, tehre is no issue | 18:47 |
| freemangordon | *if you | 18:47 |
| tmlind | ok | 18:48 |
| 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? | 18:50 |
| tmlind | see the tiler rotated view addresses int trm at "Table 2-1. Global Memory Space Mapping" | 18:51 |
| tmlind | hmm i guess it would then just not rotate though | 18:51 |
| tmlind | freemangordon: also not that for ddk-1.9 we had the legacy omapdrm ioctl stuff patched back in | 18:54 |
| tmlind | we should not need those ioctl hacks though hopefully at all | 18:55 |
| * tmlind detaching from computer | 19:02 | |
| freemangordon | sorry, phone call | 19:03 |
| uvos | i gues dumping the sgx's mmu table and checking if it has the tiler space mapped is not an option | 19:05 |
| uvos | since no documentation | 19:05 |
| freemangordon | actually driver dumps the table | 19:07 |
| freemangordon | lemme see if I will be able to understand something | 19:12 |
| freemangordon | hmm, looks ok | 19:14 |
| freemangordon | https://pastebin.com/vji9Gbiv | 19:14 |
| freemangordon | if 70100000 is correctly calculated address | 19:15 |
| uvos | well thats the question, no idea :P | 19:20 |
| freemangordon | 70000000 it the base address for 32 bit container | 19:21 |
| freemangordon | not sure 100000 is 90 deg rotation view though | 19:23 |
| freemangordon | oh, but ofc | 19:23 |
| freemangordon | most-probably this is non-rotated TILER view | 19:24 |
| freemangordon | like, base address | 19:24 |
| freemangordon | hmmm | 19:24 |
| freemangordon | how is PVR driver supposed to know what offset to add to this? | 19:24 |
| freemangordon | to get rotated view that is | 19:25 |
| freemangordon | uvos: tmlind: this https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L890 | 19:26 |
| 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. | 19:27 |
| uvos | ah | 19:27 |
| freemangordon | so, omap_gem_rotated_dma_addr() is called only by the framebuffer code | 19:27 |
| freemangordon | based on the rotation that is set to the framebuffer | 19:28 |
| uvos | ah wait | 19:28 |
| uvos | why would sgx want to use the 90deg view? should it not be using 0deg and dss use 90deg view? | 19:29 |
| uvos | or is it the other way around? | 19:29 |
| freemangordon | that's one of the questions I dont; have answers to | 19:29 |
| freemangordon | or, maybe for tiler bos I shall transpose? | 19:30 |
| freemangordon | lemem try | 19:30 |
| freemangordon | *lemme | 19:30 |
| freemangordon | uvos: I think it shall see rotated TILER address, how it is supposed to draw a line (rotated) if not. | 19:49 |
| uvos | freemangordon: you draw a line using the non rotated view and the rotated view is then scanned out? | 19:50 |
| uvos | freemangordon: how else is it supposed to work? | 19:50 |
| freemangordon | hmm | 19:50 |
| uvos | freemangordon: if you draw a line into the rotated view and also scann it out you get no change no? | 19:50 |
| freemangordon | but then why I see it draw mostly out of screen | 19:50 |
| freemangordon | lemme take a picture to show what I mean | 19:51 |
| uvos | the buffer your allocating is the wrong size maybe? | 19:53 |
| freemangordon | not, it is fine | 19:54 |
| freemangordon | if you acces it through mmap it is ok | 19:54 |
| freemangordon | only pvr2d sees it wrong | 19:54 |
| freemangordon | ok, seems we have negative offset on y | 19:55 |
| uvos | the header pvr gets might be wrong? sees a 540x960 buffer in landscape? | 19:55 |
| uvos | i gues the line would be more than ofset then (it would be spread all over the place) | 19:55 |
| uvos | negavtive y in what space? native display or rotated buffer? | 19:57 |
| freemangordon | I see only top (maybe) 256 pixels painted in the fill color | 19:58 |
| uvos | top being the top in native orientaion? | 19:58 |
| freemangordon | no, top in rotated orientation | 19:59 |
| uvos | ok that excludes the possible pvr thinks its drawing into a 540x960 buffer | 20:00 |
| uvos | *possibility | 20:00 |
| freemangordon | yeah | 20:00 |
| uvos | no idea then, fun :) | 20:01 |
| freemangordon | if I hardcode X size, it is ok, like if I hardcode 512, I have 512x? blue rectangle | 20:02 |
| freemangordon | but I cannot extend on vertical | 20:02 |
| freemangordon | so it seems to try to draw correct thing | 20:02 |
| freemangordon | hmm, maybe this is 64 lines | 20:02 |
| 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? | 20:14 |
| 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 | 20:16 |
| uvos | on the d4 the android kernel never dose anything with the uart (iirc its not even configured in dts) | 20:16 |
| uvos | so you have to kexec somewhere else if you want to use it | 20:17 |
| uvos | like los maybe | 20:17 |
| dreamer | freemangordon: ^ | 20:17 |
| zmatt | I was summoned? | 20:17 |
| dreamer | :) | 20:17 |
| dreamer | freemangordon: can you summarize the tiler issue for zmatt? :) | 20:18 |
| freemangordon | zmatt: hi! | 20:18 |
| zmatt | are we talking omap4 or omap5 btw? | 20:19 |
| freemangordon | well, I am having hard time trying to correctly accelerate 2d operations by using PVR @D ops on TILER buffers | 20:19 |
| freemangordon | omap4 | 20:19 |
| freemangordon | but should be the same, no? | 20:19 |
| freemangordon | beside cache flags, IIUC | 20:20 |
| zmatt | they're *mostly* the same yes... iirc main difference is that omap5 tiler has separate pagetables for 2d and 1d | 20:20 |
| freemangordon | the same is for omap4, IIUC | 20:20 |
| freemangordon | DMM vs TILER 2d | 20:20 |
| freemangordon | but, I don;t think it makes any difference in the particular scenario | 20:21 |
| freemangordon | so, basically | 20:21 |
| freemangordon | I am implementing xorg EXA that is supposed to accelerate 2D ops by using SGX | 20:21 |
| freemangordon | in 'native' view it is fine | 20:22 |
| freemangordon | BTW, so far I have implemented basic SolidFill only | 20:22 |
| freemangordon | but as POC it should be ok | 20:22 |
| zmatt | right, since omap4 didn't have the separate 2d gpu | 20:22 |
| freemangordon | however, as soon as a TILER bo is allocated (for rotated view), only the upper (maybe) 64 lines are filled | 20:23 |
| freemangordon | with the fill color that is | 20:23 |
| uvos | zmatt: except -60 :P | 20:23 |
| freemangordon | look at https://pastebin.com/vji9Gbiv | 20:23 |
| uvos | \me pedantic | 20:23 |
| * uvos pedantic | 20:23 | |
| 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 | 20:23 |
| 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? | 20:23 |
| freemangordon | zmatt: to me SGX MMU seems to be correctly setup | 20:24 |
| zmatt | uvos: 4470 you mean | 20:24 |
| uvos | calebtheythem[m]: not really | 20:24 |
| freemangordon | DMA address of the buffer looks fine to me, to the extend I understand how all this is supposed to work | 20:24 |
| zmatt | freemangordon: how many bits/pixel ? | 20:24 |
| freemangordon | unfortunately the extend is not as wide as I would like it to be :D | 20:25 |
| freemangordon | 32bpp | 20:25 |
| freemangordon | 960x544 | 20:25 |
| freemangordon | motorola droid4 that is | 20:25 |
| freemangordon | native orientation is portrait | 20:25 |
| uvos | zmatt: right -70 | 20:26 |
| freemangordon | I am using PVR2DBlt for drawing | 20:26 |
| freemangordon | if that makes any difference | 20:26 |
| freemangordon | zmatt: so, SGX core should see *unrotated* DMA address, right? | 20:27 |
| uvos | calebtheythem[m]: very unlikely, but check with a scope/la if you have one | 20:27 |
| freemangordon | BTW, the same BO, when accessed by userspace (mmap-ed) is ok | 20:28 |
| 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 | 20:28 |
| uvos | calebtheythem[m]: where do you get the idea that the uart is multiplexed to the usb port btw? | 20:29 |
| 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 | 20:29 |
| 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 | 20:29 |
| freemangordon | mhm | 20:29 |
| freemangordon | my understanding as well | 20:29 |
| uvos | that also makes the most sense | 20:29 |
| freemangordon | but that, why it provides DMA address in TILER address space and not in DMM? | 20:30 |
| freemangordon | *but then | 20:30 |
| calebtheythem[m] | uvos: this driver is built on downstream and shows up in logs https://github.com/MotorolaMobilityLLC/kernel-msm/blob/kitkat-mr1-rel-razrm/drivers/mfd/emu-det.c | 20:30 |
| freemangordon | omapdrm that is | 20:30 |
| zmatt | I don't know what you mean by that... linux uses the words tiler and dmm in a way that doesn't actually match hardware meaning | 20:30 |
| freemangordon | rotated BOs are allocated in TILER 2d | 20:31 |
| uvos | you have to draw into tiler space for caching purposes maybe? | 20:31 |
| zmatt | rotatable BOs would be a better term | 20:31 |
| freemangordon | ok, will use that | 20:31 |
| zmatt | you have to draw into tiler space | 20:31 |
| freemangordon | uvos: yeah, maube | 20:31 |
| freemangordon | *maybe | 20:31 |
| freemangordon | zmatt: ok | 20:31 |
| zmatt | the underlying ram has the pixels totally jumbled up | 20:32 |
| freemangordon | hmm, wait, why so? | 20:32 |
| zmatt | because tiler turns 2d spatial locality into 1d spatial locality | 20:32 |
| uvos | calebtheythem[m]: ok | 20:32 |
| freemangordon | ok | 20:32 |
| freemangordon | anyway, this is detail that I don't think matters for the issue | 20:33 |
| zmatt | so like, each 32x32 block of pixels is one page of underlying ram (... sort of, ignoring interleaving) | 20:33 |
| freemangordon | ok, so, do you think SGX MMU is correctly set up? https://pastebin.com/vji9Gbiv | 20:34 |
| uvos | calebtheythem[m]: i dont think we can help your really the xt897's hardware is totaly different from xt860/xt875/xt894 | 20:34 |
| uvos | calebtheythem[m]: besides me having one i dont think anyone here has had any interaction with one | 20:35 |
| freemangordon | 0x70000000 is the start of 32 bpp TILER space, IIUC | 20:35 |
| freemangordon | but then, why 0x100000 offset? this is "native" view or what? | 20:35 |
| uvos | like the uart behavior/multiplexing on xt894 is controled by its custom motorola pmic | 20:36 |
| calebtheythem[m] | uvos: yeah i suspected as much, thanks anyway. Hopefully I'll be able to track down UART on the JTAG header and go from there. | 20:36 |
| uvos | which you dont have | 20:36 |
| uvos | yeah :) | 20:36 |
| calebtheythem[m] | oh interesting | 20:36 |
| freemangordon | hmm, wait, what is the stride of rotatable BOs? | 20:39 |
| freemangordon | 4096? | 20:39 |
| zmatt | freemangordon: https://pastebin.com/raw/n7zUGyxS | 20:39 |
| zmatt | that's how addresses in tiler virtual space are decoded | 20:39 |
| freemangordon | si, it is row 16 in 32bit space, IIUC | 20:42 |
| freemangordon | *sp | 20:42 |
| freemangordon | aah | 20:42 |
| freemangordon | so | 20:42 |
| freemangordon | not that I understand what is this supposed to mean | 20:42 |
| zmatt | more detailed: https://pastebin.com/raw/H1hATHRU | 20:43 |
| zmatt | the ypage and xpage parts are combined to select a page | 20:43 |
| freemangordon | so, this is not linear? | 20:44 |
| zmatt | no, that's what I said: each 32x32-pixel block (for 32-bit mode) is a single 4K page | 20:44 |
| zmatt | 64x32-pixel for 16-bit mode, 64x64-pixel for 8-bit mode | 20:45 |
| freemangordon | I mean 'linear' in terms of addressing | 20:45 |
| zmatt | I'm not sure what you mean by that... the tiler virtual space is a single giant big rectangle of pixels from which you carve your buffers | 20:46 |
| freemangordon | I mean in terms of SGX MMU | 20:46 |
| freemangordon | lemme do some calculations | 20:46 |
| zmatt | buffers are not contiguous, unless you're actually using the entire width (8192 pixels in 32-bit mode) | 20:47 |
| freemangordon | so, stride is 8192? | 20:47 |
| freemangordon | oh, 8192*4 | 20:47 |
| freemangordon | is that correct? | 20:48 |
| zmatt | 8Kpixels, 32KB yes | 20:48 |
| zmatt | (32KB in 16- and 32-bit mode, 16KB in 8-bit mode) | 20:48 |
| freemangordon | ah, so maybe thats why it draws on only a small part of the screen | 20:48 |
| freemangordon | hmm, who is supposed to provide the correct stride to sgx driver? | 20:49 |
| freemangordon | basically it imports gem bufefr | 20:49 |
| zmatt | ¯\_(ツ)_/¯ | 20:49 |
| zmatt | you probably want to hide the real stride anyway | 20:50 |
| zmatt | similar to how it's hidden from userspace | 20:50 |
| zmatt | using the mmu | 20:50 |
| freemangordon | which mmu? SGX one? | 20:50 |
| zmatt | (but that's only really possible if buffers are page-aligned in tiler space) | 20:50 |
| zmatt | the sgx one for sgx, the arm one for userspace | 20:50 |
| zmatt | though mainline linux does a gross and really inefficient hack for userspace | 20:51 |
| freemangordon | MMU_Alloc: uSize=0x1fe000, flags=0x0, align=0x1000 | 20:51 |
| freemangordon | I guess the align here is incorrect | 20:51 |
| zmatt | to avoid having to properly align the buffers themselves | 20:51 |
| 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) | 20:52 |
| freemangordon | but, how do you setup SGX MMU then? | 20:52 |
| freemangordon | I mean - obviously ATM it uses wrong stride | 20:53 |
| zmatt | never got to that point | 20:53 |
| freemangordon | no 3d acceleration for rotated BOs? | 20:54 |
| zmatt | in fullscreen mode it's more efficient to let sgx do the rotation anyway | 20:54 |
| freemangordon | SGX like glamor? | 20:54 |
| freemangordon | or rather - like GL (rotate through shader)? | 20:55 |
| 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) | 20:55 |
| freemangordon | which driver? kernel mode? | 20:55 |
| zmatt | no the userspace libs | 20:55 |
| zmatt | the API to the (window-)system glue layer includes the ability for that glue layer to report back the desired orientation | 20:56 |
| freemangordon | but how do they rotate? I mean - who is the one that performs the real rotation? 3D core? | 20:56 |
| uvos | wsegl dosent exist in ddk1.17 | 20:56 |
| uvos | it was droped with 1.14 no | 20:56 |
| uvos | ? | 20:56 |
| freemangordon | that doesn;t really matter | 20:56 |
| zmatt | freemangordon: that's an internal detail but presumably it just applies a rotation to the coordinate system | 20:56 |
| zmatt | uvos: uhh what? | 20:56 |
| freemangordon | most of the functions are still there (for 2D and 3D blits) | 20:57 |
| freemangordon | zmatt: yeah, no longer WSXXX_EGL.so libs | 20:57 |
| freemangordon | everything is done through dma_buf/DRI in 1.17 | 20:58 |
| 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 | 20:58 |
| zmatt | "might not care about the performance" ? what? | 20:59 |
| freemangordon | I mean - omap5 has 2d core, afaik | 20:59 |
| zmatt | right sgx isn't used for 2d there | 20:59 |
| freemangordon | also, it is times more powerful than omap3, so even if you rotate in SW, FPS will drop by 2-3 | 21:00 |
| uvos | but the rotation is perfomed on 3d engine | 21:00 |
| uvos | if it "works like on android" | 21:00 |
| freemangordon | that's what I am asking :) | 21:00 |
| freemangordon | uvos: 3d engine like shader? | 21:00 |
| 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. | 21:02 |
| 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 | 21:02 |
| zmatt | I'm not sure what solution has been used, I've been out of the loop for a while now | 21:02 |
| uvos | zmatt: sure but how do you rotate the output of the 2d core? | 21:03 |
| 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 | 21:03 |
| zmatt | uvos: sgx isn't used for 2d | 21:03 |
| zmatt | on omap5 | 21:03 |
| uvos | right thats what i mean | 21:03 |
| freemangordon | zmatt: whatever is used, how do you rotate it? | 21:03 |
| uvos | on pyra you draw x elements with the sperate 2d core | 21:04 |
| uvos | how do you rotrate that? | 21:04 |
| uvos | upload it to sgx as a texure and transform it? | 21:04 |
| uvos | or what | 21:04 |
| zmatt | freemangordon: if you did a blit instead of a fill you probably would have noticed the issue of the wrong stride ;) | 21:04 |
| 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 | 21:05 |
| freemangordon | zmatt: yeah, but it is more complicated to implement, that's why I started with simple fills | 21:05 |
| zmatt | heh, btw this is what you get when you bypass TILER when drawing an image: https://liktaanjeneus.nl/very-tiled-fbdev.jpg | 21:06 |
| zmatt | (but then display it using TILER) | 21:06 |
| uvos | pretty | 21:06 |
| freemangordon | nice :) | 21:06 |
| zmatt | iirc because I used write() on the fbdev and this turned out to works incorrectly for tiled buffers | 21:07 |
| * freemangordon checkes how SGX driver imports omap_bo BOs | 21:07 | |
| zmatt | first question would be, how are they exported? | 21:07 |
| zmatt | iirc even that was broken | 21:07 |
| freemangordon | they are exported as FDs | 21:08 |
| zmatt | that's not what I meant | 21:08 |
| freemangordon | but what? | 21:08 |
| freemangordon | provided DMA address seems correct to me | 21:08 |
| zmatt | the tiled buffer is non-contiguous and possibly not even page-aligned, is its scatterlist correct? | 21:08 |
| freemangordon | should be | 21:09 |
| freemangordon | why you said it is non-contiguous? | 21:09 |
| freemangordon | the backing RAM is not, but it's addressed through DMM, IIUC | 21:09 |
| zmatt | because its stride is much larger than its width, and that space belongs to other buffers | 21:09 |
| freemangordon | ah | 21:10 |
| freemangordon | oh | 21:10 |
| freemangordon | omg | 21:10 |
| freemangordon | I see what you mean | 21:10 |
| buZz | hi zmatt \o/ | 21:10 |
| freemangordon | hmm.... | 21:10 |
| freemangordon | so, a 'row' is not assigned to a single BO? | 21:11 |
| freemangordon | ok, seems SGX expects contiguous memory | 21:11 |
| zmatt | freemangordon: I know this is something I was working on at some point, but I don't really remember any details about it: https://github.com/mvduin/linux/commit/78b2f59352a2697590a7b9ed8ffed1ad7f98b98d | 21:11 |
| freemangordon | and most-probably that's our issue | 21:11 |
| zmatt | freemangordon: a row is indeed not a single BO | 21:12 |
| freemangordon | ok, this explains it | 21:12 |
| freemangordon | at least partially | 21:12 |
| 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 | 21:13 |
| zmatt | then the stride will seem to be the width rounded up to a multiple of 4KB, same as in userspace | 21:13 |
| zmatt | (or rather, the actual width *will be* the requested width rounded up to a multiple of 4KB) | 21:13 |
| 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 | 21:14 |
| freemangordon | hmm, I guess I shall ask Tomi about that | 21:15 |
| freemangordon | what about allocating the full row for a line? | 21:15 |
| zmatt | (and the stride perceived by sgx is then the same as the stride perceived by userspace) | 21:15 |
| zmatt | that would be even more wasteful without any benefit | 21:15 |
| freemangordon | we will waste TILER space, but so what | 21:15 |
| uvos | tiler space is 128mb | 21:16 |
| zmatt | and it would make the stride different for sgx and for userspace, which sounds like it'll bite you in the ass | 21:16 |
| uvos | and on android the video decoding uses lots of it | 21:16 |
| freemangordon | yeah, right | 21:16 |
| freemangordon | but, userspace stride I see is 4096 | 21:16 |
| zmatt | width rounded up to multiple of 4KB | 21:16 |
| freemangordon | so something lies SGX driver about the size of th buffer | 21:16 |
| freemangordon | size=0x1fe000 | 21:17 |
| zmatt | btw forcing page alignment is like a single-line change, or at least it was in 4.19: https://github.com/mvduin/linux/commit/6629b3a97bf30fd59c4eb941087a3fca1ac48471 | 21:17 |
| freemangordon | 0x1fe000 = 960x544x4 | 21:18 |
| zmatt | so yeah, that WiP patch ( https://github.com/mvduin/linux/commit/78b2f59352a2697590a7b9ed8ffed1ad7f98b98d ) looks like for 2d buffers I create a scatterlist with one entry per line of the buffer | 21:20 |
| freemangordon | BTW, we'll have the same issue for VRFB on omap3 | 21:21 |
| 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 | 21:21 |
| freemangordon | mhm | 21:22 |
| freemangordon | I have to verify how is BO imported by SGX driver | 21:23 |
| zmatt | yeah, I don't remember if this patch was tested *at all* yet | 21:23 |
| freemangordon | because all I see is that it receives only TILED address and a size | 21:24 |
| freemangordon | *TILER | 21:24 |
| zmatt | so it's not using dma_buf ? | 21:25 |
| freemangordon | no idea what it does :) | 21:25 |
| zmatt | or does it just fail if given a scatterlist with more than one element? | 21:25 |
| freemangordon | have to check | 21:25 |
| freemangordon | I have a blob function called PVRSRVMapFullDmaBuf() | 21:26 |
| zmatt | that sounds like it would need to be fixed anyway, dma buffers do not generally come with a promise of being contiguous | 21:26 |
| freemangordon | yeah | 21:26 |
| freemangordon | also, I was not able to find a way to allocate TILER GDB BO | 21:27 |
| freemangordon | *GBM | 21:27 |
| freemangordon | zmatt: ok, thanks for the help, I think I now have a better understanding on what is going on | 21:29 |
| zmatt | I also force page-alignment of buffers to allow for fast userspace mapping: https://github.com/mvduin/linux/commit/a8612b1ca3e69afa551b8d9605b72c5acbeb859e | 21:29 |
| zmatt | since the mainline mechanism is excruciatingly slow | 21:30 |
| freemangordon | why not send those for upstreaming? | 21:30 |
| zmatt | because these are hacky patches that basically undo trade-offs mainline chose deliberatley | 21:31 |
| zmatt | *deliberately | 21:31 |
| zmatt | mainline's hack conserves tiler virtual memory space | 21:31 |
| freemangordon | I see | 21:32 |
| zmatt | that had to do with iva-hd iirc | 21:33 |
| 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 | 21:34 |
| freemangordon | yeah | 21:34 |
| zmatt | which is really awkaward since it caves out awkward non-rectangular chunks of the tiler space | 21:34 |
| zmatt | potentially at least, depends a bit on where it allocates | 21:35 |
| zmatt | on omap5 there's a separate page table used for page mode | 21:36 |
| zmatt | to avoid that problem | 21:36 |
| zmatt | so the patches I did were to maximize performance with little care about wasting tiler virtual space | 21:37 |
| freemangordon | ok, I will have to teach SGX driver to correctly set its MMU for such buffers | 21:38 |
| zmatt | it shouldn't require anything tiler-specific though, just support for non-contiguous dmabufs | 21:38 |
| zmatt | which shouldn't be a problem since it has an MMU to make these appear contiguous to the SGX core | 21:39 |
| 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? | 21:40 |
| freemangordon | yeah, will have to look into it | 21:44 |
| freemangordon | "Create a linear mapping for a range of pages at a specified" | 21:45 |
| freemangordon | not really what we need :) | 21:46 |
| zmatt | so why is there "Scatter" in its name then? :P | 21:46 |
| freemangordon | no idea | 21:46 |
| freemangordon | but there is MMU_MapPages with exactly the same comment :) | 21:47 |
| zmatt | oh wait, *list* of pages | 21:48 |
| zmatt | that's scatter indeed | 21:48 |
| freemangordon | where do you see *list*? | 21:48 |
| zmatt | in the mmu.h header | 21:48 |
| freemangordon | I see *range* | 21:48 |
| freemangordon | hmm | 21:48 |
| freemangordon | maybe they copied wrong comment in mmu.c | 21:49 |
| zmatt | https://git.ti.com/cgit/graphics/omap5-sgx-ddk-linux/tree/eurasia_km/services4/srvkm/devices/sgx/mmu.h?h=ti-img-sgx/1.17.4948957/k4.19#n312 | 21:50 |
| freemangordon | same here, but see the comment in mmu.c | 21:50 |
| zmatt | yeah, copy-paste error | 21:51 |
| freemangordon | mhm | 21:51 |
| freemangordon | ok, lemme see how that worls | 21:51 |
| freemangordon | yeah, this will map pages | 21:52 |
| freemangordon | like list of pages | 21:53 |
| freemangordon | hmm, seems SGX driver does its job through dma_buf API | 22:15 |
| freemangordon | so, it calls dma_buf_map_attachment() and gets scatterlist | 22:17 |
| freemangordon | so, it seems this list is incorrect | 22:17 |
| zmatt | which makes sense, it was broken when I last worked on it and TILER probably hasn't gotten much love and attention since then | 22:34 |
| freemangordon | ok, lemme see if I get that correctly | 22:37 |
| freemangordon | it seems omap_gem_map_dma_buf creates scatterlist for a single contiguous memory block | 22:39 |
| freemangordon | which is absolutely wrong | 22:39 |
| zmatt | yep | 22:40 |
| freemangordon | I see now what happesnt | 22:40 |
| freemangordon | so, I have to create a correct scatterlist there and all will start working correctly | 22:40 |
| zmatt | that's what I was working on fixing in https://github.com/mvduin/linux/commit/78b2f59352a2697590a7b9ed8ffed1ad7f98b98d | 22:40 |
| zmatt | (I don't remember how far I got, it could be anywhere from "doesn't even compile" to "works perfectly") | 22:41 |
| freemangordon | :D | 22:41 |
| freemangordon | was about to ask - does it works | 22:41 |
| freemangordon | *work | 22:41 |
| freemangordon | do you remember why this change? https://github.com/mvduin/linux/commit/78b2f59352a2697590a7b9ed8ffed1ad7f98b98d#diff-9b3c6ba4dcbd05c07bafe254dd7bc5fd1ac42fede2f7d43aa8250a20c31eecb3L1339 | 22:45 |
| zmatt | that's fixed in mainline anyway | 22:47 |
| zmatt | https://www.lkml.org/lkml/2020/6/18/687 | 22:47 |
| zmatt | I probably made the same observation while working on this patch | 22:48 |
| freemangordon | not really https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L1296 | 22:50 |
| freemangordon | I mean - this is not in mainline | 22:50 |
| zmatt | oh huh, weird, this patch series didn't get in? | 22:50 |
| zmatt | well, at least it describes the reason | 22:51 |
| freemangordon | yeah | 22:52 |
| freemangordon | any reason why you didn;t send scaterlist fix for upstreaming? | 22:52 |
| zmatt | this was work in progress and that work got interrupted | 22:52 |
| freemangordon | so you work on that no more? | 22:53 |
| freemangordon | shall I take it from here? | 22:53 |
| zmatt | I haven't done anything with this for years | 22:53 |
| zmatt | (I think the relatively recent commit date was because I committed my old uncommitted work in progress for someone else) | 22:54 |
| freemangordon | I see | 22:54 |
| zmatt | and indeed feel free to pick it up | 22:54 |
| freemangordon | ok, I will pick this up, test it and send a proper patch for upstreaming | 22:54 |
| zmatt | it'll need to be rebased first anyway, I see it's committed on top of other hacks/patches | 22:55 |
| zmatt | but that's hopefully not too difficult to unravel | 22:56 |
| 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 | 22:56 |
| freemangordon | If you don;t mind | 22:57 |
| 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 :) | 22:57 |
| uvos | i gues the suggested-by tag is for this case. | 22:57 |
| freemangordon | ok | 22:58 |
| zmatt | be sure to sanity-check it, I'm not particularly experienced with kernel development | 22:58 |
| freemangordon | me neither, so I count on the maintainers to verify :) | 22:59 |
| zmatt | hehe | 22:59 |
| freemangordon | also, we have tmlind here on the channel :p | 23:00 |
| freemangordon | ok, lets try to quickly hack this code in my tree | 23:01 |
| 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 | 23:04 |
| freemangordon | hmm, why? I mean - in scatterlist you have len and offset for each page? | 23:04 |
| zmatt | yes the scatterlist can specify it, and my code does, which is why I said it looks like this code handles that correctly | 23:05 |
| freemangordon | mhm | 23:05 |
| zmatt | but the SGX mmu can only map entire pages, not part of a page | 23:05 |
| freemangordon | lets see | 23:05 |
| zmatt | (or any MMU for that matter) | 23:05 |
| freemangordon | what about DMM? can it map partial pages only? | 23:06 |
| 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 | 23:07 |
| zmatt | so, obviously DMM works with entire pages, however due to TILER those become 32x32 pixel blocks (in 32-bit mode) | 23:07 |
| zmatt | so BOs are 128-byte aligned, not 4096-byte aligned | 23:08 |
| freemangordon | Y see | 23:08 |
| freemangordon | *I see | 23:08 |
| zmatt | which can be fixed by passing PAGE_SIZE as the last argument to tiler_reserve_2d() | 23:09 |
| zmatt | instead of 0 | 23:09 |
| freemangordon | yeah | 23:09 |
| freemangordon | but I want to see what will happen iw I just pass correct scatterlist to SGX driver | 23:09 |
| freemangordon | *if | 23:10 |
| freemangordon | before changing that | 23:10 |
| zmatt | well there's no possibility (from a hardware point of view) for that to actually work correctly | 23:10 |
| freemangordon | agree, but lets see how wxactly it will fail :) | 23:11 |
| freemangordon | because now it does not fail | 23:11 |
| freemangordon | I mean - does not crash | 23:11 |
| zmatt | be sure to try with a buffer whose misalignment makes it touch more pages than it would if it were aligned ;) | 23:11 |
| freemangordon | most of the times | 23:11 |
| zmatt | no but right now it's certainly clobbering random buffers | 23:12 |
| freemangordon | yes | 23:12 |
| zmatt | *hopefully* graphics buffers and not one of the other users of dmm | 23:12 |
| freemangordon | we don;t have details on SGX MMU | 23:12 |
| zmatt | well in theory the kernel driver source should tell you all you need to know right :) | 23:13 |
| freemangordon | yeah, but SGX driver is not easy to read, you know | 23:13 |
| freemangordon | anyway, lets try to hack some code | 23:13 |
| zmatt | it's a bit gauge-eye-out-with-spoon inducing | 23:13 |
| freemangordon | rebooting the device, lets see :) | 23:28 |
| freemangordon | well, at least display still works :) | 23:29 |
| freemangordon | oopsed on xrand rotation | 23:30 |
| dsc_ | are there any QML apps for maemo that work 'well' (in terms of performance) | 23:45 |
| dsc_ | maemoleste* | 23:45 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
