Re: scroll down the screen
Hi Johnny, What I said is, I don't think you can run Sculpt effectively on such small screens right now. When using an emulator I always set the screen size to something big enough - this depends on the emulator but there are tricks, at least with qemu. On Fri, Jan 20, 2023 at 6:53 PM Johnny Nunez wrote: > > > > > > > Hi Colin, > > > > I am still struggling with the gui here , I can’t see what you reply back, > can you please try again , thank you > ___ > Genode users mailing list > users@lists.genode.org > https://lists.genode.org/listinfo/users > ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: scroll down the screen
Hi Colin, I am still struggling with the gui here , I can’t see what you reply back, can you please try again , thank you ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: memcpy_cpu on 64bit arm
> There is no particular reason why the implementation is (i.e. "was") > empty. You can find a recent commit on the staging branch that applies a > few obvious optimisations to all architectures, though: > https://github.com/genodelabs/genode/commit/4d06661d7c3f7b798ec8228f04983bd4ae7cddcf > Is there any content in the commit? > For 32bit arm, I optimised the memcpy_cpu implementation a while ago > (see Issue #4456). Interestingly, I could not see any improvements when > using neon, at least on arm v7. I got the impression that the > instruction density is not an issue when using the multi-word > load/store (ldm/stm). Ok. I think that it makes more sense now. But yes for v7 it might not help.The only way , from my experience, neon could be used effectively is a test/copy routine for all sizes. Most arm/arm64 libc do that. I would like to try this. But I have no Idea where to put the .s file in order to build it. I don't want to have it inline since it is quite big.. Thanks, Michael ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: memcpy_cpu on 64bit arm
Hi Michael, On Fri, 20 Jan 2023 16:40:10 +0100 Michael Grunditz wrote: > Hello, > > Is there any particular reason why it is empty? > My rect copy to fb in riscos uses neon. It is > a speed gain of about 40% compared to word/long word > copy from c. But I don't know how much it affects Genode. > > It seems like it ends up in /* eight bytes chunks */ but isn't that a > byte copy? > There is no particular reason why the implementation is (i.e. "was") empty. You can find a recent commit on the staging branch that applies a few obvious optimisations to all architectures, though: https://github.com/genodelabs/genode/commit/4d06661d7c3f7b798ec8228f04983bd4ae7cddcf For 32bit arm, I optimised the memcpy_cpu implementation a while ago (see Issue #4456). Interestingly, I could not see any improvements when using neon, at least on arm v7. I got the impression that the instruction density is not an issue when using the multi-word load/store (ldm/stm). Johannes ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
memcpy_cpu on 64bit arm
Hello, Is there any particular reason why it is empty? My rect copy to fb in riscos uses neon. It is a speed gain of about 40% compared to word/long word copy from c. But I don't know how much it affects Genode. It seems like it ends up in /* eight bytes chunks */ but isn't that a byte copy? I have the feeling that in my case, with blit,mem copy without crop is faster than doing it with crop every time. Ram, accesses are proved to be very fast on this hardware. The extra cycles for cropping might be a bottleneck. Combined with a neon run through , testing and copying without leaving routine could probably make a big performance gain. But. I am happy, as always, to be proved wrong! Michael ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: video and usb driver (rk3588)
OK so stupid me.. Invalidation should be after Blit. I don't know where my brain is :-) Thanks for reading! ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: video and usb driver (rk3588)
> > I have tested with full screen invalidate. It doesn't look pretty when > moving a window.. but mouse pointer > is ok. I have tried the below. Result: No traces if moving up , left > or right. Down , traces. So the start address > is wrong, probably. > > cache_clean_invalidate_data(xxx+invalid,(size.count()*sizeof(Pixel))-invalid); The imx8 doesn't use cached dma-buffer? Is there soeḿething (apart from imx53) that does use cached framebuffer? /Michael ___ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Re: video and usb driver (rk3588)
On Thu, 19 Jan 2023 at 17:04, Michael Grunditz
wrote:
>
> >
> > It might be easier to (1) calculate both the start offset and the end
> > offset, then (2) truncate the start offset to the cache-line size, (3)
> > round the end offset to the cache-line size, (4) calculate the size
> > argument by subtracting the start from the end offset.
> >
> > Regarding (2), when calculating the end offset via surface.w()*rect.y2()
> > + rect.x2(), it will refer to the pixel at the lower-right corner of the
> > dirty rectangle. You have to add 1 to this offset value, so that the
> > subsequent subtraction yields the number of covered pixels, not the
> > difference. E.g., think of a rectangle of only one pixel where p1 == p2.
> > Here we want to flush the cache line around this pixel. The difference
> > between the start and end offsets would be zero. But the number of
> > covered pixels is one.
>
> I have tried with 16,32 and 64. Same result. Movement y wise makes
> traces with mouse and bigger artifacts for windows.
> These sorts of things are really my weak spot.
>
> int a=0;
> int r=0;
> a=64;
> Genode::addr_t invalid =
> (rect.x1()+(rect.y1()*(size.w(*sizeof(Pixel);
> log("unaligned invalid: ",invalid);
>
> invalid = invalid&~63;
>
> Genode::addr_t endoffset =
> (1+(size.w()*rect.y2())+ rect.x2())*sizeof(Pixel);
> log("endoffset: ",endoffset);
>
> r = endoffset%a;
> endoffset = r? endoffset + (a - r) : endoffset;
> log("invalid: ",invalid);
> log("invalidz: ",endoffset);
>
> Genode::addr_t xxx = (Genode::addr_t)surface.addr();
>
> cache_clean_invalidate_data(xxx+invalid,endoffset-invalid);
I have tested with full screen invalidate. It doesn't look pretty when
moving a window.. but mouse pointer
is ok. I have tried the below. Result: No traces if moving up , left
or right. Down , traces. So the start address
is wrong, probably.
cache_clean_invalidate_data(xxx+invalid,(size.count()*sizeof(Pixel))-invalid);
___
Genode users mailing list
users@lists.genode.org
https://lists.genode.org/listinfo/users
