Graphics coprocessor - what would you use today? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: July 31, 2020, 05:01:09 pm
content: I go back to the old ones like the Thomson CSF (later ST) 9365, NEC UPD7220... driven from Z80 type CPUs. After that people just used PC (motherboard) chipsets which had loads of performance and you could do it all in software. Nowadays you could use a graphics chip but as with the MB chipsets you have the huge problem of parts going obsolete every few years.Is there some "industrial" co-processor in common use, for driving a hi-res colour LCD, from something like an ARM ST? It needs to draw polygons, polygon fills, fonts, etc...One could of course dedicate a 32F 4xx to graphics, and have some shared RAM for passing the data, or even send it via SPI at 40mbps, which is probably what some do.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 31, 2020, 05:11:44 pm
content: Each ARM microcontroller manufacturer has some sort of their own hardware helper peripheral, for STM32 this is called "DMA2D" aka. "Chrom-ART Accelerator". Of course, this isn't very advanced but aimed to offload CPU time when dealing with simple GUIs; drawing 2D sprites like fonts and icons, color fills etc.The plus side is, it comes for free in the MCU, want it or not, so give it a chance.

author: peter-h
author_rank: Super Contributor
timestamp: August 03, 2020, 07:37:46 pm
content: It sounds like these chips don't exist anymore... and interfacing the PC video card ones is not trivial.

author: NiHaoMike
author_rank: Super Contributor
timestamp: August 03, 2020, 11:21:39 pm
content: Nowadays, the most common choice for cheap graphics is an ARM chip that has built in graphics, for example Allwinner.

author: Mr. Scram
author_rank: Super Contributor
timestamp: August 03, 2020, 11:29:10 pm
content: Quote from: NiHaoMike on August 03, 2020, 11:21:39 pmHow is their long term support?

author: oPossum
author_rank: Super Contributor
timestamp: August 03, 2020, 11:47:13 pm
content: Not a common solution, and I wouldn't recommend it, but if you really want a 'GPU' for a low end MCU....https://www.ftdichip.com/Products/ICs/BT81X.html

author: NiHaoMike
author_rank: Super Contributor
timestamp: August 04, 2020, 01:16:25 am
content: Quote from: Mr. Scram on August 03, 2020, 11:29:10 pmIf that's a concern, use a Raspberry Pi, or even better a low end FPGA.

author: Mr. Scram
author_rank: Super Contributor
timestamp: August 04, 2020, 01:42:50 am
content: Quote from: NiHaoMike on August 04, 2020, 01:16:25 amOP literally mentions chips going obsolete every few years being an issue so that's obviously a concern. A Raspberry Pi goes equally obsolete, isn't really a component you'd want to use in a product and is woefully expensive. Doing a soft GPU is expensive compared to an ASIC, not power efficient and a fair bit of trouble you don't want.

author: peter-h
author_rank: Super Contributor
timestamp: August 04, 2020, 04:58:11 pm
content: Not that I want to do exactly this product (everybody and their dog is doing them) but it shows the sort of graphics I was thinking of, with say a 1024x768 LCDWith a PC-grade CPU you would obviously do it in software, but anything "PC grade" is a production nightmare, requiring a redesign every few years at most. Whereas embedded MCUs like an ST 32F4xx tend to have a life of 20+ years and after that you get the last time buy options. I got a 25 year life with the Hitachi H8/3xx and 5xx chips, for example.The display needs to be absolutely smooth, and I suspect that won't be easy with a 150MHz MCU doing other stuff also.

author: Berni
author_rank: Super Contributor
timestamp: August 04, 2020, 05:45:07 pm
content: A RaspberryPi is actually the cheapest choice out there for a low volume, no NDA nonsense solution to running Linux with a good deal of horsepower. If you want more professional grade things then stuff like NXP i.MX6 SOCs are one of the ways to go, less horsepower, but has been available for almost 10 years now and will be available for plenty more.In any case drawing what you have shown at 60fps in 1024x768 will require a decent Linux SOC with OpenGL running on hardware accelerated graphics. The actual app at that point is just a linux executable so it will run on any other chip that has the same CPU architecture and has working OpenGL driver for whatever GPU it has. Same linux app could also be compiled for x86 and ran on a 16 core Intel i9 CPU with a RTX 2080Ti graphics card to make it run at a gazilion fps. Its just linux.EDIT: Well actually under linux the AMD graphics cards are a better choice due to better drivers.

author: peter-h
author_rank: Super Contributor
timestamp: August 04, 2020, 06:18:01 pm
content: Hmmm... what happens when some combination of objects triggers a bug in the driver?I have just had to update some nvidia drivers because a specific amazon movie site bluescreened the PC (every PC with nvidia, actually, if running the default M$ nvidia drivers).Do OpenGL graphics chips just take in the commands, byte-serially, or are they memory mapped? The LCD is normally a parallel interface, and from last time I worked with them (years ago) they have two display memory banks. You write the new data to one bank and the flip the banks and the whole lot changes instantly.

author: bd139
author_rank: Super Contributor
timestamp: August 04, 2020, 06:44:03 pm
content: I wouldn’t go near a Pi. It’s amateur kit built only to a price point.COTS Linux SoC + QT user interface is a decent win there. If it has a long lifespan then physically separate the functional processor from the UI processor. If you do it in QT you can port it to a better/cheaper/faster SoC later or handle obsolescence with an FRU replacement. Option two is buy all the stock you need up front.We did that 20 years ago with Xilinx / PPC and used a rack mount PC. The PC I understand was recently replaced with ARM touch screens without changing the functional processor.

author: Berni
author_rank: Super Contributor
timestamp: August 04, 2020, 07:14:04 pm
content: You don't get to directly talk to modern GPUs. Every GPU vendor has a different proprietary way of feeding data to there GPU chip. Doesn't matter if its the latest and greatest gaming graphics card from Nvidia or a GPU inside a mobile phone SOC with Qualcomms Adreno mobile GPU. It is the job of the vendors graphics driver to make it to what it needs to do.But having to program a separate 3D renderer for your 3D game for each graphics card vendor individually would be very annoying (But this is how it was done in the early days of hardware accelerated 3D graphics on PC, like the 3dfx Voodoo Glide API), so they have come up with a standardized graphics API that is used by all vendors. This is OpenGL or DirectX or Vulkan...etc So as long as your application uses say OpenGL 3.0 that meany any graphics card with a driver that supports OpenGL 3.0 will be able to interpret the commands and render them. Only difference being that some more powerful cards might finish rendering it faster. As a result, pretty much all 3D games support pretty much all graphics cards (within reason). Then as GPUs have gotten more powerful and flexible they also got a programmable render pipeline, so new languages called shader scripts got developed to program them. Its again the job of the API to take a shader script written in for example GLSL (OpenGL Shader Language) and compile it into a form to be executed inside the GPUs shader units. Since GPUs have gotten way more powerful than CPUs for repetitive math work lead to these shaders also being used to crunch non graphics data, this is what compute shaders are on things such as Nvidia Cuda or OpenCL. The graphics card is no longer a dumb "draw bitmap A at location X,Y" or "transform bitmap B using the affine matrix at C", instead these days if you want to draw say perlin noise to the screen then you teach the GPU the algorithm for drawing it and just let it compute it and draw it to the framebuffer in the background(And ends up finishing it WAY faster than even the worlds fastest CPU could). If you want to have double or tripple buffering then you just ask the driver to configure the GPU for that.So thanks to all this you can take an existing application and simply slap a newer faster GPU on it and it just magically works. And this is the reason why all modern GPUs in the last 15 years are interfaced in such a way.Also as a result these modern GPUs are only usable under a OS such as Windows, Linux, Android...etc. If you have a microcontroller running bare metal C code then all you get is a glorified graphics specific DMA for throwing pixels around (Much like those old graphics chips). If you do want powerful high performance 2D graphics on such a tiny MCU then your only option is to connect a large FPGA to a memory bus on that MCU and build your own memory mapped 2D GPU inside the FPGA.

author: NiHaoMike
author_rank: Super Contributor
timestamp: August 04, 2020, 11:46:07 pm
content: Quote from: Mr. Scram on August 04, 2020, 01:42:50 amThe Pi Zero is quite cheap and has been supported for years.You're suggesting an ASIC, tell me what small graphics ASICs are available other than ARM chips with graphics capability.

author: Mr. Scram
author_rank: Super Contributor
timestamp: August 05, 2020, 12:42:22 am
content: Quote from: NiHaoMike on August 04, 2020, 11:46:07 pmRead bd139's comment. A Raspberry Pi is amateur kit with Zero guarantees in regards to support and supply. Not something a sensible engineer builds a product on. OP is looking exactly for suggestions for the latter.

author: Berni
author_rank: Super Contributor
timestamp: August 05, 2020, 05:31:42 am
content: Quote from: Mr. Scram on August 05, 2020, 12:42:22 amIt happens more than you would think, especially with the RPi compute module.Go ahead and try to design a device with a high resolution touch screen, some wireless and wired connectivity and enough computing power to render 3D graphics. Now try to design this with a BOM cost of 80 USD for the whole thing for production runs of 50 units and get it out the door in a timeframe of months. What CPU would you use?The only cheap Linux system on module boards with a similar level of horsepower are the chinese boards running various RockChip or Allwinner SOCs. These boards pop up and die all the time, have documentation locked under NDAs bound with manufacturing contracts (If there is English documentation at all), no support from the manufacturer and no community support.On the other hand the Raspberry Pi has been around for many years and still will be. While not actually open source it does provide some documentation and the large community around it makes development easier since most of the time someone else already did the thing you wanted to do before you. Yes using a i.MX6, i.MX8, Nvidia Tegra...etc is way more professional but you don't always have the budget or the volumes to make that happen.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 05, 2020, 06:47:52 am
content: For what, to what?For embedded, like, I have a few surplus FT800Qs -- MCU interface (er, I forget what all, SPI primarily?), parallel digital video output, up to 512 x 512 x 18bpp. (Even have a PCB they were surplus from, but I don't think I have any LCDs with parallel video to drive them with, alas!) Hmm, still available too.There's all manner of chips for LCD application. Tons of modules have them onboard (rather than faffing around with the digital video yourself). SSD1963, ILI9325, ST7735, etc. "Onboard" as in, everything from chip-on-glass (either the controller has the TFT controller+driver as well, or it's paired with one right there), chip-on-flex, or a PCB piggybacking on the module. (I have some surplus Newhaven panels with SSD1963s mounted in this way; the panel flex appears to be parallel video.)Most of these controllers are just a basic frame buffer, with various means of access to it (addressable pixels, windowing). Some have palette options, character modes, etc. There are probably bit-plane types as well (more old fashioned, compare with EGA-VGA!), though I haven't seen many myself. Of course there's direct character-only types too, HD44780 most famously.Compare with old fashioned PC graphics, where you have many more CRT control registers -- often stuff that wasn't at all interesting, or was outright dangerous to mess with (fatal poke). That's probably a consequence of their historic origins (going back to CRTC chips which were designed for arbitrary use, not just NTSC-like rasters!). As you go up from CGA to EGA and VGA, you get more color options, and a few addressing/windowing options (which, I suppose page flipping is about all you got among those sorts of features, really..).Which basically puts VGA on par with most of those basic LCD controllers. So, this is a useful point of reference between current embedded and historic PC technologies.So you have to go up from there to see anything of real interest: sprite blitting, accelerated drawing (lines, boxes, gradients, polygons..), triangles, texture maps (or other warps besides trivial orthogonal rotations and flips), alpha blending, etc.Not that sprite systems weren't around much longer than VGA, just that they didn't make it to PCs in any mainsteam way. Obviously, everything character-based, and pretty much every console on the planet up til then (including a lot of PCs that were basically consoles with keyboards in them), used sprites or tiles in some capacity.I mean, great, if you want to chop the VIC out of a C64 and slap it on an ISA card with the necessary bus interface logic, sure, you can have dual monitors, one with sprite graphics, on your IBM PC in 1982 or whatever. Possible, definitely, but it wasn't a mainstream product.And also, not that mainline sources didn't make their own. XGA for example. But these were specialty and if you weren't doing, like, CAD or whatever, you weren't going to shell out for it. Again, not mainstream. (Maybe not too bad an example, still; like, how many did they sell?)So as you go forward in history, mostly through the 90s you got more advanced, integrated video devices. In on-board and expansion-card formats.But there's so many more of those products, and far less documentation about them. Every brand had their own drivers to use with Windows and such. If you wanted to use their proprietary features, not just basic VESA and SVGA support, you either needed the OS overhead and the APIs, or you had to do it in DOS on bare metal, and either way you were probably locking yourself in quite a lot.So I'm not sure how useful it would be to discuss classic SVGA hardware, except as an example of what was available, if not as a specific use-case that is relevant today.Relevance is really what I'm getting at, here; if you choose an LCD or HDMI or whatever controller, that has easy access (e.g. parallel, USB2.0+ or PCIe bus?), and documented registers, or at least drivers provided in usable form for most platforms, somehow or another -- that's an excellent starting point.The current examples given above, include SoCs that are terribly locked up and undocumented publicly (for the most part, AFAIK -- I am slightly curious if some of them are getting RE'd, ones on the most common platforms like rPis?), and mainly supported by blob drivers in Linux or the like -- fortunately you have plenty of CPU power and acceleration left to run, say, Quake 3!Tim

author: bd139
author_rank: Super Contributor
timestamp: August 05, 2020, 08:18:36 am
content: This is why I said QT. That is at least portable and you don't have to give a crap about what stack is underneath it. It's an abstraction through a driver and kernel. You just have to care about the consistent kernel interface (linux) and user interface (QT) and skip worrying about the HAL. That's the vendor's problem!You can also quite happily throw together the thing on a desktop PC and run it there as well if you need to where the tools are fast and powerful then cross compile it later.Quote from: Berni on August 05, 2020, 05:31:42 amIt's all the trifecta of budget, time, quality. You can reduce time to market and budget with a Pi Zero but quality suffers. Terribly. The things are bug ridden nightmares and that's from direct experience of running Pi Zero and some of the earlier RPi products for years.If you want your customers coming back you don't send them a turd.As for BOM cost, if it's 80 and the unit count is 50, that sounds economically pointless. I'd find another solution to the problem, probably along the lines of avoiding solving it or charging a lot of the BOM cost out as time (so I can make efficient decisions)

author: Berni
author_rank: Super Contributor
timestamp: August 05, 2020, 11:22:57 am
content: Quote from: bd139 on August 05, 2020, 08:18:36 amNever said it is a great solution, but it is the cheapest still usable solution with a lot of processing horsepower when used in <100 unit production runs. There are lots of niche fields where products are made in such small runs every so often. The economics of some of the projects like this confuses me too, but its not my job to worry about that.I haven't seen any major faults with RPi compute modules, but its not like going to the other vendors of SOMs like Variscite, Toradex, Congatec, Wandboard...etc will get you a magical 100% bug free ready to go linux image for it. You do get official support from them to help out, but don't expect them to fix every little bug for you. In return you get to buy the modules from them for around 100 to 200 USD a piece with the more high performance chips. Tho still worth it if the budget allows for it.But if the OP never worked with graphics on a ARM SOC, then if nothing else a RPi is a good easy cheap way to play around with it and find out if this sort of thing is right for him, or if he wants to go back to oldschool bitbliting bitmaps around.

author: peter-h
author_rank: Super Contributor
timestamp: August 05, 2020, 12:43:41 pm
content: This is great input; many thanks all.Looking at OpenGL, if this needs the chip vendor's driver, that driver is going to be a binary executable which needs a specific CPU.Obviously there are 80x86 versions; I see OpenGL/Cuda/whatever options in my Vegas video editors. Hilariously they don't actually work much faster than disabling GPU acceleration and just running the 12 core i7 CPU, but they have loads of bugs (a sore point which few want to talk about)but then the target I have in mind would be just a 150MHz ARM which is perhaps 1/100 of the performance.But are there OpenGL drivers for an ARM, not running some specific OS?

author: bd139
author_rank: Super Contributor
timestamp: August 05, 2020, 12:57:17 pm
content: There might be but it's probably not a fight you want to get into if you value your time.

author: Mr. Scram
author_rank: Super Contributor
timestamp: August 05, 2020, 01:42:21 pm
content: Quote from: Berni on August 05, 2020, 11:22:57 amRegular Pi's don't seem viable but the Compute Unit may be somewhat. Supposedly designed for "industrial" purposes, whatever that means. I don't think they're qualified in any way. Only 1GB RAM. The important part is that the third + version is reported to be supported until January 2026 and there may be compatible successors, though I can't find any guarantees. Price isn't great so it may be a non starter. Maybe bd139 can tell us all the reasons it's a shit idea.

author: bd139
author_rank: Super Contributor
timestamp: August 05, 2020, 01:50:55 pm
content: Basically anything Broadcom touches, run away from. Rapidly. Preferably shooting over your shoulder.

author: rsjsouza
author_rank: Super Contributor
timestamp: August 05, 2020, 02:58:27 pm
content: Quote from: peter-h on August 05, 2020, 12:43:41 pmDid you look at the AM57x family of devices? They seem to have both Video codecs (H.264, MPEG4, etc.) and OpenGL implementations - open source, as hinted by the thread below:https://e2e.ti.com/support/processors/f/791/p/854534/3161129#3161129I don't think you will be able to find an OS-agnostic driver, though.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 05, 2020, 04:11:19 pm
content: Has anyone ever statically linked... basically the entire Linux kernel, into an application?But even then, you'd want to patch out e.g. file access for static arrays, most likely. I mean, you can leave in blobs and link them in all the same, and use whatever memory mapped file system you like. But if you aren't short-circuiting those accesses to direct memory mappings, you aren't actually accomplishing anything. Presumably, the point was to optimize it in some way, reducing code size or execution time, right?!But heck, that's so much work, and... you could just replace the shell with your application and boot right into it, no fiddling around.(Yocto comes to mind -- but AFAIK that's not a compile-level build. And also from what I've heard, it'spainfullybad to work with. So, just as much work, just in some other toolchain...)Anyway yeah, I can see the appeal of just one or a few APIs in an otherwise self-contained program, and running that on something more appropriate, like an STM32F4 instead of one of these SoCs. But the problem is they are APIs built on top of APIs that call APIs. So you need to patch in all their dependencies, and pretty soon you need the whole damn Linux kernel. So it basically ends up as above, even though I kind of jumped into that as speculation rather than seriousness.Tim

author: bd139
author_rank: Super Contributor
timestamp: August 05, 2020, 04:52:47 pm
content: Nearly. I had a kernel that ran a static binary called /bin/init which had my program in it. It worked!

author: Berni
author_rank: Super Contributor
timestamp: August 05, 2020, 05:52:02 pm
content: Quote from: peter-h on August 05, 2020, 12:43:41 pmPretty much all ARM chips with a GPU will come with a linux OpenGL driver in some way (Since that's usually how the GPU vendor intends you to use it). Having the driver run on another CPU is not really a concern since these GPUs are on the same silicon die as the CPU, so its not possible to connect that GPU to anything else than the CPU it is sharing the chip die with.And yes offloading complex video processing tasks to the GPU via Cuda can be complicated and might depend a lot on the specific hardware configuration of your PC, the drivers, the OS etc.. But this is fairly new tech so it might have kinks that need to be worked out.When running old versions of OpenGL for rendering 2D or 3D graphics you get really wide compatibility. It will run on pretty much any PC GPU made in the last 15 years be it Nvidia, ATI, Intel, VIA...etc. It just runs faster on the newer more powerful cards. If an embedded version of it such as OpenGL-ES is used then the compatibility also includes mobile GPUs such as the ones used in mobile phones and tablets. Heck there are even software implementations of OpenGL that don't need a GPU at all and run fully inside the CPU (But its usually going to be too slow to be useful)Quote from: bd139 on August 05, 2020, 01:50:55 pmYep i hate them too. Not that Qualcomm is any better and they ware out to acquire NXP.

author: peter-h
author_rank: Super Contributor
timestamp: August 05, 2020, 09:28:26 pm
content: To a large extent how to approach this would depend on how cleverly one can run the Bresenham and Horn algorithms (for drawing lines and arcs, respectively). I did this way back on a Z80, obviously in asm, and it wasn't bad at 4MHz. Next come polygon fills; those are unfortunately much slower.But a whole lot also depends on how the data is represented. Often one can cache a lot of graphics shapes - the old "sprite" concept.

author: westfw
author_rank: Super Contributor
timestamp: August 08, 2020, 12:45:08 am
content: QuoteHah hah.I think there has only been ONE standard forjustthe connection of a display to a controller that has lasted 20 years (VGA.) (and it's going away now, since it's fundamentally based on CRT technology, which is also "obsolete.")

author: peter-h
author_rank: Super Contributor
timestamp: August 08, 2020, 08:05:36 am
content: VGA is nothing to do with CRTs.

author: bd139
author_rank: Super Contributor
timestamp: August 08, 2020, 08:41:13 am
content: Huh it most certainly is entirely designed for and tied to CRTs at an electrical and protocol level. The fact it works with anything else is a testament to the LCD controller manufacturers.

author: Berni
author_rank: Super Contributor
timestamp: August 08, 2020, 11:32:35 am
content: The VGA port was designed for use with CRT monitors, because the only type of high resolution color display on the market in 1987 was a CRT.As a result the circuitry required to put a VGA signal onto a CRT monitor was as simple as could be. Both the Vsync and Hsync signals come in on dedicated wires, so the is no sync extraction needed. Those get fed into two entirely separate PLLs as a reference and that makes the two ramp signals that scan the beam in X-Y. The Hsync signal continues to pulse even when inside vertical blanking (There is no purpose for this as these are no video lines to sync) since this makes it easier for the horizontal scan PLL to keep lock and makes AC coupling easier inside the horizontal deflection amplifiers (Since they just keep scanning). Then the R G B signals are also sent over 3 wires just as the CRT circuitry needs them, so all it has to do is amplify each color channel signal and send it directly into the electron gun. The RGB color signals also go black when in blanking, so no blanking circuitry is needed in the monitor.None of this is required for a LCD panel, but when the market is 100% CRT you are going to design something that firs well for those. However eventually LCD technology did get far to become a CRT alternative. By this point most full color high resolution displays used VGA or a weird proprietary standard that works almost identical to VGA (Such as the DB13W3 used by SiliconGraphics, IBM, NeXT...etc) so in order to compete with CRTs they had to support VGA.Fortunately for LCDs they can in principle be drawn to in any order you like given the right controller circuitry. So in order to make LCDs easy to connect to a VGA source they imitated the CRT as much as possible. The Hsync and Vsync lines are just as convenient for LCD, as is the separate R G B intensity in analog. The Hsync is locked on by a PLL to multiply its frequency by a the number of horizontal pixels (+blanking), this gives a pixel clock that samples the R G B color values and steps the pixel counter from left to right (Since CRTs also go from left to right). Hsync edge simply steps down by 1 row. The TFT cells on a LCD display need analog so you can simply run the analog R G B values trough a CCD bucket brigade to deserialise the pixels into a full line that is then put onto the column drivers. The row drivers are just shift registers clocked by Hsync edges. Counters are used to cut away the useless blanking areas that the LCD does not need. And done! So since LCDs are more flexible regarding driving methods it was easy to make LCD controller circuit that draws it the same way a CRT does and so make it simple to connect to VGA.But its still a bit of a hack, so LCD controllers started providing a direct pixel clock input. In something like a laptop the graphics cards video DAC clock could be tapped off and provided to the LCD controller as a pixel clock (With no need for pixel clock recovery via a PLL). But since the graphics card is generating digital data, why not just put the video DAC inside the LCD controller where its timings can be tightly tied to the required LCD matrix scan timings. So this is how the DPI (Digital Parallel Interface) RGB bus was created. It still has the useless CRT blanking times to be VGA compatible, but is now fully digital.This is now the modern digital video bus. When you use DVI or HDMI this is that exact DPI RGB bus, just sent trough a serializer and some encoding so that it only needs 4 diff pairs instead of 28 wires (8 red, 8 green, 8 blue, 1 Hsync, 1 Vsync,1 DataEnable, 1 PixelClock) and works reliably over long cables. The LVDS bus used in modern laptops to drive LCDs is the same DPI bus except its only serialized but not encoded (No long wires needed here). So even with HDMI you still are using blanking periods from the 80s that had the only purpose of giving time for the slow magnetic deflection CRTs to get the beam back into the top left corner. But HDMI found a use for this blanking time and placed digital audio data in there.So in a sense you could say HDMI is still designed for CRTs due to the comparability chain it was born out of.

author: rsjsouza
author_rank: Super Contributor
timestamp: August 08, 2020, 12:02:35 pm
content: Excellent post!

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 08, 2020, 01:11:43 pm
content: Heh, that they work in similar ways, I think you could prove the necessity of that:Consider what both are doing: filling a screen of millions of pixels, from a few signal lines.Right off the bat, it's obvious we can't connect single pixels. Millions of signals, that's preposterous at any level. Even connecting individual rows or columns, isn't really useful. You'd need a 223-signal connector just to drive the rows for an NTSC monitor, and you still need some way to drive the columns, some kind of multiplexing.So to even begin to be practical, we need to multi-multiplex our pixels.Geometrically speaking, we want to project a volume -- video spans two spacial dimensions and one time dimension. We can construct that volume however we like, but simple geometric shapes will be the easiest, and anything that requires additional circuitry or mechanics to deal with synchronization, or variable bandwidth, distortion, etc. will be very quickly impractical.And then, whatever our multiplex encoding method is, it will map to the axes of that geometric space.The cube, cylinder and sphere are the simplest. Consider some of their attributes:- A cube is the extrusion of a square, which is the extrusion of a line segment.- More generally, a skewed, unequal-sided cube is a parallelepiped (the 3D equivalent of a parallelogram). The rectangular prism is the special case when the axes are orthogonal, and the cube when the axes are orthogonal and equal. We probably want this case, to avoid dealing with non-square pixels and consequent distortion.- A cylinder is the extrusion of a circle, which is the revolution of a line segment.- A sphere is the revolution of a circle, which is the revolution of a line segment.We can perform a geometric extrusion by scanning a raster: we project a dot or line, then move it relative to the projection screen. If we do this twice, we can go from a pointlike signal to a flat surface, and thus turn a 0-D signal into a line, into a plane, and finally animate that to get our full video experience.We can perform a revolution in the same way, but it's less obvious how this would be constructed electronically. A mechanical implementation might scan the signal onto a line, then rotate the line physically. That gives us a POV spinner. This has the expected downsides: the intensity varies with radius (the central pixels are moving less than the outer ones), and the pixel resolution is inconsistent (leading to a circular streaking appearance towards the edge). We can at least solve the resolution electrically (committing more bandwidth to the edge pixels than the central ones), but this is a challenge -- if we didn't have an FPGA or fast CPU to do it, we'd have a real problem.The signal can also be double-revolved, which has the advantage of spherical symmetry -- it looks the same from any angle (assuming we've solved the uniformity problems, of course).All of this says nothing about the sort of multiplexing -- merely that it exists. Anything doing a scan, has to be time-division multiplexed (TDM), including the mechanical types. TDM seems to be the simplest case. We could of course choose frequency instead (FDM), but it will require a lot of signal analysis to get at.Which... heh, that's actually a bit interesting, for two reasons:1. We could make a POV spinner by driving LEDs from an array of bandpass filters. The bandwidth of each filter is proportional to its center frequency, which is proportional to its radius on the spinner. Thus we automatically get more bandwidth as we go out. Downside: it's not easy to construct arrays of bandpass filters!2. Spectrograms have been used as auditory steganography for some years. This really depends on the availability of "waterfall" spectrogram displays in common audio editing tools, without which, it sounds funny like there's something going on, but you can't really tell until you see the transform. It would be a right pain to construct live video this way (again, you'd want a reasonably powerful CPU or FPGA to do the work), but it would drop directly into to the above setup!Anyway, multiplexing also requires bandwidth. Obviously, you need ~X * Y * FPS bandwidth. NTSC needed a few MHz, which is a good example of the smallest commercially viable bandwidth, give or take. VGA used low 10s of MHz, and it's gone up over time since.Wires in cables, offer 100s of MHz bandwidth without too much effort -- pretty typical for a coaxial or twisted pair of modest length (some meters, perhaps up to 100s of meters when done with care).So multiplexing is a fine choice, and it seems TDM is the simplest and best option.What about the multiplex format, then? If we did a polar coordinate transform, we could transmit pixels in a spiral. Tricky though: the number of pixels per ring varies with radius, so we need to be very careful with timing.The simplest TDM multi-multiplex, with consistent timing and bandwidth (fixed pixel clock), is a square raster. Don't have to worry about pixels per ring, or intensity or shape or anything, it's all equal.We could still quibble about scan direction, whether we're doing it by rows back and forth (lawnmower scan) or all one direction or what; but here again, the simplest case is probably best, and anything more elaborate will only be more and more complicated.For the CRT, it makes particular sense to scan in the same order (e.g., left to right, top to bottom): if the scans alternated direction (making a zig-zag down the screen), you'd need perfect deflection linearity on both phases of the waveform. Probably more work to solve; plus a bidirectional deflection driver is required. (An actual electrical concern back in the days of expensive and unreliable vacuum tubes! The sawtooth sweep is easily solved with a single driver.)For the LCD, it also makes sense to scan in the same order: if the pixel address increments linearly, then it can simply overflow (or compare and reset to zero), little logic required. If the scan reversed every row, you'd need more logic to compute the increment/decrement.Plus, an alternating direction would be annoying. Say, if it ever got out of sync and dropped a row, the whole image flips! Or for the CRT, the vertical scan needs to be a staircase linked to the horizontal sweep, or else the rows will have a subtle taper from edge to edge.So I think it's very reasonable actually, that LCDs would be driven in the same way.Internal to the LCD, there is row buffering, level conversion (translating digital bytes into analog pixel driver voltages), and physical addressing -- row and column drivers. Which means... we do in fact use enormous 2000+ signal cables after all, they're just very short, and etched directly onto the glass.(Or occasionally hot-bar bonded between glass and driver boards. Plasma TVs, too.)Tim

author: NiHaoMike
author_rank: Super Contributor
timestamp: August 08, 2020, 02:30:53 pm
content: Quote from: Berni on August 08, 2020, 11:32:35 amThose blanking periods have become much shorter for LCDs.https://en.wikipedia.org/wiki/Coordinated_Video_Timings#Reduced_blanking

author: peter-h
author_rank: Super Contributor
timestamp: August 08, 2020, 03:01:27 pm
content: In a previous life, I used to design and build CRT drive boards, mono and colour, so I knew the stuff about V and H sync, etcWhat I was referring to was the CPU-graphics interface, which is generally just memory mapped. It's nothing to do with a CRT.It is further downstream that another bit of hardware picks up this video memory (de facto it is dual-ported, although in the old days the writing would be restricted to the H or V flyback slots, for simplicity) and shifts it out into a DAC, synced to the line and frame rates.

author: Berni
author_rank: Super Contributor
timestamp: August 08, 2020, 03:19:29 pm
content: Quote from: NiHaoMike on August 08, 2020, 02:30:53 pmTrue it does make sense to reduce then since who would make a FullHD CRT monitor with HDMI input. But they are still there, mostly because LCD displays have gotten so used to having blanking that they tend to use that time for some internal processes so do actually need a little bit of it and HDMI also needs it to fit audio in. Also HDMI supports interlaced video and that abomination would not exist if it was not for CRTs together with broadcast bandwidth limitations.Quote from: T3sl4co1l on August 08, 2020, 01:11:43 pmSure everyone draws from left to right, top to bottom (Likely just because we read that way since there is no technical reason for it) but there are some variations on it.There is interlaced video for example. But in more modern times its bandwidth requirements that pushing some other ways of doing it. For example high resolution LCD controlers have moved in to Dual Link LVDS. This is the same as the usual 4 pair LVDS except that one set of 4 pairs carries the odd pixels while the other pair carries the even pixels. This drops the bitrate by half and allows the display controller to be implemented as two slower display controllers with the column lines interleaved. This is also how DualLink DVI is implemented. But then as ridiculous resolution monitors came around bandwidth once again became a problem so they started paralleling multiple digital video cables together, so now the display data was being sent to the display with interleaved columns separately for the left and right half of the screen.Then they started putting ridiculous resolution displays in phones and they realized that sending over many millions of pixels 60 times a second takes a lot of power too. So the MIPI-DSI standard implemented two ways of drawing to the display, the classical way (Basically LVDS with a few extra commands) and the DCS way. This method draws pixels in any order while the LCD controller keeps a framebuffer in RAM. So since mobile phones draw a lot of static menus this means the CPU only needs to send the pixels that are changing in any order it likes.Sorry gotten this thread a bit off topic. But i suppose the OP will need to connect a high resolution LCD display at some point and venture into this zoo of modern display interface standards.

author: westfw
author_rank: Super Contributor
timestamp: August 08, 2020, 08:05:07 pm
content: QuoteFair enough. It'll probably be a long time before the standard abstraction of a 2d-array of pixels isn't a 2-d array of memory. (although there have been examples: vector displays, scan-line oriented displays on early video games, sprite-based stuff...)I was explicitly referring to the electrical connection, though, which is the part that has lasted 20+ years.The CPU/Graphics part of VGA (640x480: 1987) quickly gave way to SVGA (800x600: 1988) and XGA (1024x768: 1990) and hung out there for a while till HD came along (and the electricals still worked. Yea for the VGA electrical designers!) (not that there weren't competitors in the early days. I think I still have some "Apple to VGA" adapters...)