| freemangordon | tmlind: trying to devmem2 on anything in the range from 0x5000FE00 to 0x5000FF0C gives bus error (and 'external abort on non-linefetch'), so OCP on 3430 *must not* be touched | 07:45 |
|---|---|---|
| freemangordon | IIUC | 07:45 |
| freemangordon | I wonder if https://elixir.bootlin.com/linux/v5.15-rc5/source/drivers/bus/ti-sysc.c#L1499 is correct at all, given that it is executed unconditionally, no? | 07:46 |
| tmlind | freemangordon: hmm i'm pretty sure i tested that when adding it, did you do echo on > control for the module before reading? | 07:48 |
| freemangordon | kmscube is running while I am trying to read those vals | 07:49 |
| freemangordon | lemme do what you say (control) | 07:49 |
| tmlind | ok, yeah that's the ocp range, right? that is broken on 34xx afaik, so yeah if the ti-sysc sgx quirk is applied for 34xx instead of 36xx we need to fix it | 07:49 |
| freemangordon | maybe it is not applied, but anyways ti-sysc tries to read memory that's not accessible | 07:50 |
| tmlind | it is enabled based on the sgx revision register, if it was enabled for 34xx, sounds like you should see errors all the time when idling sgx | 07:51 |
| tmlind | actually when enabling sgx | 07:51 |
| tmlind | note the comments in the dts on how we read the sgx ip rev register, not the ocp register on 34xx unlike on 36xx | 07:52 |
| freemangordon | tmlind: I disabled pvr from touching OCP and everything works now, see backscroll | 07:52 |
| tmlind | yeah nice :) | 07:52 |
| freemangordon | but, ti-sysc will try to read OCP revision with your omap3-prm-gfx.patch, no? | 07:53 |
| tmlind | with the runtime pm in use with ti-sysc we should not tinker with the ocp regs in the pvrsgx driver at all | 07:53 |
| freemangordon | this https://elixir.bootlin.com/linux/v5.15-rc5/source/drivers/bus/ti-sysc.c#L1499 | 07:53 |
| tmlind | freemangordon: see the 34xx dtsi vs 36xx dtsi | 07:53 |
| freemangordon | don;t understand | 07:54 |
| freemangordon | isn't the code ^^ going to read 0x5000ff08 to try to detect 3630? | 07:54 |
| tmlind | for 34xx rev is not configured that way so no match | 07:55 |
| freemangordon | so, it matches only the first entry in that table (ti-sysc I mean)? | 07:56 |
| tmlind | for 34xx we have rev reg = <0x50000014 0x4>; | 07:56 |
| freemangordon | and once it matches rev 121 it will ignore the next entry? | 07:57 |
| tmlind | it matches the address and the mapped register offsets as the revision register alone may not be unique | 07:57 |
| freemangordon | ah, ok, so it uses the data from dts to match against revision address and then reads revision reg to match the revision? | 07:58 |
| freemangordon | so, it will not match 3430, ok | 07:58 |
| tmlind | yeah as we can't just blindly attempt to read the revision register unfortunately :) | 07:58 |
| freemangordon | I was under the impression this is what we do :) | 07:59 |
| freemangordon | otherwise I don;t understand why you patch changes the behavior | 07:59 |
| tmlind | which patch? | 07:59 |
| freemangordon | omap3-prm-gfx.patch | 07:59 |
| tmlind | that just configure the prm register, do you still need to disable off mode or something? | 08:00 |
| freemangordon | well, "was changing" as I didn;t try it with SGX_OCP_REGS_ENABLED commented out | 08:00 |
| freemangordon | so maybe I shall try it | 08:00 |
| tmlind | ah ok, yeah | 08:00 |
| freemangordon | going to | 08:01 |
| tmlind | we should just remove the whole SGX_OCP_REGS_ENABLED code for 1.17 directory as it's confusing | 08:01 |
| tmlind | what a time waster trying to see what the pvrsgx code is doing :( | 08:01 |
| freemangordon | we should remove SGX_OCP_REGS_ENABLED for 3430 only | 08:02 |
| freemangordon | not sure how to detect that though | 08:02 |
| tmlind | afaik there should be no need to keep it for any hardware with pm runtime available in the linux kernel | 08:02 |
| freemangordon | or, for rev 121, not sure what is correct | 08:02 |
| freemangordon | SGX_OCP_REGS_ENABLED also enables code that enables/disables interrupts | 08:03 |
| tmlind | i think that's only the thalia quirk that we already handle with runtime pm in ti-sysc | 08:03 |
| freemangordon | no, it is not | 08:04 |
| freemangordon | check the code | 08:04 |
| tmlind | well we should just move that code to the pvrdrv.c to either runtime functions or interrupt related functions | 08:04 |
| tmlind | ah so do you have SysEnableSGXInterrupts enabled now? | 08:06 |
| tmlind | without SGX_OCP_REGS_ENABLED? | 08:06 |
| freemangordon | no | 08:06 |
| freemangordon | I mean it is a noop, IIUC | 08:06 |
| freemangordon | #defineSysEnableSGXInterrupts(psSysData) | 08:06 |
| freemangordon | but, interrupts still work fine | 08:07 |
| tmlind | hmm we can just remove that crap, SysEnableSGXInterrupts just enables the thalia quirk | 08:07 |
| freemangordon | not really | 08:08 |
| freemangordon | OSWriteHWReg(gpvOCPRegsLinAddr, EUR_CR_OCP_IRQENABLE_SET_2, 0x1); | 08:08 |
| tmlind | oh it does toggle something, ok so let's move it to the pvrdrv where it belongs | 08:08 |
| freemangordon | ok, but please, disable all this crap for 3430 :) | 08:09 |
| tmlind | so how do you have interrupts working for 34xx then? no way to mask them? | 08:09 |
| freemangordon | by enabling SYS_USING_INTERRUPTS | 08:10 |
| freemangordon | why would I want to mask interrupts? | 08:10 |
| tmlind | with SGX_OCP_REGS_ENABLED commented out so SysEnableSGXInterrupts does nothing? | 08:11 |
| freemangordon | yes | 08:11 |
| tmlind | ok yeah so must not touch the ocp regs on 34xx, others should have the interrupt handler in pvr-drv.c | 08:11 |
| tmlind | the interrupt enable/disable in pvr-drv.c | 08:11 |
| freemangordon | I commented out lines 104-107 in syslocal.h | 08:12 |
| freemangordon | and enabled SUPPORT_ACTIVE_POWER_MANAGEMENT and SYS_USING_INTERRUPTS | 08:12 |
| freemangordon | and that's it | 08:12 |
| tmlind | ok, maybe push out your kernel changes so i can see what it's against? | 08:13 |
| tmlind | you do have 1.17 instead of 1.14 in the .config, right? | 08:13 |
| freemangordon | I am using your tree, nothiong but 1.17 there :p | 08:13 |
| tmlind | yeah because the default is 1.14 otherwise and you easily test the wrong driver :( | 08:14 |
| freemangordon | "gpu: pvr: Drop all old ddk versions" | 08:14 |
| freemangordon | "ARM: omap2plus_defconfig: Use ddk-1.17 by default" | 08:14 |
| freemangordon | :) | 08:14 |
| freemangordon | I just removed your tiler patches as they break 3430 | 08:14 |
| tmlind | ok so if you post a patch with your changes and which commit it's against i'll test here when i get a chance and try to do a fix for the pvrsgx tree | 08:14 |
| tmlind | ok i'll try to get the pvr branch working both for omap3 and 4 at least | 08:15 |
| freemangordon | tmlind: I will have to come-up with yet another macro to define that disables oc appcess | 08:15 |
| freemangordon | *ocp | 08:15 |
| tmlind | nah let's just remove that crap and add do it in pvr-drv.c based on the quirks flag there | 08:16 |
| tmlind | these ifdefs are just totally out of control | 08:17 |
| freemangordon | I don;t feel comfortable doing that | 08:17 |
| freemangordon | or, you want you to do it? | 08:17 |
| tmlind | i'll do it, just post your hacks so far so i can verify against that on n900 | 08:17 |
| freemangordon | ah, ok | 08:17 |
| freemangordon | ok, need to clone your tree first :) | 08:17 |
| tmlind | so what you have working, and what commit it's against | 08:17 |
| tmlind | a patch is fine too just do git diff from some my commit with all the reverts etc | 08:18 |
| freemangordon | ok, sec | 08:18 |
| freemangordon | hmm, wait, I want to test with your omap3-prm-gfx.patch patch first, gimme 10 minutes | 08:19 |
| tmlind | ok yeah i'll have to take a look at that stuff later, nice that you chased down the issues though :) | 08:19 |
| freemangordon | :) | 08:20 |
| freemangordon | BTW, if you have a couple of minutes, read the backscroll from after we talked yesterday evening | 08:20 |
| freemangordon | to confirm SGX idles fine | 08:20 |
| tmlind | yeah that's all there is to it, clocks get disabled, then the prm driver disables the power domain after the module is idle | 08:24 |
| freemangordon | tmlind: it works with omap3-prm-gfx.patch patch on top as well | 09:43 |
| freemangordon | tmlind: this https://www.mail-archive.com/linux-omap@vger.kernel.org/msg17821.html to ti-sysc as well, right? as a quirk for rev 121, IIUC | 09:44 |
| freemangordon | s/to ti-sysc/belongs to ti-sysc | 09:45 |
| freemangordon | user@devuan:/media/user/7b76ddc8-44f5-47b5-af5b-e5e9b5ab39c3/user/linux_openpvrsgx$ git log --pretty=oneline tmlind/droid4-pending-pvr-omapdrm-v5.15..HEAD | 09:46 |
| freemangordon | 25d1b6bd9a6e2b6093a61980fa6ee70589e27f2b (HEAD -> droid4-pending-pvr-omapdrm-v5.15) Revert "drm/omap: Fix page fault handling and flush what framebuffe wants flushed" | 09:46 |
| freemangordon | tmlind: ^^^ this is only difference with your droid4-pending-pvr-omapdrm-v5.15 branch | 09:46 |
| freemangordon | in terms of commits that is | 09:47 |
| freemangordon | and https://pastebin.com/BRKpziHV is the result of git diff | 09:47 |
| freemangordon | tmlind: please LMK if you need anything else | 09:48 |
| freemangordon | BTW I am goint to try without the revert | 09:49 |
| freemangordon | tmlind: yeah, 33bc438d6d8883d77e37b369fe5144ee9b01fad8 has to be reverted otherwise device won;t boot | 09:56 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/libmatchbox2/pull/8 (Drop support for _MOTIF_WM_HINTS) | 11:03 |
| Wizzup | great work re: sgx | 11:23 |
| sicelo | Indeed! | 11:23 |
| freemangordon | Wizzup: how had is to port pvr xorg river to 1.17? | 11:26 |
| freemangordon | *how hard | 11:26 |
| freemangordon | I don;t thing glamor makes sense | 11:26 |
| freemangordon | *think | 11:26 |
| uvos | pvr xorg driver makes no sense | 11:27 |
| uvos | its not even a kms driver | 11:27 |
| uvos | the omapdrm one makes some sense | 11:27 |
| uvos | but you cant get 2d acell with it because 1. the module it uses for that is closed source and dosent work with modern xorg abi | 11:29 |
| Wizzup | freemangordon: to port the n900 one we use right now? | 11:29 |
| Wizzup | I don't think that would make sense per se, I'd probably suggest to take the modesetting driver and add 2d on top of it using the 2d sgx code in some fashion | 11:29 |
| uvos | so it would make more sense to decouple dri3 from glamor in modesetting, there is no reason for dri3 to not work with sw 2d rendering | 11:29 |
| Wizzup | but the exact calls tht are used there do not exist | 11:29 |
| uvos | and this decoupaling was planned | 11:29 |
| uvos | and then droped when everyone moved to wayland instead | 11:30 |
| Wizzup | The 2d code/api probably exists in some form still, but not in the one we use currentenly on the n900, but also that's a very old fbdev driver with endless hacks I'd really like to not use | 11:30 |
| uvos | pvr2d still exists | 11:30 |
| Wizzup | right, but I recall the api changed some or something | 11:31 |
| Wizzup | in any case I think we should be able to register a specific exa module for the driver, no? | 11:31 |
| Wizzup | We could add another AccelMethod to modesetting for example | 11:31 |
| uvos | yes | 11:32 |
| uvos | but a seperate modesting based ddx makes more sense | 11:32 |
| uvos | since we could build that seperatly instead of forking all of xorg | 11:32 |
| Wizzup | right but the proof of concept / work would be the same | 11:32 |
| uvos | sure | 11:32 |
| Wizzup | that's just a packaging change | 11:32 |
| uvos | "so it would make more sense to decouple dri3 from glamor in modesetting, there is no reason for dri3 to not work with sw 2d rendering" | 11:32 |
| uvos | this makes the most sense at first | 11:32 |
| uvos | and would allow the same state as omap ddx on d4 atm | 11:33 |
| uvos | with acell | 11:33 |
| uvos | ie 3d but no 2d | 11:33 |
| Wizzup | yeah maybe you said the same but I can't comprehend fully because of my limited xorg knowledge | 11:33 |
| uvos | and would be welcomed upstream most likely | 11:33 |
| Wizzup | right it would also provide exa on d4 | 11:33 |
| uvos | as again this was planned anyhow | 11:33 |
| Wizzup | can you explain that in more layman terms? | 11:33 |
| uvos | so in modesetting dri3 is tied to glamor because glamor implements some bits of it in gl. so modesetting without glamor falls back to dri2 for 3d. dri2 needs special driver support that wayland kms/drm drivers dont nesscarly have (ie pvr dont some other modern drivers dont). | 11:35 |
| uvos | implementing non gl fallback paths for non glamor modesetting would allow dri3 to be used and thus accelerated 3d on pvr, in the same fashion as the omap ddx for 1.9 without the sgx2d module that is closed source | 11:36 |
| Wizzup | wasn't the sgx2d a very small lib that fmg re'd before? | 11:37 |
| uvos | ie any gl draw calls by applicaitons are acellerated as is compositing | 11:37 |
| uvos | but core x rendering is not | 11:37 |
| uvos | Wizzup: the pvr2d lib for was 1.9 was of sane size yeah | 11:37 |
| uvos | we would need to implement something like it if we want core x to be acclerated | 11:38 |
| uvos | but this could come later | 11:38 |
| Wizzup | ok | 11:38 |
| Wizzup | I'd be happy to help but I really don't know where to start | 11:38 |
| uvos | well i dont either | 11:40 |
| uvos | im not convinced fmg is correct even wrt glamor being a bad idea | 11:40 |
| uvos | its possible its perf will be bad | 11:40 |
| uvos | but at least on pvr sgx545 it must have been possible to be ok (given that glamor was initally developed for this chip a long time ago....) | 11:41 |
| uvos | we could also check out how modern kms/drm ddx drivers work that support dri3 without glamor | 11:42 |
| uvos | like the nouveau | 11:42 |
| uvos | and i think the omap5 one (maybe) | 11:42 |
| uvos | the difference being that the omap5 dirver implments 2d accell (and very likely drawing surfaces for the present extension) on the 2d core that omap5 (and omap4670?) have | 11:45 |
| uvos | *omap4470 | 11:45 |
| Wizzup | I think pvr has a 2d unit | 11:46 |
| uvos | right | 11:46 |
| Wizzup | so using that rather than 3d sounds like a good idea | 11:46 |
| Wizzup | in principle | 11:46 |
| uvos | or rather it dose 2d somehow | 11:46 |
| Wizzup | right | 11:46 |
| uvos | its proubly useing the 3d engine | 11:46 |
| Wizzup | I am not so sure | 11:46 |
| uvos | but later omaps have a deicated 2d chip | 11:46 |
| Wizzup | if it uses the 3d engine then yeah, it might be the same | 11:47 |
| uvos | well it would be better optimized | 11:47 |
| uvos | they have special microcode for 2d | 11:47 |
| Wizzup | I think it might make sense to at least fix glamor and then see just how bad it is | 11:48 |
| Wizzup | depending on how much fixing it needs | 11:48 |
| Wizzup | getting the 2d to go is also a way into mainline.. | 11:48 |
| uvos | fixing it its easy (realtivy) | 11:48 |
| uvos | fixing it without copying every surface is hard | 11:48 |
| uvos | and ofc prf wise its not fair if you copy every surface :P | 11:49 |
| freemangordon | thats the issue | 11:52 |
| freemangordon | we cannot fix it without copying every surface | 11:53 |
| freemangordon | with doing that perf goes down the drain | 11:53 |
| freemangordon | my test application does that copying with 15fps on n900 | 11:53 |
| freemangordon | and was something like 50-60 fps on d4 | 11:54 |
| freemangordon | but, keep in mind this is *the only* thing test app does | 11:54 |
| freemangordon | so in RL performance will be even worse | 11:54 |
| uvos | still faster than glxgears on ddk1.9 :P (wich clearly is also copying surfaces) | 11:55 |
| uvos | *es2_gears | 11:55 |
| uvos | but ok | 11:55 |
| uvos | if its not possible idk | 11:55 |
| freemangordon | sec | 11:55 |
| freemangordon | uvos: if you want to review the code I am using to test fix for glTexSubImage2D, please LMK | 11:56 |
| freemangordon | it is perfectly possible I am doing something wrong, thus the bad perf | 11:57 |
| uvos | i have seen it | 11:57 |
| freemangordon | ok | 11:57 |
| freemangordon | this runs with 15fps | 11:57 |
| uvos | i dont know enought about gl to say | 11:57 |
| freemangordon | but even if it was running with 50fps, still copying every BO backed texture is insane | 11:58 |
| uvos | yeah | 11:58 |
| freemangordon | so, I am not sure my idea of having pvr driver that is not glamor makes sense | 11:59 |
| freemangordon | *makes no | 11:59 |
| uvos | im not saying it dosent | 11:59 |
| freemangordon | uvos: so, you say we shall stay with modesteenig/dri2? | 11:59 |
| uvos | no | 12:00 |
| uvos | i would investigate dri3 without glamor in modesetting | 12:00 |
| freemangordon | please explain to us mortals who are not deep in xorg architecture :) | 12:00 |
| freemangordon | who will implement 2d accel? | 12:00 |
| uvos | no one | 12:00 |
| freemangordon | that'd mean we'll scroll long lists for ages, no? | 12:01 |
| freemangordon | and there will be no XV surface, and... and... | 12:01 |
| uvos | yeah, yes yeah | 12:01 |
| uvos | but we can improve that later | 12:01 |
| freemangordon | so no video playback, and basically useless device | 12:01 |
| freemangordon | how? | 12:01 |
| uvos | well you create a module that implements core x rending on pvr2d | 12:03 |
| uvos | lots of work | 12:03 |
| freemangordon | can't we just RE the one from 1.14 and port it to 1.17 | 12:03 |
| uvos | dident 1.14 drop that allready | 12:03 |
| freemangordon | lemme check | 12:03 |
| uvos | but yeah maybe depends on if pvr2d still is the same api wise | 12:03 |
| uvos | but at first you can get something that at least works as well as ddk 1.9 on d4 by "just" implementing dri3 on modeseting | 12:04 |
| uvos | analogous to how the nvidia mesa ddx driver dose it | 12:04 |
| uvos | *modesetting without gl | 12:05 |
| freemangordon | but we won;t have 3d, no? | 12:05 |
| uvos | yes we would have 3d | 12:05 |
| freemangordon | but for gbm and wl only, no? | 12:05 |
| uvos | glamor is only a hard requirement for dri3 on modesetting beacuse it uses it to render the present surfaces iiuc | 12:06 |
| freemangordon | oh, ok, I think I get your point | 12:06 |
| freemangordon | but, this already works, no? | 12:06 |
| uvos | no | 12:06 |
| freemangordon | modesetting+dri2 | 12:06 |
| freemangordon | how's that? | 12:06 |
| freemangordon | iirc we patch xorg to even try glamor on ES2 | 12:06 |
| uvos | so im pretty fuzzy on dri2 but it hooks into mesa x11 support code directly | 12:07 |
| uvos | and dosent work on just plain kms/drm/gbm driver | 12:07 |
| uvos | so no dice on pvr | 12:07 |
| freemangordon | yeah, it id dri3 | 12:08 |
| freemangordon | *it is | 12:08 |
| freemangordon | so, your suggestion is to have dri3 without glamor working? | 12:08 |
| uvos | yes | 12:08 |
| freemangordon | no way | 12:08 |
| freemangordon | lemme explain: | 12:08 |
| uvos | look at what the nv driver dose | 12:08 |
| uvos | and omap5 dxx | 12:08 |
| freemangordon | wait | 12:08 |
| freemangordon | lemme explain | 12:08 |
| uvos | they use other hw blocks to copy the surfaces | 12:08 |
| uvos | for present | 12:08 |
| uvos | or rahter blit | 12:09 |
| freemangordon | you cannot mmap bo with pvr | 12:09 |
| freemangordon | so you simply cannot render on it without GL | 12:09 |
| uvos | well im sure pvr2d can grab surfaces from its mapped space | 12:09 |
| freemangordon | but we don;t know how | 12:10 |
| uvos | you could have a tiny accel module that uses pvr2d only to blit it | 12:10 |
| uvos | it = present surfaces | 12:10 |
| uvos | well yeah | 12:10 |
| uvos | sure we dont | 12:10 |
| freemangordon | uvos: so, your idea is to: | 12:10 |
| uvos | i dont see how we know how to implement a full pvr2d xorg ddx either | 12:10 |
| freemangordon | use modesetting with dri3 to create BOs, then find a way to mmap those BOs so xorg code can render on that? | 12:11 |
| freemangordon | is this your idea? | 12:11 |
| uvos | that would work yeah | 12:12 |
| freemangordon | I don;t think we can mmap | 12:12 |
| freemangordon | BTW, there is anotehr way - using bufferclass | 12:12 |
| uvos | so how do wayland wms get cpu renerd surfaces into pvr | 12:12 |
| uvos | they just upload a texture no? | 12:12 |
| freemangordon | GL | 12:12 |
| freemangordon | texture + shader | 12:13 |
| freemangordon | I am not aware of any other way | 12:13 |
| uvos | so the BO backed textures wich are those | 12:13 |
| uvos | the core x renderd ones | 12:14 |
| uvos | ? | 12:14 |
| freemangordon | no, BOs are created by gbm_create_surface() (or whatever the function was) | 12:14 |
| freemangordon | then you create a texture/fbo from that BO, and render on that FBO | 12:14 |
| freemangordon | (IIRC) | 12:15 |
| freemangordon | I guess WL does something similar | 12:15 |
| uvos | right but in wl it works somehow | 12:15 |
| uvos | so which are created like this? | 12:15 |
| freemangordon | uvos: keep in mind it makes lots of sense to disable mmap() for such surfaces | 12:15 |
| freemangordon | in terms of xorg - I think front and back buffers | 12:15 |
| freemangordon | in modesetting that is | 12:16 |
| uvos | right but why | 12:16 |
| uvos | x could just draw its 2d stuff using the cpu | 12:16 |
| uvos | upload it as a gl texture | 12:16 |
| freemangordon | that's what they do | 12:16 |
| freemangordon | but, fron/back buffers must be BOs to pass to dri | 12:16 |
| uvos | and then compose that + gl clients to the front buffer | 12:16 |
| uvos | ok | 12:17 |
| uvos | hmm | 12:17 |
| freemangordon | look at Linux_DRM_OpenGLES.c | 12:17 |
| freemangordon | it uses front buffer only, but API is the same | 12:17 |
| freemangordon | drmModePageFlip() | 12:17 |
| freemangordon | so, on mmap - it makes perfect sense to disable that, otherwise all the GPU caches/pipelines and optimizations are basically useless, as you have to flush the rendering on every access to mmap-ed memory | 12:19 |
| freemangordon | no? | 12:19 |
| uvos | yes | 12:19 |
| freemangordon | re 2d driver - I think I will be able to RE the one from older ddk, there are ones with debug symbols there | 12:20 |
| uvos | idk how mutch that helps us really | 12:20 |
| uvos | is accelerating exa | 12:20 |
| freemangordon | yes | 12:20 |
| freemangordon | and 3d is already accelerated | 12:21 |
| freemangordon | unless I miss something | 12:21 |
| freemangordon | dri3 does that for us, no? | 12:23 |
| uvos | dri3 dosent work without glamor in modesetting so we are back to where we started | 12:24 |
| uvos | you need to find a way to implement dri3/present without gl | 12:25 |
| uvos | not impossible | 12:25 |
| freemangordon | yes, but we can implement that simple 3d renderin | 12:25 |
| uvos | others have done it | 12:25 |
| freemangordon | no, why, I will do present with GL, there is no issue with it | 12:25 |
| uvos | yes you can use gl i ment without glamor | 12:25 |
| freemangordon | we have issue with 2D in glamor, not with present | 12:25 |
| freemangordon | mhm | 12:25 |
| uvos | ie just that bit of glamore that implements that | 12:25 |
| freemangordon | exactly | 12:25 |
| freemangordon | another option - what about XWayland? | 12:26 |
| freemangordon | this is supported upstream UUIC | 12:26 |
| freemangordon | *IIUC | 12:27 |
| uvos | my knowlage mostly deserts me here but xwayland renders it stuff via gl or sw, creates a buffer via gbm to shove that into and pases that to the wl wm | 12:27 |
| uvos | iiuc | 12:28 |
| freemangordon | and we are back in square one with glTexSubImage2D issue | 12:29 |
| uvos | yes | 12:29 |
| freemangordon | also, I still think perf-wise glamor will be next to useless even on d4 | 12:30 |
| Wizzup | what about the omap5 driver that implements 2d for omap5s? | 12:37 |
| Wizzup | maybe there's usable stuff there | 12:37 |
| uvos | it implements everything (icl bliting buffers) on the ti 2d core | 12:38 |
| uvos | so its of limited use | 12:38 |
| uvos | as documentation how to implement sutch a ddx driver its usefull other wise not so mutch | 12:38 |
| Wizzup | ok | 12:38 |
| Wizzup | so adding another accel method based on glamor but using different 2d ops could potentially work? | 12:40 |
| Wizzup | (e.g. the 'old' ones we use now on n900) | 12:40 |
| uvos | Wizzup: maybe the probelm isent how to render the 2d elements per say | 12:44 |
| uvos | but how to get them to the display | 12:44 |
| freemangordon | ok, we even have file names | 12:59 |
| freemangordon | oh, 2d driver loads some code fragments into sgx (like blit) | 13:06 |
| freemangordon | I guess I can RE that in 1-2 weeks | 13:09 |
| Wizzup | might be worth to check if it uses apis that are still available | 13:28 |
| Wizzup | (if not, REing makes a lot less sense) | 13:44 |
| Wizzup | still, if we can get glamor to go with not too much effort (even though we copy a lot) it might still be worth just for the milestone + working thing | 13:44 |
| freemangordon | Wizzup: I saw glamor semi-working on d4, takes a second to render xterm | 14:26 |
| freemangordon | this is without copying | 14:27 |
| freemangordon | copying it needed by firefox, for example | 14:27 |
| freemangordon | and it will slow-down already very heavy browser | 14:27 |
| freemangordon | libpvr2d is still there on 1.17, don;t know how much APIs match between Graphics_SDK_5_01_01_02 and this | 14:32 |
| freemangordon | but worths trying | 14:32 |
| tmlind | fyi, i think the pyra folks mentioned at some point that the neon functions were fastest for 2d, there's some xserver-neon or something | 14:43 |
| tmlind | i think xwayland suffers from the same glamor issues with gles2 as xorg meaning currently xwayland is not accelerated for sgx | 14:44 |
| tmlind | freemangordon: so did you try that pm34xx.c fix and verify it blocks off idle? | 14:51 |
| tmlind | hmm warm reset in off mode, how do you do that? | 14:52 |
| tmlind | i think only the macro boards had a reset button.. | 14:53 |
| lel | parazyd transferred a repository: https://github.com/maemo-leste/profilesx | 14:57 |
| uvos | tmlind: rendering a buffer on cpu is not the issue | 14:59 |
| uvos | note: check out how https://github.com/endlessm/xf86-video-armsoc works | 14:59 |
| uvos | some vague description: https://lists.x.org/archives/xorg-devel/2012-May/031250.html | 14:59 |
| freemangordon | tmlind: well, fremantle kernel has that fix. no idea if it is needed or not, but judging by the fact Nokia created the patch, I would say yes | 15:02 |
| freemangordon | not sure I understand "did you try that pm34xx.c fix" part | 15:02 |
| tmlind | i doubt that patch is needed, sounds like it's only for the macro boards | 15:13 |
| tmlind | but yeah, if off mode stops working after a warm reset in off mode, then sure we need it | 15:13 |
| tmlind | we can test that core off keeps working by decreasing the off idle mode time like i described earlier | 15:14 |
| tmlind | uvos: hmm so is your d4 consumes more in idle than bionic test case with the modem online? | 15:28 |
| freemangordon | tmlind: ok, if you say we don;t need that patch, I believe you :) | 15:39 |
| freemangordon | uvos: re armsoc - IIRC it uses the API that was before GBM, and mmap buffers | 15:40 |
| freemangordon | DMABUF? | 15:42 |
| freemangordon | https://github.com/endlessm/xf86-video-armsoc/blob/master/src/armsoc_exa.c#L310 | 15:43 |
| * freemangordon checks if pvr driver supports this | 15:51 | |
| uvos | GEM | 15:52 |
| freemangordon | mhm | 15:52 |
| freemangordon | PRIME? | 15:55 |
| freemangordon | it seems omapdrm supports that | 15:56 |
| freemangordon | however, this is not accelerated through PVR 2D engine, IIUC | 15:56 |
| uvos | prime exchaned buffers between gpus with gem iirc | 15:57 |
| freemangordon | ok, but blits still won;t be accelerated, no? | 15:57 |
| uvos | no final blit would be cpu | 15:58 |
| uvos | but that would be ok if the pvr dri node can give you a gem buffer without copying | 15:58 |
| freemangordon | pvr_drv does it through 2D engine, IIUC | 15:58 |
| uvos | you have to transfer the buffer off of the gpu anyhow since its seperate from the dss | 15:59 |
| uvos | not sure how this works atm actually | 15:59 |
| uvos | (ddk 1.9) | 15:59 |
| uvos | i gues -video-omap must do this | 15:59 |
| freemangordon | in Graphics_SDK_5_01_01_02 there is pvr_drv.so (xorg EXA driver), which allocates memory through libpvr2d.so | 16:00 |
| freemangordon | later on this memory is passed back to PVR2DBlt | 16:01 |
| uvos | yeah but how dose it work in the fallback path | 16:01 |
| freemangordon | ah | 16:01 |
| freemangordon | well, omapdss supports GEM, IIUC | 16:02 |
| freemangordon | but all this is not accelerated | 16:02 |
| uvos | yeah sure | 16:02 |
| freemangordon | maybe I should simply RE that, 50K of code shouldn;t take that much | 16:02 |
| uvos | but how dose the bufer from pvr for accelerated clients get into omapdsss | 16:02 |
| uvos | they must share gem handle | 16:02 |
| uvos | for that buffer | 16:02 |
| freemangordon | I think they do | 16:03 |
| freemangordon | but I guess tmlind can share more info on that | 16:03 |
| freemangordon | I think he wrote a patch exactly for that | 16:03 |
| * tmlind knows nothing about that stuff | 16:03 | |
| uvos | the guestion then becomes dose this api still work in 1.17 | 16:04 |
| freemangordon | hmm | 16:04 |
| freemangordon | it should work, as this is part of the SDK | 16:04 |
| uvos | what is part of sdk? | 16:04 |
| freemangordon | libpvr2d.so | 16:04 |
| uvos | no not that | 16:04 |
| uvos | the fallback path | 16:05 |
| freemangordon | ah | 16:05 |
| uvos | ie create a gem handle on on card1 with accel client and move it to card0 | 16:05 |
| uvos | for composing on cpu/ rendering out | 16:05 |
| freemangordon | I think this is what works with modesetting and no glamor | 16:05 |
| uvos | no | 16:05 |
| uvos | at least not for me | 16:05 |
| freemangordon | no? | 16:05 |
| freemangordon | wait, it was working | 16:06 |
| uvos | mesa just refuses to use pvr_dri.so in this constilation | 16:06 |
| freemangordon | I am sure | 16:06 |
| freemangordon | ah, yeah | 16:06 |
| freemangordon | it uses dri2, IIUC | 16:06 |
| uvos | right | 16:07 |
| freemangordon | but again, I don;t have any deep knowledge on the matter and it was while ago I used it | 16:07 |
| uvos | and something is missing for dri2 | 16:07 |
| uvos | which might be the gem interface | 16:07 |
| freemangordon | pvr_drv is what is missing :p | 16:07 |
| uvos | ok | 16:07 |
| uvos | i have no idea how dri2 works | 16:07 |
| freemangordon | that provides EXA through libpvr2d.so | 16:08 |
| uvos | sure | 16:08 |
| uvos | but dri2 works on ddk1.9 with no pvr2d accell | 16:08 |
| uvos | so whats missing in the ddk1.17 setup | 16:08 |
| uvos | is the question | 16:08 |
| uvos | for the fallback path | 16:08 |
| freemangordon | ah, right | 16:08 |
| freemangordon | sec | 16:08 |
| freemangordon | libpvrws_KMS.so / libpvrws_WAYLAND.so | 16:10 |
| freemangordon | uvos: what do you mean "works"? | 16:11 |
| uvos | works in what sentence | 16:11 |
| uvos | "i have no idea how dri2 works?" | 16:12 |
| uvos | ? | 16:12 |
| freemangordon | "(17,08,26) uvos: but dri2 works on ddk1.9 with no pvr2d accell" | 16:12 |
| uvos | well it works in that x is able to render its buffer on cpu that is combined with gles clients on pvr and sent to omapdrm for output | 16:13 |
| uvos | with bad but not unusable performance | 16:13 |
| freemangordon | this is with that patched omap-fb exa? | 16:13 |
| freemangordon | do you know which repo are those binaries? | 16:14 |
| freemangordon | for 1.9 | 16:14 |
| uvos | xf86-video-omap | 16:14 |
| uvos | https://github.com/maemo-leste/pvr-omap4 | 16:14 |
| freemangordon | yeah, those | 16:14 |
| freemangordon | uvos: libpvrws_OMAPDRI2.so is what is missing | 16:15 |
| freemangordon | actually, the whole 'WS' stuff was removed | 16:15 |
| freemangordon | if that wasn;t the case (removed) there would have been no need for the shim | 16:16 |
| uvos | yeah i know | 16:16 |
| uvos | the question is how dri2 works and whats in there even | 16:16 |
| uvos | but i should just read the omap ddx and what it uses in the fallback path myself | 16:16 |
| freemangordon | ah | 16:17 |
| freemangordon | I think it still calls libpvr2d.so to mmap gpu memory | 16:17 |
| uvos | aha | 16:17 |
| uvos | neat | 16:17 |
| uvos | so we can do that | 16:17 |
| uvos | (if it still works with modern libpvr2d) | 16:18 |
| freemangordon | hmm, no | 16:18 |
| freemangordon | it calls omap_bo_map | 16:18 |
| freemangordon | but should be the same basically | 16:18 |
| freemangordon | and that is in omap_drm, IIUC | 16:19 |
| uvos | omap_bo_map might be one of those functions that where there only to support sgx and where removed | 16:19 |
| freemangordon | IIUC, this was one of those HW specific libs that were needed by dri2 | 16:20 |
| freemangordon | it is in omap_drm lib | 16:20 |
| freemangordon | lemme check on my d4 | 16:21 |
| freemangordon | yes, there is such library | 16:22 |
| freemangordon | libdrm_omap.so.1.0.0 | 16:22 |
| freemangordon | https://github.com/grate-driver/libdrm/blob/master/omap/omap_drm.c | 16:23 |
| freemangordon | so, I guess we can make this work | 16:23 |
| freemangordon | but, I would say this is a dead-end as we don't use PRV 2D engine | 16:24 |
| freemangordon | maybe the best option is to use PVR driver from meego and port it to modern xorg | 16:25 |
| freemangordon | or, /me to RE the ones in Graphics_SDK_5_01_01_02 and port them to 1.17 | 16:25 |
| freemangordon | PVR2DMemMap is still there in 1.17 | 16:36 |
| freemangordon | PVRSRVAllocDeviceMem too | 16:39 |
| freemangordon | uvos: also, we also have declarations of all the exported functions, structs, everything | 16:51 |
| freemangordon | for example: https://github.com/tmlind/linux_openpvrsgx/blob/droid4-pending-pvr-omapdrm-v5.15/drivers/gpu/drm/pvrsgx/1.17.4948957/eurasia_km/include4/services.h | 16:52 |
| kona | freemangordon: is the platform gated on modest-providers in some way? | 18:47 |
| kona | i don't want to hold things up, but i haven't been able to give it any time | 18:48 |
| Wizzup | uvos: btw I was on the croatian/bosnian border a few times and got quite a few smss on sphone about changing country - was nice | 20:09 |
| Wizzup | freemangordon: I wonder if our use case / problem is worth discussing with tomi or others who might know more | 20:10 |
| uvos | Wizzup: neat | 20:19 |
| uvos | Wizzup: well anyone who would listen how has more knowlage would be great, but ofc most will, rightly so, not be interested in pvr crap. tomi might ofc. | 20:20 |
| Wizzup | right | 20:22 |
| uvos | btw freedreno works really well with xorg | 20:23 |
| uvos | (on pmos) | 20:24 |
| uvos | i should really maybe port leste to xt1602 | 20:25 |
| Wizzup | no keyboard though right? | 20:27 |
| uvos | no | 20:28 |
| Wizzup | still, would be cool | 20:28 |
| uvos | but otherwise its really well suported | 20:28 |
| uvos | even calls and stuff work | 20:28 |
| uvos | except that it has audio routing issues | 20:28 |
| Wizzup | right | 20:28 |
| uvos | like xt894 | 20:29 |
| Wizzup | the more the merrier I guess, although I think we'd still want to solve the pvr stuff | 20:29 |
| uvos | sure ofc | 20:29 |
| uvos | i was just noteing | 20:29 |
| Wizzup | yeah good ideas | 20:29 |
| uvos | that freedreno works well while we have problems with pvr and mali too | 20:29 |
| Wizzup | yeah, I also bought a nexus 5 for leste at some point | 20:31 |
| Wizzup | I think parazyd has it | 20:31 |
| Wizzup | at the time I tried it we had some h-d bugs for rotation, but otherwise I already had 3d working | 20:31 |
| Wizzup | this was 2+ years ago | 20:31 |
| uvos | rotaion works fine | 20:31 |
| uvos | with xrandr | 20:31 |
| Wizzup | yeah, *now* :) | 20:31 |
| uvos | so is a solved issue or was hildon ackting up | 20:31 |
| uvos | yeah | 20:31 |
| Wizzup | https://wizzup.org/leste-n5-initial.jpg | 20:31 |
| uvos | looks like the hildon dosent like the crtc changing bug | 20:32 |
| uvos | that still exists | 20:32 |
| Wizzup | I don't think so, this is a different one | 20:32 |
| uvos | (ie change resolution on hdmi, it looks exactly like that) | 20:32 |
| uvos | ok | 20:32 |
| Wizzup | this was about starting h-d on any display that was higher than it was wide | 20:32 |
| Wizzup | e.g. d4 too | 20:32 |
| uvos | ok | 20:33 |
| Wizzup | so we should retry some time, but atm I don't want to, cause it feels like a bit of distraction | 20:33 |
| Wizzup | but yea | 20:33 |
| uvos | if it wernt for the keybord i would be sorta ok with outright dropping the pvr devices over the constant strugels with 3d | 20:34 |
| uvos | but well..... | 20:34 |
| uvos | here we are | 20:34 |
| Wizzup | clearly there is a link between pvr and keyboards | 20:37 |
| uvos | you joke but MSM8916 dosent have a keyboard matrix | 20:40 |
| uvos | but other varants do afaik | 20:41 |
| uvos | not that adding a i2c keyboard is hard | 20:41 |
| Wizzup | hehe | 20:42 |
| uvos | case point for code formating: i want to change debug("something") to sphone_log(LL_DEBUG, "something") | 21:59 |
| uvos | but sphone person used debug("something") debug ("something") debug ("something") debug( "something" ) and debug ( "something" ) | 22:00 |
| uvos | great | 22:00 |
| Wizzup | yikes | 22:01 |
| uvos | debug("book_import_csv: add dial column: %d\n", column),dialcolumns++,headers[column]=1; | 22:05 |
| uvos | i have to admit i dident even know that was valid c | 22:05 |
| Wizzup | lol | 22:07 |
| freemangordon | kona: don;t worry, it is not important | 22:08 |
| freemangordon | still, good to have some day :p | 22:09 |
| freemangordon | Wizzup: what exactly to discuss with tomi? I'd say for the others xorg is dead and buried. | 22:09 |
| freemangordon | also, what we have here is low-end HW noone but us is interested in | 22:11 |
| freemangordon | n900 is simply not capable of supporting galmor, according to to what I was able to understand so far | 22:11 |
| uvos | well not the way its written, clearly you can draw with gles and compose everthing with gles to the screen from a hw perspective | 22:13 |
| uvos | since wayland wms do exactly that | 22:13 |
| Wizzup | freemangordon: I figured he might have some ideas, but it sounds like you mostly have a good sense of what ought to be done now | 22:14 |
| Wizzup | still, I'd take n900 with glamor (albeit slow) over 5.1 with old x ddx, but a path towards fast 2d is really nice (also for d4!) | 22:15 |
| freemangordon | right, but what is the point of wasting resource on something that we already know will be next to useless in terms of performance (glamor) | 22:18 |
| Wizzup | fair enough | 22:18 |
| freemangordon | either we find a zero-copy way or we waste cpu/gpu cycles and battery juice | 22:18 |
| Wizzup | right | 22:18 |
| freemangordon | see, maybe what I think shall be done is not the right thing to do | 22:19 |
| freemangordon | but as I see it none of use have the whole picture and until we try, we never know | 22:19 |
| freemangordon | well I tried glamor already and I am convinced this is not the correct thing for our usecase | 22:20 |
| freemangordon | on n900/d4 that is | 22:20 |
| freemangordon | for more powerful ES3 devices, it is another story | 22:20 |
| freemangordon | but for those who barely cover 2.1 we cannot use it and better look at TI already did back then | 22:21 |
| freemangordon | REing ~50KB lib is nothing compared to the time I already wasted on glamor/xorg without major success | 22:21 |
| freemangordon | I might be wrong as well, but... | 22:22 |
| uvos | well reing that lib is hardly sufficant | 22:22 |
| freemangordon | for 2D it should be | 22:22 |
| Wizzup | we still need to use the lib in the modesetting fork | 22:23 |
| Wizzup | and integrate that | 22:23 |
| Wizzup | but yeah | 22:23 |
| uvos | you still have to port omap ddx to dri3 and whatever changes come with the newer blobs | 22:23 |
| Wizzup | hm, why can't we use modesetting? | 22:23 |
| freemangordon | modesetting will be happy with dri2 EXA | 22:23 |
| freemangordon | if we dont; use glamor | 22:23 |
| uvos | except the iiuc dri2 path is not possible since you can shim it the same way | 22:24 |
| uvos | so how would 3d clients work... | 22:24 |
| freemangordon | yeah, I will have to think about that | 22:24 |
| uvos | in dri2 the server has to create the buffer and hand it to the client | 22:26 |
| freemangordon | uvos: but, honestly, do you think glamor is a viable option given it doe not support ES2? | 22:26 |
| freemangordon | *does not | 22:26 |
| uvos | i dont see how you gonna shim that | 22:26 |
| uvos | wdym? it supports es2 just fine | 22:26 |
| uvos | mostly | 22:26 |
| uvos | slightly out of spec maybe | 22:27 |
| freemangordon | BTW, if we are to implement video playback in glamor, we'll have something like 10fps for fullscreen | 22:28 |
| freemangordon | on n900 that is | 22:28 |
| freemangordon | SGX530 is simply not powerful enough for that | 22:28 |
| uvos | not sure how you come up with these numbers but ok | 22:28 |
| Wizzup | probably mem b/w? | 22:28 |
| freemangordon | because I played a lot with it back then when I was rtying to implement embedlite | 22:28 |
| freemangordon | back then mozilla switched to GL rendering for gecko | 22:29 |
| freemangordon | ecause of webgl | 22:29 |
| freemangordon | *because | 22:29 |
| freemangordon | so, videos were decoded to textures | 22:30 |
| freemangordon | I played "Big Buck Bunny" countless times trying to optimize to an acceptable performance | 22:31 |
| freemangordon | no dice | 22:31 |
| freemangordon | we have another option I don;t really like - bufferclass | 22:31 |
| uvos | im going to press x for doubt that sgx cant scale and transform a 1080p texture at 30 fps, and the ducati decoder works in the same memory so there is no copying needed | 22:31 |
| Wizzup | Why would it be 1080p? | 22:32 |
| uvos | decoder maximum | 22:32 |
| Wizzup | The n900 can't even decode 720p using the hw decoder | 22:32 |
| freemangordon | mhm | 22:32 |
| uvos | oh ok | 22:32 |
| uvos | well omap4 then | 22:32 |
| freemangordon | it can, but low profile only | 22:32 |
| Wizzup | in any case I think this is not super relevant | 22:32 |
| uvos | software /driver issues non withstanding the hardware can do this | 22:32 |
| freemangordon | yes, decoding was through DSP | 22:32 |
| Wizzup | Sure smooth video playback is nice for low res videos, but we can't make the hw better than it is, I think having smooth scrolling and such is imortant | 22:32 |
| Wizzup | having in-browser video playback ... eh | 22:32 |
| freemangordon | actually it is possible, and HW supports it | 22:33 |
| uvos | side not in-browser video plackbak works absoulty fine on d4 wayland | 22:33 |
| uvos | with gl surfaces | 22:33 |
| Wizzup | not arguing one way or another, just saying it's not that important to me personally | 22:33 |
| Wizzup | I really never play videos on my n900 fremantle much either, but having maps scroll smooth is important | 22:33 |
| uvos | dose sd @60 fps for youtube | 22:33 |
| Wizzup | e.g. maep on n900 is smoother now than on the d4 iirc | 22:33 |
| uvos | in ff | 22:33 |
| Wizzup | (on leste) | 22:34 |
| freemangordon | uvos: I was just givin an example | 22:34 |
| freemangordon | why I think about the numbers | 22:34 |
| uvos | and its more limited by the cpu than by sgx doing the presenting | 22:34 |
| uvos | *cpu decoding | 22:34 |
| freemangordon | not, it is limited by the memory bus | 22:34 |
| freemangordon | because you have to push every frame to a texture | 22:35 |
| freemangordon | and then use SGX to render that texture | 22:35 |
| freemangordon | this is not a zero-copy, sorry | 22:35 |
| uvos | no not atm in wayland its not zero-copy | 22:36 |
| freemangordon | we can have zero-copy with bufferclass | 22:36 |
| uvos | but its less copy | 22:36 |
| uvos | since the output dosent copy again | 22:36 |
| uvos | anyhow it works fine on d4 | 22:36 |
| uvos | but its also faster ofc | 22:36 |
| uvos | than n900 | 22:36 |
| freemangordon | uvos: ok, I don't get it - tmlind said WL has the same issues with SGX ddk as xorg | 22:37 |
| freemangordon | you say that it works fine | 22:37 |
| uvos | ? wayland has allways worked fine | 22:37 |
| uvos | its very performant | 22:37 |
| Wizzup | I think uvos is not talking about sgx at all | 22:37 |
| uvos | yes ofc | 22:38 |
| Wizzup | in this instance | 22:38 |
| uvos | sgx output | 22:38 |
| uvos | im talking wlroots here | 22:38 |
| uvos | it renders via gles | 22:38 |
| uvos | its extreamly performant | 22:38 |
| uvos | fire up firefox and scroll around | 22:38 |
| uvos | or watch a video | 22:38 |
| Wizzup | maybe try it on the n900? would be interesting | 22:38 |
| freemangordon | could you try that on n900? | 22:39 |
| freemangordon | :) | 22:39 |
| uvos | if you provide me with a kernel that works | 22:39 |
| uvos | i guess i could also install pmos | 22:39 |
| freemangordon | which ddk? 1.17? | 22:40 |
| uvos | 1.17 | 22:40 |
| freemangordon | no problem, in 5 minutes | 22:41 |
| sicelo | I don't think we should discourage/stop fmg from RE'ing the 50kb binary if he feels there's some hope there. Just my 2 cents | 22:42 |
| freemangordon | sicelo: OTOH, if GL is performant enough, we should really consider it | 22:42 |
| uvos | sicelo: dont you use ddk1.17 on n900/wayland | 22:42 |
| uvos | or just d4 | 22:42 |
| freemangordon | I doubt | 22:42 |
| freemangordon | as we have useful 1.17 on n900 since yesterday :) | 22:43 |
| uvos | well afaik it works in pmos i thought | 22:43 |
| Wizzup | I don't think so | 22:43 |
| freemangordon | with out working kernel? | 22:43 |
| freemangordon | I doubt too | 22:43 |
| sicelo | I was using 1.17 with no issues on debian. No one tried it on pmos | 22:43 |
| uvos | they use 5.7 or something | 22:43 |
| uvos | pmos has pacakges for jonathings mesa sgx | 22:44 |
| uvos | for omap4 at least | 22:44 |
| freemangordon | sicelo: with 2fps vbo I guess | 22:44 |
| sicelo | I used TI blobs with debian | 22:44 |
| sicelo | Mmm, i don't have it handy right now, and can't remember the actual benchmark scores. However sway worked reasonably okay | 22:45 |
| Wizzup | on 5.1 h-d works quite nicely too :p | 22:45 |
| freemangordon | but that's not 1.17 | 22:45 |
| freemangordon | ;) | 22:45 |
| sicelo | Yeah :-) | 22:46 |
| uvos | http://uvos.xyz/maserati/glmark-sway.txt | 22:51 |
| uvos | glmark on patched wlroots | 22:51 |
| uvos | on d4 | 22:52 |
| freemangordon | uvos: http://46.249.74.23/linux/n900.tar.gz | 22:53 |
| freemangordon | this is omap2plus_defconfig | 22:54 |
| uvos | where are the blobs | 22:54 |
| freemangordon | Wizzup: could you provide yours, mine are not patched | 22:54 |
| freemangordon | uvos: or you don't need patched ones? | 22:55 |
| uvos | i gues i could start with a debain rootfs | 22:55 |
| freemangordon | which debian is the question :). libc 2.28 or 2.31 | 22:55 |
| uvos | well i would choose 11 | 22:56 |
| uvos | ofc | 22:56 |
| freemangordon | ok, gimme a minute to reboot to fremantle and will provide blobs | 22:56 |
| freemangordon | uvos: better clone https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/ | 22:57 |
| freemangordon | branch 1.17.4948957-next | 22:57 |
| uvos | i wish we had a package for ddk1.17 | 22:58 |
| freemangordon | ti343x is what you need | 22:58 |
| uvos | installing stuff is major pain | 22:58 |
| uvos | beacuse of the dependancy hell | 22:58 |
| uvos | ok | 22:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
