<Blakegriplingph>
Just wondering about something in relation to a touchscreen I'm using.
<Blakegriplingph>
It's a GSL1680, or at least a variant of it. I managed to dump the firmware off it from a working gslX680.ko, but it's a hex dump and not a C header.
cnxsoft has joined #linux-sunxi
<Blakegriplingph>
Hey there. :)
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-sunxi
TheSeven has quit [Ping timeout: 252 seconds]
bonbons has quit [Quit: Leaving]
akaizen has quit [Ping timeout: 272 seconds]
_whitelogger has joined #linux-sunxi
Blakegriplingph has quit [Quit: Page closed]
akaizen_ has joined #linux-sunxi
akaizen has quit [Ping timeout: 256 seconds]
naobsd has joined #linux-sunxi
p1u3sch1 has joined #linux-sunxi
p1u3sch1_ has quit [Ping timeout: 240 seconds]
StevenWang has joined #linux-sunxi
<StevenWang>
Hello, Master. Which is the best 2-d graphic technology to implement imange moving,scaling and blt-function with hardware acceleration?
<StevenWang>
suported by A31 or A20 Soc in Linux platform.
JohnDoe_71Rus has joined #linux-sunxi
Black_Horseman has quit [Ping timeout: 256 seconds]
ssvb has joined #linux-sunxi
cubear has joined #linux-sunxi
reinforce has joined #linux-sunxi
Andy-D has quit [Ping timeout: 252 seconds]
Andy-D has joined #linux-sunxi
imcsk8 has quit [Quit: Reconnecting]
imcsk8 has joined #linux-sunxi
Net147 has joined #linux-sunxi
qemandro has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
bbrezillon has quit [Quit: WeeChat 0.4.2]
premoboss has quit [Remote host closed the connection]
qemandro is now known as shineworld
shineworld has quit [Quit: Sto andando via]
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
hansg has joined #linux-sunxi
whitesn has quit [Remote host closed the connection]
selfbg has joined #linux-sunxi
selfbg has quit [Client Quit]
dev1990 has joined #linux-sunxi
kivutar has joined #linux-sunxi
bbrezillon has joined #linux-sunxi
dev1990 has quit [Client Quit]
hansg has quit [Quit: Leaving]
sehraf has joined #linux-sunxi
leviathanch has joined #linux-sunxi
prz has joined #linux-sunxi
<leviathanch>
wens: maybe you can write to the engineer of the DRAM controller and suggest to him that he configures the registers for it correctly within the mainline u-boot?
<leviathanch>
wens: as far as I understodd he has issues with any other language than Mandarin
<leviathanch>
*understood
<leviathanch>
wens: and I think your Chinese is a lot better than mine ^^
<wens>
i don't follow
<wens>
for which SoC?
<wens>
leviathanch: also i sent out a80 prcm drivers today
<wens>
leviathanch: could you ping anyone related @ aw? the patches are on linux-arm-kernel
<leviathanch>
wens: 杰文 just returned from Chinese hollidays this week
<leviathanch>
wens: many of the engineers still are at their families and not available
<leviathanch>
wens: you would need to ask Flord (on Mandarin) for informations about the DRAM controller
<leviathanch>
or most preferrable just ask him to just configure the registers himself
Net147 has joined #linux-sunxi
<leviathanch>
they are afraid of RockChip copying their chip design so they are very sensitive about the A80 DRAM interface
<leviathanch>
and I see a real threat with Rockchip too, so the best solution would be to let Flord do the work in mainline himself
<leviathanch>
which would be sensitive to the design issue
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
<leviathanch>
wens: I've seen your patches
<wens>
i'm not working on u-boot though
<leviathanch>
okey
JohnDoe_71Rus has joined #linux-sunxi
<leviathanch>
it's more like: you can write Mandarin :)
<leviathanch>
wens: better than I do ^^
<wens>
you should shoot off an email to all related parties first, it's less confusing
<leviathanch>
wens: ah, ok
<wens>
who is 杰文?
<leviathanch>
wens: a friend at Allwinner
<leviathanch>
Martin is his European name
<leviathanch>
he does Software-Engineering there
<leviathanch>
and helped me out when talking to the folks there, because my Chinese is still bad
<leviathanch>
:(
<leviathanch>
anyway
<leviathanch>
he wants to improve his English and I wanna learn to talk Chinese
<leviathanch>
so we are Skyping a lot
<wens>
I see
gianMOD has joined #linux-sunxi
<leviathanch>
at the moment the office in Zhuhai is still half deserted because it has been Chinese new year
<wens>
see, throwing a name out without context is a bit confusing :p
<leviathanch>
^^
<leviathanch>
sorry
<leviathanch>
对不起! ^^
<leviathanch>
wens: my vocab and spelling is very limited and flord has issues with English
<leviathanch>
wens: but we came to the conclusion that he could do the coding work himself at the part
<leviathanch>
*party
wickwire has joined #linux-sunxi
_massi has joined #linux-sunxi
bonbons has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
StevenWang has quit [Quit: Leaving]
naobsd has quit [Remote host closed the connection]
HeHoPMaJIeH has joined #linux-sunxi
HeHoPMaJIeH has joined #linux-sunxi
naobsd has joined #linux-sunxi
kaspter has quit [Ping timeout: 244 seconds]
gianMOD has quit [Remote host closed the connection]
naobsd has quit [Quit: naobsd]
naobsd has joined #linux-sunxi
gzamboni has quit [Ping timeout: 252 seconds]
ricardocrudo has quit [Ping timeout: 250 seconds]
Andy-D has quit [Ping timeout: 245 seconds]
mzki has joined #linux-sunxi
Andy-D has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
gianMOD has joined #linux-sunxi
simosx has joined #linux-sunxi
gianMOD has quit [Ping timeout: 256 seconds]
selfbg has joined #linux-sunxi
naobsd has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
<plaes>
hrm.. should we expect that people who are able to send email to linux-sunxi to read man pages?
FR^2 has joined #linux-sunxi
Blakegriplingph has joined #linux-sunxi
<Blakegriplingph>
plaes: You're not referring to me, are you?
<plaes>
I am.. :)
<Blakegriplingph>
lol
<Blakegriplingph>
bear with me though, I'm kinda' new to this
<ssvb>
pirea: there are quite a number of other tests which could help to pinpoint the root cause, you can try to reduce the display resolution to see if it helps and also check the known video samples
<ssvb>
pirea: if there is something wrong specifically with this particular file, then maybe you could ping jemk
<pirea_>
ssvb i have something to do but i'll be back
<ssvb>
ok
leviathancn has joined #linux-sunxi
<pirea_>
ssvb btw scaler mode is enabled
<pirea_>
and i have uboot 01.2015
<pirea_>
and sunxi_ve_mem****=128
<NetForHack>
what i need install for do "cp /usr/bin/qemu-arm-static /mnt/usr/bin/" ?
<NetForHack>
qemu package don`t include it
quitte has quit [Ping timeout: 246 seconds]
<atsampson>
NetForHack: it's the qemu-user-static package on Debian
<ssvb>
pirea_: in your case the risk factors are: your mkv file (it may be somewhat special), the archlinux distribution (very few people are using it afaik, and it is mostly untested) and the 1080p display resolution to some extent (potential memory bandwidth issues)
<ssvb>
pirea: try to remove some of these risk factors just to see if everything else works
<NetForHack>
atsampson: what about ubuntu ?
<NetForHack>
ow
<NetForHack>
the same
<NetForHack>
obvilious
<libv>
NetForHack: what device are you working on?
<NetForHack>
libv: dat shitty a10s mk802 clone
<libv>
NetForHack: why don't you start working through the new device howto first?
<NetForHack>
becuse i dont have stock andoid
<libv>
but you have almost all of the other information right there
<NetForHack>
i flash image from the internet that works bad
<pirea>
ssvb resolution of my display is 720p, movie is 180p
<libv>
i tracked down someone with the exact same device
<pirea>
1080p*
<libv>
NetForHack: he probably is bored with the device today
<libv>
so i really doubt he will work through the new device howto
<libv>
but if someone has gone and done all of the other work of the new device howto, and created a proper device page, he might be more easily coerced
<NetForHack>
libv: i`ve seen some guy in mailing list, i emalied him for nand backup or just fex
<libv>
before you have done as much as you can on the ndh, you are telling us all here that you are just going to waste our time
whitesn has joined #linux-sunxi
<NetForHack>
libv: i wrote dat page after make shure that i have an working device, what sense wrote about a brick ?
reinforce has quit [Quit: Leaving.]
<libv>
if you have done the device page properly, you will have proven that you are capable of doing the basics, and that we here are not having our time horribly wasted
<libv>
NetForHack: i told you before
<libv>
NetForHack: if you can go to this other guy with an almost complete device page, he is much more likely to spend a few minutes to get you that fex
whitesn has quit [Client Quit]
<libv>
a device page without a fex is not a waste
whitesn has joined #linux-sunxi
<libv>
someone else might come along and pick things up
gianMOD has quit [Ping timeout: 264 seconds]
<libv>
why do i have to keep on repeating this when this sort of thing has been written up in the wiki?
whitesn has quit [Client Quit]
whitesn_ has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
whitesn_ has quit [Client Quit]
whitesn has joined #linux-sunxi
gianMOD has joined #linux-sunxi
premoboss has joined #linux-sunxi
NetForHack has quit [Quit: Page closed]
premoboss has quit [Ping timeout: 252 seconds]
arete74 has quit [Read error: Connection reset by peer]
gianMOD has quit [Remote host closed the connection]
afaerber_ has joined #linux-sunxi
<wens>
Turl: how's it coming?
afaerber has quit [Ping timeout: 244 seconds]
gianMOD_ has joined #linux-sunxi
afaerber_ has quit [Quit: Verlassend]
<Turl>
wens: I need to rebase on -rc1 and resend for the most part
buZz has quit [Ping timeout: 240 seconds]
khuey|away is now known as khuey
buZz has joined #linux-sunxi
buZz is now known as Guest80742
Guest80742 is now known as buZz
reinforce has joined #linux-sunxi
leviathancn has quit [Ping timeout: 264 seconds]
gianMOD_ has quit [Remote host closed the connection]
gianMOD has joined #linux-sunxi
gianMOD has quit [Ping timeout: 246 seconds]
reinforce has quit [Quit: Leaving.]
leviathancn has joined #linux-sunxi
Andy-D has quit [Ping timeout: 250 seconds]
Andy-D has joined #linux-sunxi
di-erz has quit [Ping timeout: 246 seconds]
leviathancn has quit [Ping timeout: 240 seconds]
leviathancn has joined #linux-sunxi
di-erz has joined #linux-sunxi
Netlynx has joined #linux-sunxi
gianMOD has joined #linux-sunxi
di-erz has quit [Ping timeout: 240 seconds]
ssvb has quit [Ping timeout: 255 seconds]
gianMOD has quit [Remote host closed the connection]
afaerber has joined #linux-sunxi
di-erz has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
prz has quit [Ping timeout: 264 seconds]
leviathancn has quit [Ping timeout: 264 seconds]
premoboss has quit [Remote host closed the connection]
Andy-D has quit [Ping timeout: 245 seconds]
MY123 has joined #linux-sunxi
dev1990 has joined #linux-sunxi
<Turl>
ls
<Turl>
ugh
<plaes>
nope
<lioka>
nope~
F1skr has joined #linux-sunxi
jinzo_ has joined #linux-sunxi
jinzo_ has quit [Client Quit]
Vanfanel has joined #linux-sunxi
<Vanfanel>
hi. Is there a way to copy data from a ram buffer to the framebuffer without using these SLOW memcpy() calls??
shinobi has joined #linux-sunxi
quitte has quit [Quit: Lost terminal]
<libv>
Vanfanel: do not privmsg these things.
gianMOD has joined #linux-sunxi
<Vanfanel>
libv: sorry, I didn't know it wasn't a bad idea to ask. Is it better to ask in the channel, then?
<libv>
Vanfanel: first off, do you think i am allknowing?
<Vanfanel>
libv: no, I don't think so, but I seem to recall you know a lot about G2D
<libv>
Vanfanel: so where would be a better place to ask?
<Vanfanel>
libv: I don't know a better place than this channel to ask about specific sunxi G2D implementation
<Vanfanel>
but if there is a better place, please tell me
<libv>
so why didn't you do so from the start?
<libv>
your question here is later than your privmsg, and it contains less information.
<libv>
you had a question about sunxi g2d and memcpy
<libv>
so you should come ask here
gzamboni has joined #linux-sunxi
<libv>
the one with the experience there is ssvb, but don't try to privmsg him either.
<libv>
ssvb will answer here when he has time.
akaizen_ has quit [Read error: Connection reset by peer]
<Vanfanel>
libv: ok, ok, sorry again. I won't private message you again.
akaizen has joined #linux-sunxi
<libv>
at least not with "help me on $topic_that_has_a_much_better_target"
<Vanfanel>
libv: by target you mean "the person I ask to"?
<libv>
no.
<libv>
you seem to have missed the point of the last 10 minutes.
<Vanfanel>
look, I don't want to annoy anybody, really. I am really sorry for having pm-ed you
<libv>
learn how to make best use of the different mediums.
<Turl>
Vanfanel: messaging random people with random questions is bad etiquette, just keep that in mind
<libv>
in this case, it was just extremely bad judgement, even ignoring the fact that it was bad etiquette
gianMOD has quit [Remote host closed the connection]
<libv>
it was a sunxi question, so #linux-sunxi has a much higher probability of getting an answer
<Vanfanel>
ok, I understand. I won't make the same mistake again, really
<libv>
what's more, if the question was more specialized, and thus the audience should've been much wider, the mailinglist was the place where an answer would've had the highest chance.
<libv>
and yes, GL is not always a super fit and it could be optimized
<libv>
but vulkan/mantle are going to mean that applications will be a lot less portable
<libv>
already portability is an issue with gles1/2/3
<libv>
these things will make it much much worse
<libv>
replacing the hw is always possible
<libv>
rewriting a 5y old application is not
<libv>
amd threw down the gauntlet with mantle, solely because it could as it owns the console market at this point
<libv>
ibm powerpc owned the console market in the previous generation
<Turl>
libv: but assuming everything is standarized to SPIR-V as they claim, wouldn't it Just Work? (barring runtime bugs?)
<libv>
Turl: an ir is a lower level representation for shaders
<libv>
Turl: state management is also a big factor
<libv>
Turl: remember, lima was proactively split, by me, into two different subprojects
<libv>
command stream and shader
<libv>
spir-v covers the shader bit
<libv>
vulkan covers the command stream/driver bits
<libv>
mesa has several different IRs
<libv>
and now a new one will be added into the mix
<libv>
that is, if it gains traction at all
<libv>
then there is the issue of what will happen with subsequent hw generations
<libv>
vulkan is probably a good match for current gles3/gl4 hw
<libv>
but what's next?
<Turl>
Initial specs and implementations expected this year
<Turl>
Will work on any platform that supports OpenGL ES 3.1 and up
<Turl>
that's what the site says
<libv>
that's very limited
<libv>
why can it not work on gles2 hw?
<MY123>
libv, Probably 3d text
<MY123>
*ures
<libv>
MY123: wrong
<libv>
MY123: uniforms buffers
<MY123>
libv, only as extension on GLES2
<libv>
uniform buffers are the reason
<libv>
at least the main reason i can spot from the limited information available
<MY123>
libv: They should be HW supported
<libv>
mali has bits of memory for uniform storage and can do uniform buffers
<Turl>
3.1 is adreno 4xx right?
<MY123>
libv: At least on Mali and VideoCore
<MY123>
(2nd gen)
<libv>
other gles2 era hw might have this too, others might just have this embedded in the command stream
<libv>
but even then, they could be generated
<libv>
err, emulated
<libv>
doesn't make things faster, but could make things compatibke
<libv>
so i am amazed that they made this gles3.1 hw only
<MY123>
libv: Does Mali400 fully support 3D texture support?
<libv>
they could've made it a slight bit more generic and made 3d textures an extension
<libv>
for which a driver could query
<libv>
that would've severely helped getting traction
<libv>
which is what this game is all about now
<MY123>
libv, Can you run geometry shaders on the Mali400?
<MY123>
(or it's a VC3/4 nice ahead of time feature?)
<libv>
i am not entirely sure yet what geometry shaders are, i am not fully versed on the difference between them and vertex shaders yet
<libv>
you cannot with the binary driver, you could perhaps do so with an open source shader compiler
<libv>
i do not know the details of what a geometry shader needs over a vertex shader
<linkmauve1>
MY123, AFAIK no, there is no dedicated geometry units on the Mali400.
<libv>
geometry units?
<linkmauve1>
libv, it can emit vertices.
<linkmauve1>
That’s the main difference.
<libv>
linkmauve1: how is that different from a fragment shader?
<libv>
err vertex
<libv>
mali takes some data in some memory, does some calculations on it, then sticks that data in some other memory
<linkmauve1>
A vertex shader transforms an input vertex into an output vertex, suitable for fragment shader consumption.
<linkmauve1>
A geometry shader can emit more than one vertex.
<libv>
then the tiler kicks in
<libv>
apart from the running of the vertex shader command stream being synced with the tiler command stream on mali400, it could very well be that the architecture can be coerced into doing it
<linkmauve1>
libv, wait, it’s not vertices the geometry shader emits, but primitives.
<linkmauve1>
It can take a point as input and emit a ten-vertices triangle-strip for example.
afaerber has quit [Quit: Verlassend]
<linkmauve1>
Or a triangle and emit five lines.
<linkmauve1>
Or any combinaison.
<libv>
ok
<linkmauve1>
And the geometry shader is executed after the vertex shader stage, in the pipeline.
kivutar has quit [Ping timeout: 246 seconds]
kivutar has joined #linux-sunxi
<libv>
anyway, all of this is pretty preliminary
<libv>
no details are known
<libv>
mantle has traction with game engines as all the consoles benefit from it
<MY123>
libv: except the XBox One
<libv>
khronos is "a standard" from a consortium
<MY123>
(locked to DirectX)
<MY123>
libv, you need to pay fees to pass the certification
_massi has quit [Remote host closed the connection]
<libv>
what i see from that is that the console market doesn't care about mantle
<libv>
so it is per definition dead
<MY123>
libv: Yeah, as the console HW is already outdated
<libv>
which could be both a good and a bad thing for vulkan
<MY123>
(at the time it was released)
<libv>
wait and see.
<MY123>
libv: I would like nVidia releasing true Maxwell docs...
<MY123>
but that may be just a dream
FR^2 has quit [Quit: Connection reset by peer]
alexxy has quit [Quit: No Ping reply in 180 seconds.]
gianMOD has joined #linux-sunxi
alexxy has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
ricardocrudo has quit [Remote host closed the connection]
ssvb has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
gianMOD has joined #linux-sunxi
<MY123>
libv, There will be Vulkan on the VideoCore V
<MY123>
(apparently, that will be published soon)
leviathanch has quit [Ping timeout: 265 seconds]
wickwire has quit [Ping timeout: 244 seconds]
<ssvb>
MY123: are there any devices with VideoCore V?
leviathanch has joined #linux-sunxi
<MY123>
ssvb, only in the Broadcom labs currently
<ssvb>
so why should we care/speculate about it now?
<MY123>
ssvb: As it will probably be in a future product
<ssvb>
Vanfanel: you probably don't want to do redundant copies in the first place, regardless whether they are done by the CPU or G2D
domidumont has joined #linux-sunxi
<Vanfanel>
ssvb: I don't understand I am making redundant copies. I need to memcpy from a ram buffer to framebuffer, because the g2d blitting function requires both src and dst to be in the same buffer, according to the function docs
F1skr has quit [Quit: WeeChat 1.1.1]
<ssvb>
Vanfanel: if you need the best performance, then your buffers should be all in the framebuffer (or some other physically contiguous chunk of memory)
<ssvb>
Vanfanel: then you just setup a hardware layer to make it visible on screen
<ssvb>
Vanfanel: instead of copying stuff around, you only need to re-configure layers
<Vanfanel>
do you mean reconfigure buffers, right?
<Vanfanel>
as in "have all the buffers in contiguous chunk of memory"
<Vanfanel>
I am already using a layer
<ssvb>
both the g2d and the display engine can only work with physically contiguous memory
<Vanfanel>
can the layer read from ram then?? no need to memcpy() anything into framebuffer??
<ssvb>
everything is in ram (including the framebuffer)
<Vanfanel>
ssvb: yes, that's physically true, of course, but sunxi_layer_set_rgb_input_buffer() seems to need things to be in the framebuffer
<ssvb>
that's just a software implementation, tailored for some specific purpose
<ssvb>
you can't make assumptions about the hardware capabilities by just looking at this code
<Vanfanel>
ssvb: yes, of course, but this code is what I have until now :P
<ssvb>
implement a better code :-)
<Vanfanel>
so it's possible to implement something similar to sunxi_layer_set_rgb_input_buffer() so the layer reads from a normal ram buffer, right?
<ssvb>
please define what is "normal ram buffer"
<Vanfanel>
I mean, it would require to call the same ioctl() that sunxi_layer_set_rgb_input_buffer() calls in the end, with different parameters, right?
<Vanfanel>
ssvb: normal ram buffer = a buffer in memory that has not been memcpy-ed to the framebuffer
<ssvb>
that's still ambiguous
<Vanfanel>
hmm, a simple malloc-ed void*
<Vanfanel>
can the layer be reading from there?
<ssvb>
malloc-ed buffer will not work, because it is not physically contiguous
<ssvb>
it may consist of a lot of 4k pages, scattered all around the physical ram
<Vanfanel>
ssvb: let's say it's "static uint16_t video_out[256 * 240]": will that work?
<Vanfanel>
reading from video_out I mean
<ssvb>
you need to specifically allocate physically contiguous buffers with the help of the kernel driver
<ssvb>
which may either use static reservation or cma
<Vanfanel>
so in the end I need to use memcpy, because I can't decide what the app draws into
<ssvb>
and you also need to deal with cache coherency if you want to access the same buffer with the cpu, the g2d accelerator and the display engine
<ssvb>
yes, if the application only provides you with a malloc-ed buffer, then you have no choice
<Vanfanel>
those things are way above my head, really. I don't even know what cache coherency means :D
F1skr has joined #linux-sunxi
<Vanfanel>
what I receive is that "static uint16_t video_out[256 * 240]" thing really. Not a malloc-ed buffer, sorry.
<Vanfanel>
memcpy() is necessary then?
<ssvb>
maybe try to fix this application to implement a custom allocator for memory buffers?
<ssvb>
btw, uint16_t video_out[256 * 240] is very small
<ssvb>
you should not have any significant performance problems even doing memcpy
<Vanfanel>
I do. Tried removing memcpy() and I get some extra fps...
<Vanfanel>
not that I see a thing on screen of course :D
<ssvb>
how much extra fps?
gianMOD has quit [Remote host closed the connection]
<ssvb>
and the g2d copy is not free either, it runs at approximately the same speed as memcpy, but does not peg the cpu core
<Vanfanel>
I get rock-solid snes emulation without memcpy(), where I get ~57FPS with it. So, like rock-solid 60FPS vs 57FPS which causes audio to go broken.
ikeeki has joined #linux-sunxi
<ssvb>
you could estimate the potential g2d "acceleration" effect by doing a dummy copy of the same size
<ssvb>
and if you use dual-core a20, then you can do memcpy in a separate thread too
MY123 has quit [Read error: Connection reset by peer]
Netlynx has quit [Quit: Leaving]
<Vanfanel>
ssvb: yes, I am using a dual-core A20 and tried to do memcpy in a different thread, but I found it impossible to implement after trying: let's say a second game loop (because we don't block on memcpy call because it's in another thread) writes into the origin buffer while we are doing the memcpy: we will get part of a frame and part of the next frame. tearing-like effects.
<Vanfanel>
Of course I have a double-buffer mechanism but it's not use: if the game writes to the origin buffer while memcpy being done, artifacts are logically showing up.
<Vanfanel>
memcpy must be done synchronously with the game thread
<ssvb>
this is normally solved by triple buffering
<ssvb>
if you are doing the copy synchronously, then g2d is not going to help at all
<ssvb>
it will only make the cpu go idle during the copy, but will not improve fps
gianMOD has joined #linux-sunxi
<Vanfanel>
g2d? what part of g2d? hardware blitting DOES help here
<Vanfanel>
as does scaling
<ssvb>
how much does the hardware blitting help?
<Vanfanel>
the problem is that the game always writes to the same buffer, the one I receive
<ssvb>
yes, scaling is slow in software, so accelerating it with g2d or using scaled layers makes sense
<Vanfanel>
I haven't done exact time measurements but it's way faster than software blitting for sure
<ssvb>
just do the measurements and come back
<Vanfanel>
ok, but really, what's taking CPU time here is memcpy()
<ssvb>
the faith based approach does not work for optimization
<Vanfanel>
it's not faith: if I remove the memcpy() call I get rock-solid 60FPS
<ssvb>
would you prefer to have the CPU doing nothing instead?
<Vanfanel>
I can see and hear it
<Vanfanel>
I would prefer the CPU not block in the memcpy and go instead
<Vanfanel>
I mean, doing something like memcpy() just way faster
<ssvb>
don't just remove memcpy, but replace it with a dummy g2d blit between two locations in the framebuffer
<ssvb>
and you will get your potential accelerated performance numbers
mrnuke has quit [Ping timeout: 265 seconds]
<Vanfanel>
on the Pi there's this write_data videocore, which is fast as lighting, sorry for the comparision
<Vanfanel>
ok
<ssvb>
how fast is this "write_data videocore" in terms of MB/s? because "fast as lighting" smells like a faith based approach again
<ssvb>
anyway, I have a very strong dejavu feeling
<ssvb>
I think that we have had exactly the same irc discussion earlier, but I need to check the logs
shinobi has quit [Quit: Konversation terminated!]
<Vanfanel>
ssvb: quite possible, I've been trying to speed up things on this Cubie2 for quite a long time
<Vanfanel>
ssvb: you are right, g2d blit between framebuffer regions is as slow as memcpy...
<Vanfanel>
thought it was done in hardware somehow, using a DMA or whatever
<ssvb>
it is done in hardware
<ssvb>
but there is no magic involved, something still needs to move bits in the DRAM and it takes time
<Vanfanel>
anyway, if I want hardware-scaled graphics via the layer, I need to use the memcpy
<Vanfanel>
and the blitting is necessary too
domidumont has quit [Ping timeout: 246 seconds]
gianMOD has quit [Remote host closed the connection]
premoboss has joined #linux-sunxi
<ssvb>
Vanfanel: the recipe for fixing all of these performance problems is triple buffering (with the buffers either in the framebuffer or in some other physically contiguous memory area) and the use of scaled layers
<ssvb>
Vanfanel: you don't even seem to need g2d at all
<Vanfanel>
ssvb: yes, but for that, the app should be triple-buffering. Instead, it's writing over the same buffer over and over. I can do triple-buffering "externally" and not block on vsync waiting, moving vsync wait to another thread, but memcpy() is a different story: it has to be done in the main game thread OR the game will overwrite it's buffer during memcopy() and that causes tearing, I have already tried
<Vanfanel>
I DO use external triple buffering with a queueing mechanism, to avoid blocking on vsync waiting
<Vanfanel>
but for memcpy() that can not be done
gianMOD has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
<linkmauve1>
Am I right in that KVM isn’t available on A10, but is on A20?
<ssvb>
Vanfanel: if the application can't implement triple buffering (it sometimes reads back from the buffer or performs partial updates), then this means exactly one memcpy per frame for you
<ssvb>
Vanfanel: and no g2d or other overhead
<linkmauve1>
And in this case, which option do I hate to emulate another ARM machine with the least possible overhead in the CPU emulation? I already take care of everything else.
<Vanfanel>
ssvb: I still need to do the blitting, be it g2d or my software implementation, because when you memcopy the frame from source to framebuffer, it's copied with all lines one after another. If I don't "construct" the frame, what the scaled layer shows is garbage.
<ssvb>
Vanfanel: yes, one memcpy per scanline in this case, which is not very much different
<ssvb>
Vanfanel: however, are you sure that you set up stride for the scaled layer correctly?
<ssvb>
Vanfanel: if you do, then a single memcpy per frame should be still usable
Black_Horseman has joined #linux-sunxi
<Vanfanel>
ssvb: yes. The problem is that some emulation cores in RetroArch (which is what I'm trying to improve) don't produce packed frames: there is stuff or simply black pixels between each scan line
<Vanfanel>
so it's scanline_starting_addr = prev_scanline + total_pitch, being the total pitch different from the visible pitch
<ssvb>
Vanfanel: so what? this should be supported
<ssvb>
Vanfanel: unless you want to skip copying these extra gaps for performance reasons
<Vanfanel>
it's supported, but blitting (ie, taking ONLY the needed pitch of each line) is needed as far as I understand...
<Vanfanel>
ssvb: also, I need 16-to-32 bpp conversion, which g2d blitting func does
paulk-collins has quit [Quit: Quitte]
<ssvb>
Vanfanel: in this case you can use pixman 16-to-32 bpp conversion and still avoid g2d overhead
<Vanfanel>
ssvb: do you have an example on that? I don't know what pixman is
ikeeki has quit [Remote host closed the connection]
<Vanfanel>
ok
cooper has joined #linux-sunxi
<cooper>
I'm completely stoked because I managed to get 4.0-rc1 going on one of my Nanos, but I've got this tiny little snag.
<cooper>
From the bootup log:
<cooper>
[ 4.937266] EXT4-fs (mmcblk0p2): Filesystem with huge files cannot be mounted RDWR without CONFIG_LBDAF
<ssvb>
Vanfanel: well, not exactly this one though, because conversion between formats needs 'pixman_image_composite32' instead of 'pixman_blt'
<cooper>
Now, the device it's talking about is my 16 GB SD card.
<ssvb>
Vanfanel: I can update this demo program to add benchmarks for 16->32 and 32->16 bpp conversion
<cooper>
So, why complain about this? The largest file on the system is under 4 GB.
<cooper>
In fact, under 1 GB.
<cooper>
But I currently have a read-only mounted filesystem.
<Vanfanel>
ssvb: no, don't do anything for me, really. I'm about to give up on this whole Allwinner stuff. It's too much for me.
<Vanfanel>
ssvb: I really thank you for your help, but this is crazy...
<ssvb>
Vanfanel: how much fps do you get with the Raspberry Pi?
<atsampson>
cooper: I think it's a filesystem feature thing (i.e. it might not have huge files, but it does have the huge_file option turned on)
<cooper>
Hrmm...
<atsampson>
cooper: does "tune2fs -O ^huge_file /dev/whatever" help?
<atsampson>
(I'm not sure if that's actually a feature you *can* turn off...)
<atsampson>
alternatively, is there some reason not to turn on CONFIG_LBDAF in your kernel config?
<Vanfanel>
ssvb: The original Pi is not comparable, but with, let's say, the Odroid U3, I get rock solid 60FPS even in the most demanding Super-FX games
<Vanfanel>
ssvb: I don't have a Pi2 yet, it's coming next week
<cooper>
atsampson: Trying a wee bit too hard to deactivate stuff I'm "obviously not going to use".
<cooper>
atsampson: Famous last words, I'm sure. :)
<atsampson>
cooper: given that huge_file is in the default ext4 options, I think that's probably an option too far to turn off ;-)
<cooper>
atsampson: Okay, thanks, I'll reboot to the old kernel, rebuild with the feature enabled and try again. Still, *VERY* pleased. Basically everything that matters to me on this system aside from that one thing works.
<ssvb>
Vanfanel: how so? didn't you mention that Pi was "fast as lighting"?
<Vanfanel>
ssvb: the vc_write_data() function is.
<ssvb>
Vanfanel: as for the Pi2, it should be roughly the same as Allwinner A20 for the single-threaded performance
<atsampson>
cooper: you should at least be able to build pretty quickly if you've still got the built kernel tree sitting around...
<cooper>
I do.
<Vanfanel>
ssvb: yeah, but with vc_dispmanx_write_data() function, performance will be a lot better.
cubear has quit [Quit: Leaving]
<ssvb>
Vanfanel: you still have not provided the MB/s numbers for it, so we can't be sure ;-)
<Vanfanel>
and it has an VCOS thread for vsync callback, and many more nice things :P
<ssvb>
Vanfanel: I can believe that everything just performs a lot worse when compared with this vc_dispmanx_write_data() function there, so on a relative scale this function does not look like an obvious bottleneck
<Vanfanel>
not to mention dispmanx API is braindead easy once you know it. G2D is proving hard and strange...
<Vanfanel>
anyway, I got similar performance to the GLES2-based renderer in RetroArch using G2D on the Cubie2, so that should suffice to me as a personal "adventure"
<Vanfanel>
same performance with no binary blobs involved is good
<ssvb>
Vanfanel: you don't really need to use G2D in your code (doing this wastes performance), and the dispmanx counterpart on sunxi hardware are disp layers
<Vanfanel>
ssvb: dispmanx gives me hardware blitting, since write_data accepts random pitches so blitting and uploading is done with a simple, single call
<Vanfanel>
no need to memcpy(), no need to manual blitting
<ssvb>
Vanfanel: I doubt about it actually doing hardware blitting if you are using malloc buffers
gianMOD has quit [Remote host closed the connection]
<ssvb>
Vanfanel: you can still use pixman instead of "memcpy + g2d 16bpp->32bpp blit", and this should be faster
<ssvb>
Vanfanel: yes, it is not integrated as part of a convenient API on allwinner hardware, but still very much doable
<Vanfanel>
ssvb: with no docs and no examples? It's too much for an aficionado, really. We need good APIs like dispmanx :(
<libv>
Vanfanel: who do you expect to do the work?
<ssvb>
Vanfanel: didn't you say that you don't want an example?
<Vanfanel>
Allwinned I suppose. Broadcom did the job with dispmanx.
<Vanfanel>
Allwiner, sorry
<Vanfanel>
agh
<Vanfanel>
Allwinner
<libv>
Vanfanel: complaining in here then doesn't help
<ssvb>
Vanfanel: you are free to write an online petition :-)
Zotan has quit [Remote host closed the connection]
Zotan has joined #linux-sunxi
<Vanfanel>
yes, yes, sorry, I'm not complainig! I was just discussing with ssvb about how I feel about all this.
Renard has joined #linux-sunxi
<Vanfanel>
you guys have been very helpful, really
<Vanfanel>
and patient too
<ssvb>
libv: oh, very cool, now I don't need to do u-boot mainlining for the Forfun Q88DB tablet :-)
petr has quit [Remote host closed the connection]
leviathancn has joined #linux-sunxi
* ssvb
likes when the work is getting done by the others
petr has joined #linux-sunxi
<libv>
:)
<libv>
damn, i should've sent you the other a10 tablet then :p
<libv>
oh, a13, since it is a q8
leviathancn has quit [Ping timeout: 265 seconds]
dev1990 has quit [Quit: Konversation terminated!]
<libv>
ssvb: we do need to keep better tabs on people posting things to u-boot
<libv>
could it be that uboot requires those urls?
<libv>
if so, we better make sure that they actually exist and that people spend a few hours creating the device pages
<ssvb>
u-boot does not require these linux-sunxi wiki urls, but looks like I had just started a new fashion when mainlining u-boot support for the msi primo tablets :)
<libv>
ok, well done then :)
<libv>
how does uboot ensure long term maintainance without such a thing?
<libv>
not at all probably
<libv>
if so, they are going to have a massive problem on their hands at some point
mrnuke has joined #linux-sunxi
<Vanfanel>
ssvb: ok, been thinking about this in the shower. I'm going to try the 1-memcpy + pixmam 16-32bpp route. Can you provide the pixman example you were going to provide earlier?
<Vanfanel>
I can't simply think "I can not do it", I have to try
<ssvb>
Vanfanel: that would be a single pixman call without memcpy, because this is the whole point
<Vanfanel>
ssvb: what about the layer needing the pixel array to be in framebuffer? For that, I need a memcpy...
petr has quit [Remote host closed the connection]
<ssvb>
Vanfanel: pixman can move pixels from the malloc buffer to the framebuffer and also do the 16bpp -> 32bpp conversion on the fly using NEON
petr has joined #linux-sunxi
<Vanfanel>
ssvb: ok, ok. Mind you I already have tried a NEON memcpy implemention and it's not much faster..
<ssvb>
Vanfanel: it is memory bandwidth limited just like memcpy and g2d
<Vanfanel>
but ok, give me a call example on the function that does all that, and I will try to use that instead of memcpy + g2d blitting
<Vanfanel>
oh, ok
<ssvb>
you can get better performance because you don't need to move pixels twice (once with memcpy and one more time with g2d)
<ssvb>
ok :)
<Vanfanel>
oh, ok. pixman_blt() is the man, maybe?
<ssvb>
well, it will return FALSE if you call this function with different bpp for the source and destination
<ssvb>
a bit different function is needed
<Vanfanel>
wait, what about setting my video mode to 16bpp? that way it would be 16bpp->16bpp
ricardocrudo has quit [Remote host closed the connection]
<Vanfanel>
will the scaler work with a 16bpp pixel array?
<ssvb>
no, the scaled layer needs 32bpp
<Vanfanel>
I mean, the layer using the 16bpp as source
<Vanfanel>
agh :D
<Vanfanel>
then 16bpp to 32bpp is needed
<ssvb>
that's why we need the 16bpp to 32bpp conversion in the first place
<ssvb>
yep
<Vanfanel>
so there's no pixman function ready to use, is there?
<Turl>
Vanfanel: out of curiosity, have you disabled cpu scaling?
<Vanfanel>
Turl: where? on the software I'm trying to improve?
<Turl>
Vanfanel: on the cpu (ie, using performance governor or disabling cpufreq altogether)
<Vanfanel>
ahhh!! CPU freq scaling!
<Vanfanel>
Turl: yes, I'm using the performance governor, full 1.2 GHz or the like
<Vanfanel>
the board doesn't get very hot so it's ok
<ssvb>
Vanfanel: this board can't really run reliable at 1.2GHz
<Vanfanel>
ssvb: has been running well for 1 year now, sometimes it's been 24/7 as a server for weeks :D
<Vanfanel>
ssvb: so ok, no numbers, but mine hasn't got in flames yet
<Vanfanel>
ssvb: < Vanfanel> so there's no pixman function ready to use, is there? (sorry for repeating, I am not sure you read it)
bonbons has quit [Ping timeout: 256 seconds]
naobsd has quit [Quit: naobsd]
F1skr has quit [Quit: WeeChat 1.1.1]
<cooper>
atsampson: It's still building - guess that particular option ends up hitting close to everything. Would've called it a night by now, but forgot to start this from a screen session so can't disconnect/reconnect. :-/
bonbons has joined #linux-sunxi
<atsampson>
cooper: you could always Ctrl-C it then restart the build in screen...
<atsampson>
if you don't change the config again it shouldn't need to rebuild much of what it's already built
<atsampson>
(alternatively, you could spend the time setting up a cross-build environment which would go much faster ;-)
<cooper>
atsampson: Never liked the concept of cross-compiling. Guess I'm sadomasochistic like that.
<cooper>
Restarting the build from a screen session would certainly work... Might try that.
<atsampson>
I became much more enthusiastic about cross-compiling after getting an 8-core PC ;-)
<atsampson>
it's pretty painless for the kernel and u-boot; it's more awkward for applications, though
<cooper>
Meh. This A20 built u-boot in a few minutes.
<cooper>
Doing other stuff while the machine chugs away at the code is fine in my book. I'm sure things are different when you do this repeatedly and in close succession.
FDCX_ has joined #linux-sunxi
<cooper>
Yup. Build continues where I cut it off. Excellent!
<atsampson>
I've been playing with DRAM controller settings on the pcDuino3 Nano lately (http://stuff.offog.org/tpr3.html), so I've been compiling u-boot a lot...
<Turl>
cooper: compare that to sub-6s build times when crosscompiling :)
<atsampson>
it takes about the same time to compile as it does for me to move the SD card from the board to the PC, which is handy ;-)
<cooper>
atsampson: What's the goal you're going for?
<atsampson>
cooper: well, initially I was just curious as to why they'd downclocked it from 480MHz to 408MHz in the upstream config just before release...
<atsampson>
but I've currently got a test running at 648MHz which is looking fairly encouraging
<cooper>
atsampson: Had some issues with random memory corruption a while back. Since the memtester and the cpuburn program both work flawlessly for long runs I don't think the hardware is at fault so I'm hoping this kernel might improve things a bit.
<atsampson>
the stock impedence settings aren't great, and the stock delays are about the worst possible choice...
<cooper>
Ah! It's done.
dev1990 has joined #linux-sunxi
dev1990 has quit [Client Quit]
<cooper>
How should I read those memory tables? At the moment that's just a big chunk of hex and colors to me.
<atsampson>
basically, it's trying a whole load of different delay settings, and indicating which ones work and which cause memory errors or crashes
<atsampson>
mid-green (short test OK) and dark green (long test OK) are good; anything else is bad
<cooper>
Nice. Thanks for that. Something to read through tomorrow.
<atsampson>
ssvb's examples on the wiki are nicer than mine (or at least better-organised)...
<atsampson>
I suspect in the morning I'll be looking at adjusting timing for individual lanes, looking at the 648MHz results
<cooper>
Calling it quits for tonight. Alarm will be going off again in under 6 hours so I better make the most of it. Set the Nano to rebuild all of gentoo with multiple threads, which used to be a surefire way of causing the corruption problem. First few packages installed without a hitch, so here's hoping. I'll let you know tomorrow at which point I'll probably pester you about those memory settings some. :-)
jinzo has quit [Quit: Leaving]
<cooper>
Thanks for the friendly support, folks. It's greatly appreciated!
<ssvb>
so it need to be increased to at least 400MHz
<ssvb>
and the MBUS clock speed is sensitive to DCDC3 voltage
<ssvb>
before experimenting with per-lane delays, it may make sense to try adjusting ZQ at high clock speeds to confirm that 0x1a is really the best option, or find something even better
Blakegriplingph has joined #linux-sunxi
<Blakegriplingph>
@turl - Same goes for rendering 3D scenes :P
<Blakegriplingph>
put a dozen lights on it, some complex meshes and whatnot, and you now have the perfect excuse to do whatever you want