<catphish>
according to ubuntu, it's 72 bytes to be removed and the rest is just text
Andy-D has joined #linux-sunxi
<alexxey>
Oh!... Thanks, problem solved!
<catphish>
i'm still struggling with memory speed, write through seems unbearably slow, i think what i need to do is use write back so that the writes are buffered through the cache then clean it once i've finished
<catphish>
would quite like to push for 1GB/s so i'll do some more objective tests to see what can be achieved / what i might be doing wrong
vagrantc has quit [Ping timeout: 260 seconds]
<catphish>
objective tests are much more useful, a plain sequential write achieves 550MB/s, that's more like it, but a sequential copy reduces that down to 18MB/s, i feel like i have a deep lack of understanding of how computers work all of a sudden
<catphish>
with write-back, that copy runs at 400MB/s, would anyone be able to briefly explain to me what i'm seeing here?
RichardG867 has quit [Read error: Connection reset by peer]
RichardG867 has joined #linux-sunxi
Nyuutwo has quit [Read error: No route to host]
Mandragor has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
<catphish>
in fact the slowdown applies to just reading, so i guess my real question becomes, why can i only read dram at 18MB/s when the mmu is configured with write-through? specifically with tex=0b000, cb=0b10
<catphish>
that bufferability bit must have more impact that just a write policy
* catphish
keeps reading
JohnDoe_71Rus has joined #linux-sunxi
<jelle>
do I need a special /boot for arm64 or can I just use a single partition?
aalm has joined #linux-sunxi
<jelle>
nvm figured it out :)
dddddd has joined #linux-sunxi
<mru>
catphish: for a graphics framebuffer you probably want to use uncached "normal" (aka write-combining)
glamb has joined #linux-sunxi
glamb has quit [Remote host closed the connection]
<mru>
buffering is a write feature
<mru>
doesn't affect reads
<mru>
caching is only useful if you expect to be reading the framebuffer a lot
<KotCzarny>
isnt framebuffer in dram anyway?
<mru>
yes, so?
<KotCzarny>
isnt the cache small?
<mru>
small is a relative thing
<KotCzarny>
compared to usual framebuffer size
<mru>
but you obviously don't want to be wasting cache space on data you're going to read
<mru>
a large L2 cache could hold a small framebuffer
<catphish>
mru: thanks, it is a framebuffer, uncached sounds ideal, caching it is totally wasteful, write-combining sounds good, but i don't know what that entails or how to enable it
<catphish>
mru: thanks for that, makes a lot more sense now, and setting my framebuffer to uncached "normal" while my source data is cacheable has improved things vastly
<mru>
catphish: are you using sprites?
<catphish>
mru: yes
<catphish>
the code essentially just loops over the pixels in a sprite and copies them to a given location in the framebuffer
<mru>
you could probably have some fun optimising those copies with neon instructions
<catphish>
i did wonder if i could use some better functions (neon or dma) do to it
<mru>
what size are your sprites?
<catphish>
16 x 16 x 32-bit
<catphish>
though it's a tad complicated because some of the pixels might be transparent, and of course those 790 bytes don't land sequentially in the framebuffer, only each line of 16 pixels does
<catphish>
brb
catphish has quit [Quit: Leaving]
catphish has joined #linux-sunxi
reinforce has joined #linux-sunxi
<mru>
do you have a separate copy of the background image somewhere?
<catphish>
my aim is that the background is generated from sprites in the same way, and they're layered up as needed
<mru>
ok, makes sense
<catphish>
so draw one set first, then draw a second set over the top, skipping any pixels where the alpha byte is 0x0 on the second pass
<mru>
but I guess the foreground sprites can be positioned anywhere
nuuuciano has joined #linux-sunxi
<mru>
and the background is simply tiled, yes?
<catphish>
so, the concept is as follows: multiple layers can be created, each layer consists of a tiled grid of sprites, and an offset to render at, so a bakground might have lots of sprites in a 50x50 grid, and an offset of 0,0, whereas a foreground layer might have 4 sprites in a 2x2 grid and its position would change much more often, and there may be any number of these layers
<catphish>
this is just a concept that seemed cool to me
<catphish>
the transparency seems like the thing that will cause the most annoyance, but i'll look into what neon instructions can do and hopefully speed things up :)
<catphish>
thanks for all the assistance, learning a lot here
<mru>
I think you'll find the VBSL instruction useful
<mru>
along with VCLT
<mru>
but make it work first
<mru>
then optimise
IgorPec has quit [Ping timeout: 250 seconds]
Andy-D has quit [Ping timeout: 250 seconds]
Andy-D has joined #linux-sunxi
<qschulz>
wens: hehe, missed the IRC conversation on the alignment patch but good to see we're on the same page :) thanks quark_ for the patches!
IgorPec has joined #linux-sunxi
IgorPec has quit [Client Quit]
giomba has joined #linux-sunxi
IgorPec has joined #linux-sunxi
popolon has quit [Quit: WeeChat 2.3]
clemens3 has joined #linux-sunxi
lykt has quit [Quit: leaving]
clemens3 has quit [Remote host closed the connection]
clemens3 has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
lykt has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 268 seconds]
nuuuciano has joined #linux-sunxi
muvlon has joined #linux-sunxi
clemens3 has quit [Ping timeout: 272 seconds]
clemens3 has joined #linux-sunxi
\\Mr_C\\ has quit [Ping timeout: 272 seconds]
\\Mr_C\\ has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
alexxey has quit [Ping timeout: 245 seconds]
csims27 has joined #linux-sunxi
csims27 has quit [Remote host closed the connection]
nomad_fr_ has joined #linux-sunxi
nomad_fr_ has quit [Remote host closed the connection]