IMHO, the point of X network transparency is a no-brainer in the same way as local OpenGL acceleration. Instead of wasting bandwidth on raw bitmaps, you just send the drawing commands, whether over the network or PCIe. (It's like MIDI vs. raw audio for the keyboardists out there.) I don't know all the programming details, but I've done 3D modelling over 2 MB/s cable this way, and I can't imagine it would have worked as smoothly using raw video.
You are talking about indirect 3D rendering, which is a fundamentally different topic. It is true that you can in theory send OpenGL command streams over a network, but in practice, this works only for certain applications, where the size of the commands is not too large, and no large assets (textures, meshes) etc. are transmitted. There's a reason why everybody wants *direct* rendering for 3D on the local machine. Forget about running games with indirect rendering, for example.
But when it comes to 2D applications, it quickly becomes obvious that the X protocol is useless nowadays, since most application draw paths, fonts etc. on their own, and X only gets to handle window-sized pixmaps. X drawing commands are almost never used anymore, except by some ancient stuff, like xterm. In that case, that fancy "X11 transparency" will end up transmitting raw bitmaps over the wire. Just use RDP, VNC etc. instead.
For gaming, why not just run the PC-versions of Dune, Monkey Island and Settlers? They aren't exactly the same but is the difference really that important?
One reason is that back then, many DOS versions of games only had AdLib or even just PC speaker support, while the Amiga version came with fully digitized audio. Compare https://www.youtube.com/watch?... to https://www.youtube.com/watch?... , https://www.youtube.com/watch?... . (The sound is actually in stereo, but the Youtube videos are downmixed for some reason.) The difference can be jarring thanks to the inferior music.
As a matter of fact, the Amiga was famous for its sound (and graphics) capabilities back then, *especially* compared to DOS. (Well, until 256-color VGA became common..)
Some DOS games had digitized audio as well, but Amiga could mix 4 channels in hardware. Mixing had to be done in software in DOS, unless you had something like a GUS or an AWE32 sound card.
But even if it consumes less RAM, browsers do a lot of I/O, because they cache all these images etc. so if your disk cache is almost nil, you will notice.
It consumes almost all of the physical memory. free -m also shows that the RAM is full, even when taking cache into account. Also, it uses about 1GB of swap.
It is definitely not a CPU limitation. CPU is almost never a bottleneck these days. The hard disk is the no.1 bottleneck by far. Also, CPU limitations don't cause massive amounts of hard disk activity and swapping. Note that I did check if swap was in use. It was. A lot.
I actually cannot open more than 4-5 tabs on my old Thinkpad with 2 GB RAM because it will be filled quickly. This is just Chromium and icewm running, on a bare minimum Archlinux installation. More than 4-5 tabs, and disk activity skyrockets, because the disk cache is pretty much zero at this point. And this affects the system twice - first, any other I/O activity will be slower because of almost zero disk cache, and second, Chromium itself suffers, because it too does a lot of I/O operations (more reads than writes).
20+ tabs on that machine is doable, sure, if you are willing to tolerate a slideshow..
This is quickly becoming untrue. The no.1 memory hog these days is the browser. People keep 20+ tabs open, many of them filled with tons of fancy graphics and complex structures. The virtual memory WILL become active. And then everything is incredibly slow.
Also, even if you measure that your browser, OS etc. consume say 3 out of 4 GB, do not forget about disk cache. It is *crucial*. Plenty of free RAM means that a lot of files can be cached in memory, which helps immensely.
And, since RAM has become rather cheap these days, I'd try to max out my mainboard RAM capacity for one simple reason: DDR generations come and go. Today you might think "oh that is lots of RAM". Tomorrow you will be glad you got that much back then, because that DDR generation is obsolete now, and remaining chips are expensive. To get an example, just try to find DDR2 RAM to upgrade an old PC...
"Soft realtime" means it operates in real-time, able to land exact guarantees within given time constraints reliably; "Hard realtime" means it's able to make 100% perfect guarantees within given time constraints, and absolutely will not miss those guarantees. "Soft realtime" requirement means your shit only operates if realtime works, but it's okay if realtime fails--it can recover, or if it flat out fails out it can be restarted with no harm. "Hard realtime" requirements mean a failure is CATASTROPHIC and has SEVERE CONSEQUENCES.
Okay, I admit I forgot about one thing: the definition of hard- and soft-realtime can be context specific. In the multimedia world, soft realtime would refer to something like realtime 3D rendering in games and visualizations, where a frame does not strictly have to finish rendering until a certain deadline is met; instead, there is a tolerance range for the interval of each rendering (and for how fast and how much this interval changes over time). Audio is hard realtime, because even one missed sample is an error (in case of capturing, arguably fatal, because it can mean the entire recording has to be thrown away). In your definition, all of them would be lumped together in the "soft realtime" category, which is not really useful.
Sure, it is nice to see that these issues have been acknowledged and are being fixed. But that proves the point, doesn't it? If the internet were easily and perfectly capable of real-time HD video delivery, these fixes wouldn't be necessary, would they?
In practice, I think it will unfortunately take years until real-time constraints are supported by consumer-grade network stacks.
Debatable. On one hand, a dropped/lost frame does not bring down the system, and is not apparent until it happens often. On the other hand, it *is* an error. I guess it is more hard-realtime-ish when it comes to capturing video, since then, the video data is actually incomplete.
Audio is definitely hard-realtime for me. Even a few lost samples are immediately noticed and usually are unacceptable. Capturing is very tough because of additional low-latency constraints.
They kind of did back then. Remember, in the past, you usually logged into something like CompuServe, which acted as an Internet portal, but also contained its own network.
But I think the simple reason net neutrality wasn't such a hot topic was because the internet just wasn't big enough yet. It is hard to compare the internet from the 80s with the one from today. In the 80s it was still very research and university/DARPA centric. Today.... not so much.
Streaming video is easier than downloading large programs, as you only need to ship a certain amount per second, rather than ship it all and only be able to use it when the last byte has arrived. For real-time broadcast, which causes massive numbers of synchronized transfers, you can use multicast directely, as well as to "prime" a content delivery network node close to your particular edge.
Uh, no, it is not easier. I say that as somebody who has been developing audio and video delivery software. The requirements differ significantly. Most network gear out there is optimized to maximize throughput, which is *not* what you want for video. For video, you want deliver on-time. This affects the kind of buffering used in hard- and software. Given the many different sources of latency over a WAN, the real-time constraints of video playback cannot be met unless you use a big jitter buffer. How big? Well, here is where the difficulties start.
Multicast does not solve that problem. All it solves is scalability (which is nice). But not the real-time constraint. BTW, if you wish to distribute video over Wi-Fi, you might be surprised to find out that many unicasts streams are better than one multicast one, thanks to Wi-Fi specific issues.
(And yes, video playback is a case for real-time programming. Real-time simply means that a given task has to be finished before a specific deadline is passed, in this case, the next frame has to be shown on screen until its timeslice passed. It does not necessarily mean that it must be something that happens many times per second.)
I do think this case against net neutrality is bollocks though.
But then, you transmit OpenGL commands as some sort of command stream to the client, which contains the GPU that renders the command stream locally. The other way is to render with the GPU on the headless machine. Then you need to encode the rendered frames and transmit them to the client on the fly. You could also use VNC, RDP etc.
All you have to do is to look for the i.MX6 specs. That gives you the infos you want. Having worked with Sabre SD devices (which also use the i.MX6 and performed very well), I am pretty excited about this.
The i.MX6 inside uses a Vivante GPU. Vivante drivers work rather well, but for some reason, that company can't version their drivers, which is annoying. However, Freescale takes care of this. When working on Sabre SD boards, I always had stable OpenGL ES and OpenVG support. Newest Vivante drivers even support desktop OpenGL (only 2.1 though).
There is also an opensource driver project called etnaviv https://github.com/laanwj/etna_viv it has come pretty far. People have been running GLQuake and others with it already.
I have been playing around with the Freescale VPU. It is very powerful, can do 1080p easily, Linux support is solid. It can also encode in hardware. Supported formats I know of are: h264, mpeg-1/2/4, vp8, vc-1,wmv3,mjpeg. I think h263 too, not sure though. It also has deinterlacing and hardware scaling and color space conversion capabilities (think YUV->RGB).
No VDPAU support. But VDPAU is nVidia only. You probably meant VA-API. I do not know if this is supported. There are GStreamer plugins for it, XBMC and libav/ffmpeg support is being worked on IIRC.
Um, a RPi is much less powerful than even the $45 model. The ChromeCast uses a Marvell SoC. Marvell is notoriously uncooperative when it comes to documentation and details about their hardware, unless you are Google. (So is Broadcom btw.) Freescale is much more open and forthcoming.
This one combines eSata with gbit ethernet (limited to 470 Mbit though, yes) and a pretty powerful video engine. Seems very nice as a DVR/HTPC combo, and/or a box for transcoding media.
Same problem as this model. The Gigabit is limited to 480Mbps (USB 2.0 bus speed). Actually this Cubic isn't all that different from an RPi, they run the same family chips, the same type of RAM, the same type of I/O.
Not true. Ethernet does not go through USB here; it is connected to the SoC directly. See http://boundarydevices.com/i-mx6-ethernet/ . The Raspberry Pi uses a BCM 2835 from Broadcom, while the Cubox-i uses a Freescale i.MX6 , so they are not the same chip family, they aren't even made by the same company. Raspberry Pi also does not have eSata, while the CuBox-i.
Reminds me of software bugs which are "fixed" by disabling subsystems around them. Example: in a media player, AAC playback sometimes freezes and causes glitches. Solution: disable AAC playback, ensuring that the media player does not reach this undefined and broken state.
Yes. Most people seem to mainly pay attention to the "Under God" part (and that part is very creepy). Plus, any kind of compulsory oath is at odds with liberty.
Slashdot Mirror
IMHO, the point of X network transparency is a no-brainer in the same way as local OpenGL acceleration. Instead of wasting bandwidth on raw bitmaps, you just send the drawing commands, whether over the network or PCIe. (It's like MIDI vs. raw audio for the keyboardists out there.) I don't know all the programming details, but I've done 3D modelling over 2 MB/s cable this way, and I can't imagine it would have worked as smoothly using raw video.
You are talking about indirect 3D rendering, which is a fundamentally different topic. It is true that you can in theory send OpenGL command streams over a network, but in practice, this works only for certain applications, where the size of the commands is not too large, and no large assets (textures, meshes) etc. are transmitted. There's a reason why everybody wants *direct* rendering for 3D on the local machine. Forget about running games with indirect rendering, for example.
But when it comes to 2D applications, it quickly becomes obvious that the X protocol is useless nowadays, since most application draw paths, fonts etc. on their own, and X only gets to handle window-sized pixmaps. X drawing commands are almost never used anymore, except by some ancient stuff, like xterm. In that case, that fancy "X11 transparency" will end up transmitting raw bitmaps over the wire. Just use RDP, VNC etc. instead.
For gaming, why not just run the PC-versions of Dune, Monkey Island and Settlers? They aren't exactly the same but is the difference really that important?
One reason is that back then, many DOS versions of games only had AdLib or even just PC speaker support, while the Amiga version came with fully digitized audio.
Compare https://www.youtube.com/watch?... to https://www.youtube.com/watch?... , https://www.youtube.com/watch?... . (The sound is actually in stereo, but the Youtube videos are downmixed for some reason.) The difference can be jarring thanks to the inferior music.
As a matter of fact, the Amiga was famous for its sound (and graphics) capabilities back then, *especially* compared to DOS. (Well, until 256-color VGA became common..)
Some DOS games had digitized audio as well, but Amiga could mix 4 channels in hardware. Mixing had to be done in software in DOS, unless you had something like a GUS or an AWE32 sound card.
But you forgot to use an XML schema for validation, and XSL transformations to be able to automatically write a game out of the XML files!
But even if it consumes less RAM, browsers do a lot of I/O, because they cache all these images etc. so if your disk cache is almost nil, you will notice.
It consumes almost all of the physical memory. free -m also shows that the RAM is full, even when taking cache into account. Also, it uses about 1GB of swap.
It is definitely not a CPU limitation. CPU is almost never a bottleneck these days. The hard disk is the no.1 bottleneck by far.
Also, CPU limitations don't cause massive amounts of hard disk activity and swapping. Note that I did check if swap was in use. It was. A lot.
I actually cannot open more than 4-5 tabs on my old Thinkpad with 2 GB RAM because it will be filled quickly. This is just Chromium and icewm running, on a bare minimum Archlinux installation. More than 4-5 tabs, and disk activity skyrockets, because the disk cache is pretty much zero at this point. And this affects the system twice - first, any other I/O activity will be slower because of almost zero disk cache, and second, Chromium itself suffers, because it too does a lot of I/O operations (more reads than writes).
20+ tabs on that machine is doable, sure, if you are willing to tolerate a slideshow..
This is quickly becoming untrue. The no.1 memory hog these days is the browser. People keep 20+ tabs open, many of them filled with tons of fancy graphics and complex structures. The virtual memory WILL become active. And then everything is incredibly slow.
Also, even if you measure that your browser, OS etc. consume say 3 out of 4 GB, do not forget about disk cache. It is *crucial*. Plenty of free RAM means that a lot of files can be cached in memory, which helps immensely.
And, since RAM has become rather cheap these days, I'd try to max out my mainboard RAM capacity for one simple reason: DDR generations come and go. Today you might think "oh that is lots of RAM". Tomorrow you will be glad you got that much back then, because that DDR generation is obsolete now, and remaining chips are expensive. To get an example, just try to find DDR2 RAM to upgrade an old PC...
"Soft realtime" means it operates in real-time, able to land exact guarantees within given time constraints reliably; "Hard realtime" means it's able to make 100% perfect guarantees within given time constraints, and absolutely will not miss those guarantees. "Soft realtime" requirement means your shit only operates if realtime works, but it's okay if realtime fails--it can recover, or if it flat out fails out it can be restarted with no harm. "Hard realtime" requirements mean a failure is CATASTROPHIC and has SEVERE CONSEQUENCES.
Okay, I admit I forgot about one thing: the definition of hard- and soft-realtime can be context specific. In the multimedia world, soft realtime would refer to something like realtime 3D rendering in games and visualizations, where a frame does not strictly have to finish rendering until a certain deadline is met; instead, there is a tolerance range for the interval of each rendering (and for how fast and how much this interval changes over time). Audio is hard realtime, because even one missed sample is an error (in case of capturing, arguably fatal, because it can mean the entire recording has to be thrown away). In your definition, all of them would be lumped together in the "soft realtime" category, which is not really useful.
Sure, it is nice to see that these issues have been acknowledged and are being fixed. But that proves the point, doesn't it? If the internet were easily and perfectly capable of real-time HD video delivery, these fixes wouldn't be necessary, would they?
In practice, I think it will unfortunately take years until real-time constraints are supported by consumer-grade network stacks.
Debatable. On one hand, a dropped/lost frame does not bring down the system, and is not apparent until it happens often. On the other hand, it *is* an error. I guess it is more hard-realtime-ish when it comes to capturing video, since then, the video data is actually incomplete.
Audio is definitely hard-realtime for me. Even a few lost samples are immediately noticed and usually are unacceptable. Capturing is very tough because of additional low-latency constraints.
They kind of did back then. Remember, in the past, you usually logged into something like CompuServe, which acted as an Internet portal, but also contained its own network.
But I think the simple reason net neutrality wasn't such a hot topic was because the internet just wasn't big enough yet. It is hard to compare the internet from the 80s with the one from today. In the 80s it was still very research and university/DARPA centric. Today.... not so much.
Streaming video is easier than downloading large programs, as you only need to ship a certain amount per second, rather than ship it all and only be able to use it when the last byte has arrived. For real-time broadcast, which causes massive numbers of synchronized transfers, you can use multicast directely, as well as to "prime" a content delivery network node close to your particular edge.
Uh, no, it is not easier. I say that as somebody who has been developing audio and video delivery software. The requirements differ significantly. Most network gear out there is optimized to maximize throughput, which is *not* what you want for video. For video, you want deliver on-time. This affects the kind of buffering used in hard- and software. Given the many different sources of latency over a WAN, the real-time constraints of video playback cannot be met unless you use a big jitter buffer. How big? Well, here is where the difficulties start.
Multicast does not solve that problem. All it solves is scalability (which is nice). But not the real-time constraint. BTW, if you wish to distribute video over Wi-Fi, you might be surprised to find out that many unicasts streams are better than one multicast one, thanks to Wi-Fi specific issues.
(And yes, video playback is a case for real-time programming. Real-time simply means that a given task has to be finished before a specific deadline is passed, in this case, the next frame has to be shown on screen until its timeslice passed. It does not necessarily mean that it must be something that happens many times per second.)
I do think this case against net neutrality is bollocks though.
But then, you transmit OpenGL commands as some sort of command stream to the client, which contains the GPU that renders the command stream locally.
The other way is to render with the GPU on the headless machine. Then you need to encode the rendered frames and transmit them to the client on the fly. You could also use VNC, RDP etc.
But there is already the VPU in the SoC. It can encode and decode. So why do you want to encode with the GPU?
All you have to do is to look for the i.MX6 specs. That gives you the infos you want. Having worked with Sabre SD devices (which also use the i.MX6 and performed very well), I am pretty excited about this.
The i.MX6 inside uses a Vivante GPU. Vivante drivers work rather well, but for some reason, that company can't version their drivers, which is annoying. However, Freescale takes care of this. When working on Sabre SD boards, I always had stable OpenGL ES and OpenVG support. Newest Vivante drivers even support desktop OpenGL (only 2.1 though).
There is also an opensource driver project called etnaviv https://github.com/laanwj/etna_viv it has come pretty far. People have been running GLQuake and others with it already.
I have been playing around with the Freescale VPU. It is very powerful, can do 1080p easily, Linux support is solid. It can also encode in hardware. Supported formats I know of are: h264, mpeg-1/2/4, vp8, vc-1,wmv3,mjpeg. I think h263 too, not sure though. It also has deinterlacing and hardware scaling and color space conversion capabilities (think YUV->RGB).
No VDPAU support. But VDPAU is nVidia only. You probably meant VA-API. I do not know if this is supported. There are GStreamer plugins for it, XBMC and libav/ffmpeg support is being worked on IIRC.
GPU acceleration in a headless setup? More details please? What is the use case? They do mention OpenCL being supported in the more expensive models.
Um, a RPi is much less powerful than even the $45 model.
The ChromeCast uses a Marvell SoC. Marvell is notoriously uncooperative when it comes to documentation and details about their hardware, unless you are Google. (So is Broadcom btw.)
Freescale is much more open and forthcoming.
This one combines eSata with gbit ethernet (limited to 470 Mbit though, yes) and a pretty powerful video engine. Seems very nice as a DVR/HTPC combo, and/or a box for transcoding media.
Same problem as this model. The Gigabit is limited to 480Mbps (USB 2.0 bus speed). Actually this Cubic isn't all that different from an RPi, they run the same family chips, the same type of RAM, the same type of I/O.
Not true. Ethernet does not go through USB here; it is connected to the SoC directly. See http://boundarydevices.com/i-mx6-ethernet/ . The Raspberry Pi uses a BCM 2835 from Broadcom, while the Cubox-i uses a Freescale i.MX6 , so they are not the same chip family, they aren't even made by the same company. Raspberry Pi also does not have eSata, while the CuBox-i.
A mesh network would have terrible latency, at least in its current generation.
Reminds me of software bugs which are "fixed" by disabling subsystems around them. Example: in a media player, AAC playback sometimes freezes and causes glitches. Solution: disable AAC playback, ensuring that the media player does not reach this undefined and broken state.
Yes. Most people seem to mainly pay attention to the "Under God" part (and that part is very creepy). Plus, any kind of compulsory oath is at odds with liberty.
So you would stop the US government from stripping away rights by taking away control over the Internet from them, and giving it to Russia etc.?
That would help freedom of speech how exactly?