[03:25] hello [03:25] my arm system's gpu is poorly supported by nvidia. can i play videos and firefox on another machine, and display it in a remote x11 window, or does that still use the arm gpu the same? [03:29] don't even bother [03:30] u wil be transferring pixels over the network in uncompressed full framebuffer formats [03:30] (xshmputimage pixel blobs) [03:30] if u are super-lucky it may xfer yuv [03:30] but then it'lll be using your arm's gfx unit to convert yuv- [03:30] but then it'lll be using your arm's gfx unit to convert yuv-->rgb + scale [03:31] (xv) [03:31] chances are it wont use xv as in a browser it has to composite video into the document tree so its converting and scaling to rgb space. [03:31] as such the nvidia drivers for tegra3 at least are a bit poor [03:32] they dont do vsync, they dont do buffer swaps (they do dumb copies) [03:32] for gl anyway [03:32] so performance-wise you probably lose something like 20-50% of your performance AND you get ugly tearing [03:32] on local rendering with gl [03:32] it's a tegra2 [03:32] remote display is not a world you even want too touch with a barge pole [03:33] i dont know about tegra2 - but i believe its the same drive3rs for 2 and 3 [03:33] i already do it [03:33] with better systems [03:33] u dont want to do remote display even with better systems [03:33] but nothing with crazy graphics [03:33] i dont know if i ever tried mplayer remotely [03:34] the bandwidth of a netwo9rk is somethnig like 1/1000th of that of a local display [03:34] i am assuming probably wifi connectivity [03:34] no, gigabit switch [03:34] you also have latency out the wazoo [03:34] this arm and other system would be connected with a crossover cable [03:35] remote dispay is not something you want to do.. ever.. voluntarily.. unless you have no choice [03:35] and you never do it if u care about performance [03:35] ever [03:35] my main use for remote x11 is to use handbrake for video editing. the handbrake application doesn't do many frames per second [03:36] again - don't [03:36] but it' [03:36] s your time and effort [03:36] do what you like with it [03:36] in my little experience, remote x11 works just fine for what i have used it for [03:37] anyway. my original question [03:37] i've been doing gfx for pushing on 30 years. written toolkits, apps and wm's for x11/linux for 17 years. this is my simple advice. [03:37] \don't do remote display unless u can totally avoid it. [03:38] results all depend on HOWit displays [03:38] and that varies from app to app and toolkit to toolkit [03:38] and depends on the capabilities of the xserver [03:39] fewer and fewer apps/toolkits use regular emote rendering and more and more are pixel pushing or using gl. gl remote is not an option for u due ti it being egl/gles2 [03:40] well not unless u wish to write an extension for it and do all the plumbing too [03:41] and even then xfer of data (verticieis, textures etc.) will b e raw, and slow over a network cmpared to locally - literally 1000th the speed [03:41] 1//1000th [03:42] with the systems i already do remote x11 with, it's with a 28mB/s ssh connection [03:42] u're talking an arm systeem [03:42] yes [03:42] which would be slower [03:42] i wouldn't use x11 [03:42] uh [03:42] shh [03:42] ssh [03:42] that will have to expend likely 50% of its dpu resources in JUST handlign the ssh decryption [03:42] although the tegra2 is a quad core [03:43] u will not have a lot left over at that bandwidth [03:43] no [03:43] its 2 core [03:43] could use telnet [03:43] ok, dual core [03:43] tegra2 is dual core [03:43] 2 very weak cores [03:43] u'll likely peg a cpu core on ssh [03:43] by arm standards [03:43] raster, don't be silly [03:43] *IF* u can even maintain that bw [03:43] arm isn't that terrible [03:44] lilstevie: it is in my experience. [03:44] I use ssh all the time both server and client on my tf201 [03:44] if you want it to run an ssh connection sustaining 300mbit [03:44] and it is nowhere near that bad [03:44] THEN u have to add protocol decode, memcpy's [03:45] ok. to somewhat change the topic, what use can i get from a trimslice, with a tegra2, 1GB memory, and 500GB storage (other than a nas, because i already have a better one)? [03:45] ashes, well I use mine as a builder [03:45] for kernels [03:46] yes, ok. what else? [03:47] thats all I do with it [03:47] trimslice is getting fairly old these days [03:47] my idea was to give it to my 6 year old nephew as a desktop, but he will expect to play movies and youtube with it [03:48] lilstevie: tesxgre3. 1.2ghz. sshd consumes about 40% cpu of 1 core to keep an scp at 2.8mb/sec [03:48] right here now. [03:48] doing it [03:48] raster: use arcfour [03:48] ashes is talking of wantingh to systain 28mb/s [03:48] sustain [03:48] thats 10x [03:48] u wont evben systain it [03:49] damnit [03:49] damn cat [03:49] tegra3 [03:49] 1.2ghz [03:49] good luck sustaining that rate in general on the trimslice though [03:49] even though it is a gigabit card, I do find it cannot sustain that kind of speed [03:49] yup [03:49] raster: scp -o Ciphers arcfour [03:49] thats what i said [03:50] it'll peg a core at 100% cpu [03:50] and forget ssh [03:50] i can use telnet [03:50] raster, it isn't so much the core, I don't think the pci-e bus is fast enough to support the rates of a gigabit card [03:50] ashes: even with that it runs about 25% cpui [03:50] for 3mb/sec [03:51] again [03:51] at 10 TIMES that badnwdith.. there is simply not enough compute [03:51] raster, also in your config how is the network attached [03:51] telnet would be dramatically faster [03:51] lilstevie: this is wifi - thus the low rates [03:51] i am not caring about that end of things [03:51] raster, well that is probably putting a little bit of strain on the cpu too [03:51] :p [03:51] the cpu overheadalone of sshd will peg your bandwidth [03:52] sure [03:52] or rsh [03:52] my point is for remote display you have several thigns that will kill the ui [03:52] 1. network devide3 handling itself (packet handling and at least 1 or 2 memcpy's there) [03:53] eh, remote display is problematic on x86 in the best of conditions [03:53] then more memcpy's within the xserver [03:53] vs only a single memcpy locally for local display [03:53] add to that the bandwidth bottleneck of the networi deevice [03:54] remember memcpy bandwdith will clock in at the magnitudes of 500-1500mb/se [03:54] at least on something tegra2-land [03:54] or tegra3 [03:54] your gitibit card will drop you to 100mb/s [03:54] gitbit [03:54] gigabit [03:54] thats IN THEORY.. if u can systain it [03:55] add do that sshd bottlenecking your connection maybe to 10mb/sec on the best of days [03:55] and soaking up a whole core on its own\ [03:55] add in the protocol handling by xserver, memcpy's etc. [03:55] you may very well know exactly what you're talking about, but i'll try it to see for myself [03:56] you are now looking at just pure bandwidth-wise like 1-2mb/sec of effective bw [03:56] because i want to get some use out of it [03:56] now throw in latencies more like 1-2ms [03:56] whrere local latencies (round trips) are more in the 1/100th or less of that... [03:57] unless your app is so insanely trivial where the overheads just barely make the effects visible... it'll be nasty to do remote x11 display however you look at it [03:57] the model that works is high level control protocol [03:57] with local display [03:58] the problem comes when you simply cant avoid xferring large gobs of data around as part of the display [03:59] it's then that you play tricks in downgrading the data quality (eg downscaling by 2x2 or 4x4 nd using local gpu+interpolation to upscale again) to retain interactivity [03:59] and you are only xferring some susbet of the frame data across the network [04:05] xzzzzz``````