GrimKriegor has quit [Read error: Connection reset by peer]
lurchi_ is now known as lurchi__
GrimKriegor has joined #linux-sunxi
anarsoul|2 has quit [Ping timeout: 244 seconds]
catphish has quit [Quit: Leaving]
OneManHateGroup has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
adityaxavier_ has joined #linux-sunxi
adityaxavier_ has quit [Client Quit]
leviathanch has joined #linux-sunxi
crondog has joined #linux-sunxi
crondog has quit [Read error: Connection reset by peer]
megi has quit [Ping timeout: 250 seconds]
afaerber has quit [Ping timeout: 268 seconds]
tlwoerner has quit [Quit: Leaving]
adityaxavier has joined #linux-sunxi
adityaxavier has quit [Client Quit]
tlwoerner has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
merlin1991 has quit [Remote host closed the connection]
kelvan has quit [Read error: Connection reset by peer]
merlin1991 has joined #linux-sunxi
kelvan has joined #linux-sunxi
IgorPec has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 250 seconds]
selfbg has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 250 seconds]
reinforce has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
kaspter has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
IgorPec has joined #linux-sunxi
aalm has quit [Ping timeout: 268 seconds]
f0xx has joined #linux-sunxi
IgorPec2 has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
vagrantc has joined #linux-sunxi
dddddd has joined #linux-sunxi
tmx has quit [Ping timeout: 268 seconds]
qeed has quit [Quit: Leaving]
clemens3 has joined #linux-sunxi
vagrantc has quit [Quit: Lost terminal]
dddddd has quit [Ping timeout: 250 seconds]
vagrantc has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
dddddd has joined #linux-sunxi
vagrantc has quit [Ping timeout: 252 seconds]
florianH has joined #linux-sunxi
vagrantc has joined #linux-sunxi
maz has joined #linux-sunxi
maz has quit [Remote host closed the connection]
maz has joined #linux-sunxi
Nevolution213 has joined #linux-sunxi
Nevolution213 has quit [Remote host closed the connection]
yann has quit [Ping timeout: 250 seconds]
aalm has joined #linux-sunxi
msimpson has joined #linux-sunxi
ganbold has quit [Quit: Leaving]
ganbold has joined #linux-sunxi
leviathanch has joined #linux-sunxi
Gerwin_J has quit [Ping timeout: 264 seconds]
<vagrantc>
hrm. pinebook still leaps into the future occasionally ... not as often as the pine64+
<plaes>
is this ARM errata included?
selfbg has quit [Remote host closed the connection]
popolon has joined #linux-sunxi
BenG83 has quit [Ping timeout: 246 seconds]
vagrantc has quit [Quit: leaving]
pgreco has quit [Ping timeout: 272 seconds]
BenG83 has joined #linux-sunxi
yann has joined #linux-sunxi
pgreco has joined #linux-sunxi
pgreco has quit [Ping timeout: 272 seconds]
pgreco has joined #linux-sunxi
megi has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 240 seconds]
nuuuciano has joined #linux-sunxi
aballier has quit [Quit: leaving]
tnovotny has joined #linux-sunxi
aballier has joined #linux-sunxi
aballier has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
catphish has joined #linux-sunxi
lurchi_ is now known as lurchi__
paulliu has quit [Quit: Leaving.]
JohnDoe_71Rus has joined #linux-sunxi
<catphish>
how fast should sdram reads and writes realistically be on an A20? i'd like to know if the limits i'm running into are the result of configuration, or are indeed the absolute limits, maths tells me with a bus speed of 400MHz, DDR and 32 bit transfers, the total could be anything up to 3GB/s, but i'd like to know what's realistic
<karlp>
are you still getting 10MB/sec?
<KotCzarny>
~22MB/s is most in practice
<mru>
just ran a test here, got about 730 MB/s read
<mru>
1900 MB/s write
<KotCzarny>
erm, sorry, misred sdram as sdcard, disregard me.
<karlp>
mru: thats.... quite a difference?
<mru>
writes being faster than reads is normal
<karlp>
I've honestly never tried, but I wouldn't have expected such a difference.
<karlp>
what are you using to test that?
<mru>
a little test program I cooked up a long time ago
afaerber has joined #linux-sunxi
tllim has joined #linux-sunxi
<catphish>
sorry, wandered off there, running a simple a 32-bit memcpy, (a blocking uncached read followed by a buffered write), i see about 300MB/s
<catphish>
mru: thanks for confirming, it's actually write speed i'm most interested in, so perhaps my problem here is actually the individual 32 bit reads, i'll test the reads and writes separately
<catphish>
my current method is just 4 instructions, a 32-bit fetch and increment, a 32 bit store and increment, a compare, and a conditional branch (the latter 2 make the for loop)
<catphish>
if i switch to write-through, that speed drops dramatically (though i've not measured it). i'll put together some better tests, separating the reads and the writes this time
<mru>
various different memcpy implementations range from 340 to 600 MB/s here
<catphish>
so in theory, i should be looking to achieve 1GB/s+ on pure writes, and dramatically less on reads, i suspect my naive memcpy implementation is roughly what you're describing with the 340MB/s
<catphish>
i'm still on my mission to copy a 480x270 framebuffer to a 1920x1080 hdmi output without using the proprietary graphics drivers and opengl, i haven't managed to make the hardware do this with simple linear scaling, so looking into whether i can do it efficiently in software, this has lead me down the rabbit hole of trying to work out how to get good sdram performance
<mru>
the display pipeline should be able to do this
<catphish>
mru: i had this opinion too, but i have failed to make it work :(
<mru>
try harder :)
<catphish>
the only scaling functionality i could find does not appear to support linear scaling, i spent a couple of days trying to work out how to make the DEFE scale linearly, but so far without success
random_yanek has quit [Quit: random_yanek]
<mru>
what do you mean by linear?
<catphish>
1 pixel in, 16 identical pixels out
<mru>
it should be able to do that
<mru>
but it can also do much better
<mru>
that's what those filter coeffs are for
<catphish>
it does a great job of generating a smooth output using the filter, and that may be something i want
reinforce has quit [Quit: Leaving.]
<catphish>
but what i can't seem to achieve is *not* to smooth the edges
<catphish>
i will spend a little more time with the filter settings, i'm not really familiar with the algorithm it's using
<catphish>
i was doing this rather late at night, i'll look at it fresh, thanks mru, still getting my head around a few things at once
aalm has quit [Ping timeout: 245 seconds]
qeed has joined #linux-sunxi
<mru>
it should be possible to get simple pixel replication by setting the filters properly
<mru>
try setting one coefficient to 64 and the rest to 0
<catphish>
that is in fact what i've been trying to do, and it does improve the situation dramatically, but not completely
<catphish>
i'm wondering if actually the problem isn't my filter at all, but the device i'm using to look at the output signal
<catphish>
i'll try plugging it into a real TV with large pixels for clarification
<catphish>
because setting all the filters to "0x00000040" appears to "nearly work"
<mru>
what's the problem?
<catphish>
i'm glad i'm at least trying the right things
<mru>
try setting DEFE_CH0_HORZTAP0_REG and friends to all zeros
<mru>
also set DEFE_CH0_HORZCOEF1_REGN to 0, not 0x40
<catphish>
yeah, sorry that's indeed what i did, thanks for confirming
<catphish>
i didn't really understand what he "tap" options do though
<mru>
unfortunately it's not clear from the manual exactly how all these values are used
<catphish>
that's the problem i've run into, the best results i got were setting the taps all to 0x01010101, and the coefficients to 0x00000040 (0x00000000)
<catphish>
but i don't totally understand what that's doing
<mru>
I'm guessing DEFE_CH0_HORZTAP0_REG sets the pixel offset from the current position for each tap in the filter
<mru>
with TAP1 and up being relative to the previous one
<mru>
since then the defaults would give a range of -3 to 4
<mru>
for horizontal
<mru>
and -1 to 2 for vertical
<catphish>
that's very interesting, thank you, because i was pretty clueless about this, not knowing much about FIR filters
<mru>
very simply, each output pixel is the weighted sum of multiple input pixels
<mru>
the coefficients are the weights
<catphish>
so in theory by having only one non-zero coefficient it should be impossible for anything to be blended
<mru>
yes, then only one input would contribute to each output
<catphish>
i will get the hardware connected up again a little later and test this properly, i'm starting to wonder whether the problem i observed by actually compression in my hdmi capture device, and not the output at all
random_yanek has joined #linux-sunxi
random_yanek has quit [Max SendQ exceeded]
<mru>
with the coefs as you've set them, changing the TAPn values should shift the picture
heatfanjohn has joined #linux-sunxi
random_yanek has joined #linux-sunxi
<catphish>
so the first tap is relative to the start of a block, with 0x80 being the midpoint?
<mru>
looks like 7-bit signed values to me
<mru>
so 0 is 0, 1 is 1, 0x7f is -1, etc
<catphish>
oh, interesting
<mru>
I'd suggest using a simple test pattern, say a grid of 1-pixel lines spaced 16 pixels apart
<mru>
then play around with those registers and see how it behaves
<catphish>
that's much what i did yesterday, but i'll do it all over, now that i have a MUCH better idea of how the maths works
<catphish>
thanks a lot for that
<catphish>
i like to think i have a feel for these things, but the 7 bit signed thing would never have occurred to me
<mru>
I'm just guessing based on the default values listed in the manual
<catphish>
it's also interesting that i'm sure i tried setting them all to zero, and it just broke completely, but i'll do more tests now i properly understand it, and record the results more accurately
<mru>
hah, the R8 manual has a much more thorough description
OneManHateGroup has quit [Ping timeout: 268 seconds]
<catphish>
that's good to know!
<mru>
or course there might be subtle differences in the hardware
<catphish>
i'm actually still really confused about how the frontend works with interleaved rgb data
<catphish>
it seems bizarre that there are always 2 channels to configure (i'd expect one, or 3 when using separate R,G,B layers), but there's 2, even though data is only provided to ch0, ch1 is still used
<catphish>
i'm sure it would make sense if i knew why :)
<catphish>
thanks again :)
<catphish>
i'm reading the R8 manual too, huge improvement
mpmc has quit [Ping timeout: 268 seconds]
<mru>
beware of slight differences though
<mru>
like only 4 horizontal taps instead of 8
<mru>
and no tap offset register
mpmc has joined #linux-sunxi
<catphish>
yeah having no tap offset register makes that document somewhat less useful as a reference, i'll play with it shortly and see what happens
<mru>
the pixel position calculations are probably the same though
scelestic has joined #linux-sunxi
reinforce has joined #linux-sunxi
clemens3 has quit [Ping timeout: 272 seconds]
<catphish>
one thing i'm not totally clear about is why there are 32 separate filters, i assume they operate on different areas of the image
<mru>
that's for non-integer ratios
<mru>
the R8 manual explains it reasonably
<mru>
if you want to read about the maths, look up "polyphase filter"
<catphish>
cool, probably won't attack that one today though
<catphish>
luckily i'm only interested in simple 1:1 mapping, and it looks to me like for other scenarios, the coefficients in the linux tree will do a nice job
<catphish>
well, 1:4 integer
qeed has quit [Quit: Leaving]
tl_lim has joined #linux-sunxi
\\Mr_C\\ has quit [Ping timeout: 268 seconds]
\\Mr_C\\ has joined #linux-sunxi
tllim has quit [Ping timeout: 245 seconds]
anarsoul|2 has joined #linux-sunxi
msimpson has quit [Quit: Leaving]
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
<plaes>
rellla: moving stuff up to 4.18 is a tad aggressive :P
buZz has quit [Ping timeout: 250 seconds]
<plaes>
yesterday I was actually pondering whether to move stuff up to 4.14 :)
<mru>
I need 4.19 for the hdmi output, but that breaks mali
<catphish>
mru: thanks for the pointers earlier, i have just repeated my experiments, and i'm 99% sure the scaling is working correctly, i'm using tap positions of 0,1,1,1(,1,1,1,1), and coefficients of 64,0,0,0(,0,0,0,0), the result looke like this: https://i.imgur.com/bt1KlGd.png - which looks bad, but outputting the exact same pattern using the backend and scaling in software looks the same https://i.imgur.com/4BWE3MZ.png
yann has joined #linux-sunxi
<catphish>
i think the blending that's visibe is being caused t he the compression in my hdmi capture device, not the output itself
<catphish>
this is the same thing viewed on a real TV, it's just as messy, and the same whether i use hardware or software scaling: https://i.imgur.com/bQjaLuZ.jpg
tl_lim has quit [Ping timeout: 250 seconds]
tl_lim has joined #linux-sunxi
<catphish>
overall i'm pretty sure this is good enough, but it would be nice too get a clean read of the hdmi data to be sure
BenG83 has quit [Quit: Leaving]
<willmore>
catphish, I'm sorry, I haven't been following this closely, are you trying to output to a TV?
<catphish>
nb. those images are scales up for visibility, the actual bars are 1px wide, scaled to 4px wide
<catphish>
willmore: HDMI to a HD TV / monitor yes
<willmore>
Ahh, okay.
<catphish>
willmore: i'm attempting to take a low resolution framebuffer (currently 480x270) and scale it to display on a 1080p display
<catphish>
i believe it's working correctly, but the edges look somewhat merged together on every display i'm able to test it on
<willmore>
You want it to look pixel doubled or properly smoothed?
<catphish>
pixel doubled
<willmore>
Then you're on the right path.
<catphish>
i want each pixel scaled up to 4x4 with perfectly hard edges
<willmore>
You likely won't get that with a FIR scaler.
<willmore>
Setting one tap to max is likely your best hope.
<catphish>
that is indeed what i've done :)
<catphish>
one tap (zero offset) is max, others are all zero
<willmore>
You may want to try the different taps as they might differ in offset in a sub-pixel amount.
<catphish>
i *think* this is working, and the results look the same as if i do the same scaling in software
<willmore>
With a 4:1 scaling, they *should* be aligned, but..
<KotCzarny>
and not blue on the edges?
<catphish>
unfortunately even when i do the scaling in software, real displays seem to blend the edges a little
<catphish>
i'm not really sure why
<willmore>
The FIR filter won't like what you're trying to do as it's trying to filter out the imaginary odd harmonics that make the pixels look like squares.
<willmore>
Could be that the display is doing scaling as well. See if it has a 1:1 mode.
<KotCzarny>
catphish: wrong scaling setting in tv options?
<willmore>
Most monitors do that by default if you turn scaling off, but TVs like to do silly things behind your back.
<catphish>
to me it looks like the imag is actually offset by half a pixel
<KotCzarny>
+ overscan/zoom and similar stuff
<catphish>
is that possible?
<KotCzarny>
maybe some hdmi2vga2hdmi cheapo in tv?
<KotCzarny>
or something similar
<willmore>
catphish, try to use a different coefficient in that filter for the sample point.
<willmore>
They could have some that are half pixel.
<catphish>
this occurs even if i don't use the FIR, and do the scaling in software and output it directly to the DEBE
<willmore>
Really looks like the TV is doing some video processing on your signal. Most TVs do shapening, contrast, brightness, etc. modifications unless you go through a lot of pain to tell them not to.
<willmore>
The software scaling is likely a FIR filter, too, though.
<catphish>
no, by software scaling, i mean literally writing the same value to all 16 pixels
<KotCzarny>
maybe you are drawing to yuv plane?
<willmore>
Okay, then you've got something going on in the capture.
<catphish>
now, i assume it's not physically possible for an HDMI signal to be mis-aligned by half a pixel so i can only assume some processing happening somewhere that i'm still not aware of
netlynx has quit [Quit: Ex-Chat]
<KotCzarny>
boot linux/android and display some test image
<willmore>
Likely the TV. I don't know what kind of capture device you're using, but if it's not connected to the PC by a lot of BW, the it's doing some compression of its own.
<catphish>
the fact that it looks the same with the FIR vs just writing the same value to all 16 pixels and not scaling is promising, means i probably do have the right filter settings
florianH has quit [Quit: Connection closed for inactivity]
<catphish>
i don't have a scope nearly fast enough to see the signals directly
<\x>
hello guys
<willmore>
I still suggest you try chainging which of the FIR taps you set to maximal value.
<\x>
realistically, how hot are h2/h3+ devices?
<catphish>
willmore: but the result i get is the same as *not* using the FIR at all, so i wouldn't know if i'd improved it any further afaik
<KotCzarny>
\x: h3 with voltage regilation is ~28C in idle
<KotCzarny>
with heatsink alone
<catphish>
i will have a look at the DE docs to see if there's any other offsets i might have missed though
<KotCzarny>
and ~50-60C under load
<KotCzarny>
without voltage regulation expect 60C in idle and 80-90 under load
<willmore>
catphish, if it looked better than you'd know :)
<willmore>
catphish, and look to see if your TV is doing trick on you.
<\x>
oooh
<\x>
looks like itll be fine for what ill do i guess
<catphish>
i think the displays are the problem, hard to prove though
<\x>
thx KotCzarny]
tl_lim has quit [Ping timeout: 250 seconds]
<\x>
thx KotCzarny
tl_lim has joined #linux-sunxi
<willmore>
catphish, true. Unless you have a capture card that you trust to give you a raw dump with no compression.
<KotCzarny>
\x: depends on the board size, air movement around etc
<catphish>
i don't have a raw 1080p capable capture card sadly
<willmore>
catphish, not even a single frame capture ability that's raw? If it's doing compression, it's got to have room for several full frames in its memory.
<catphish>
the only device i have to hand is designed for games, it only does video
<catphish>
i'm keeping an eye out for a second hand blackmagic 1080p capture card for work, but don't have on yet
<\x>
oooh
<\x>
there are cheap h5's from orangepi tho
<\x>
opi zero
<\x>
i thibk ill order those instead
<mru>
the display engine has a writeback mode
<KotCzarny>
\x: small boards == bigger temp
<mru>
you could try to capture the scaled output using that
<KotCzarny>
opi0+2 is really cute tho
Mr__Anderson has joined #linux-sunxi
<karlp>
nearly as cute as nanopi duo2 :)
<mru>
at least some of the nanopi variants are prone to lockups in case of a power brownout
<mru>
we had to add an external watchdog chip to deal with that
<karlp>
eh, I've got ath79 devices that do that too
<mru>
there's some circuitry on the module that's meant to detect brownouts, but it doesn't always work
<karlp>
stilla rguining with some people whether it should be fixed in uboot or not.
<KotCzarny>
battery backup ftw
<KotCzarny>
my a20 based device is stable as a brick
tl_lim has quit [Ping timeout: 268 seconds]
<catphish>
my a20 runs without even a heatsink, it's magic
tl_lim has joined #linux-sunxi
<anarsoul>
catphish: that's not magic, that's probably throttling :)
<KotCzarny>
and properly working voltage regulation
<KotCzarny>
;)
<[TheBug]>
;)
<\x>
by the way will i see armbian aarch64 for raspi 3?
<\x>
i still have a raspi 3 and yes, ill be trying out other boards soon
<anarsoul>
wrong channel? :)
<KotCzarny>
wrong channel ;)
<\x>
oh
<anarsoul>
for either armbian and raspi 3 :)
<\x>
i thought i was on armbian channel
<\x>
sorry
<[TheBug]>
haha
<\x>
shieet
<\x>
anyway, is the 8 pin flash on opi zero usable?