3 ms·

QEmu integration just started working, https://github.com/letoram/qemu https://github.com/letoram/qemu it's far from complete enough that I'll try to upstream p

QEmu integration just started working, https://github.com/letoram/qemu https://github.com/letoram/qemu it's far from complete enough that I'll try to upstream patches. -display arcan. Your GPU is most likely fill-rate limited. Are you running this entirely natively (EGL/GBM/KMS stack) or using SDL through X? In the latter case there'll be so many fullscreen sized buffer copies that your GPU cries. There's more special tricks I can do to get the fullscreen case to go faster, and it's on the near todo for Durden anyhow. Also, the terminal emulator only really supports truetype fonts (there's a built-in fallback that is quick, but it's awful and only 7bit ascii..), which is damn expensive to render.

i336_ 10y ago
Opens repository "Official QEMU mirror." "I see." So basically... you can display QEMU inside arcan. That's really neat. My GPU is everything-limited :P I just tried arcan on my integrated video, no issues there. Maybe an almost imperceptible bit of slowdown, but just that, almost imperceptible. I'm using an ancient ATI X1300-series [1002:7183] fanless GPU I yanked from an oldish workstation so I can have 3 screens in a pinch. It runs two displays; my i3's HD 2000 runs the 3rd. (And I can't move Chrome between :0.0 and :0.1, which X won the fight over me having. Yey :3) As for drivers, I'm using the radeon driver w/ KMS (switching between X and tty is instantaneous); the only issue is that I occasionally see framedrops due to driver bugs, but that's the only problem I have; the driver is very fast. (But it should be, the card's a decade old. :P) I'm not sure if I'm running truly fullscreen, incidentally - I can see vestiges of i3 (my windowmanager) in the form of a 1px border underneath the bottom of the arcan window. ...So I just tried -f... and you don't support screens with different resolutions. My center display is 1600x1200, my left is 1280x1024. I get fullscreen on the left, and a cute arcan window (that I can't move my mouse into) on my center display. (The left and middle are on the ATI card.) With fullscreen it's still slowish (which I understand is to be expected at this point). AFAIK I'm using SDL; I tried building with X11 but the build balked, so I conceded to the instructions on github :P About truetype and terminal emulators, I had an idea a while ago: glyph caching. (((8x15=size)x3=24bpp)x256=ASCII)=92160 bytes. That's remarkably manageable. Unicode blows the 256 out of the water, but how much of Unicode will the average terminal session see? Certainly not all of it, so the cache eviction algorithm won't need to be particularly aggressive or smart. The only really major catch is that #222222 will not antialias the same as #FFFFFF, and trying to make one look like the other will look either really dim or really pukey, so the caching system would also need to cache each color of each character that it sees. However, this is not actually totally the end of the world, since glyph tables don't actually take up all that much space, as I've just noted. Very mathematically inelegant, but quite possibly worth it in practice. That's the point I would be stopping at; you may be interested in going full crazy with something like https://news.ycombinator.com/item?id=11440599 https://news.ycombinator.com/item?id=11440599 (this looks like a lot of fun to play with). What's the builtin fallback font, out of curiosity? Also, I want to clarify and emphasize that, running the terminal in arcan on my old ATI card, the size of the terminal window is directly proportionate to the input+video lag. As I resize the terminal smaller (in floating mode) it speeds up, as I resize it bigger it sl-ow-s ddoowwnn and gets stuttery and glitchy. Lastly, I just discovered an extremely curious phenomenon I thought I'd mention. I wanted to screencap the terminal cursor to get the font size for the calculation above. After learning about "mouse lock > no" (good riddance :D) so I could take the screenshot, I soon found that the input lag I'd experienced was actually affecting my entire X session. Moving the arcan window offscreen seems to alleviate it; moving it back onscreen and eg running htop (inside a fullscreen terminal >:D) bogs everything down so badly that typing into Chrome (running on the i3 GPU, on :0.1) is very very very noticeably slow, and resizing xterm is... well I can sit there for 10-20 seconds watching it repaint. The weird thing: my CPU was near 0% utilization. This is either a bottleneck in my GPU, X or both (or X blocking on GPU bottlenecks). I'm not highlighting any of this to make arcan look bad; I personally find it really interesting to throw code at suboptimal hardware and seeing what, if anything, can be done to speed it up - because if code runs well on worst-case scenario hardware, it'll fly on average kit. So I thought I'd mention the above in case it's interesting. If you have any ideas for benchmarks I can run or timing information I can collect I'm fine with supplying that. ^^

i336_ 10y ago

Opens repository "Official QEMU mirror." "I see." So basically... you can display QEMU inside arcan. That's really neat. My GPU is everything-limited :P I just tried arcan on my integrated video, no issues there. Maybe an almost imperceptible bit of slowdown, but just that, almost imperceptible. I'm using an ancient ATI X1300-series [1002:7183] fanless GPU I yanked from an oldish workstation so I can have 3 screens in a pinch. It runs two displays; my i3's HD 2000 runs the 3rd. (And I can't move Chrome between :0.0 and :0.1, which X won the fight over me having. Yey :3) As for drivers, I'm using the radeon driver w/ KMS (switching between X and tty is instantaneous); the only issue is that I occasionally see framedrops due to driver bugs, but that's the only problem I have; the driver is very fast. (But it should be, the card's a decade old. :P) I'm not sure if I'm running truly fullscreen, incidentally - I can see vestiges of i3 (my windowmanager) in the form of a 1px border underneath the bottom of the arcan window. ...So I just tried -f... and you don't support screens with different resolutions. My center display is 1600x1200, my left is 1280x1024. I get fullscreen on the left, and a cute arcan window (that I can't move my mouse into) on my center display. (The left and middle are on the ATI card.) With fullscreen it's still slowish (which I understand is to be expected at this point). AFAIK I'm using SDL; I tried building with X11 but the build balked, so I conceded to the instructions on github :P About truetype and terminal emulators, I had an idea a while ago: glyph caching. (((8x15=size)x3=24bpp)x256=ASCII)=92160 bytes. That's remarkably manageable. Unicode blows the 256 out of the water, but how much of Unicode will the average terminal session see? Certainly not all of it, so the cache eviction algorithm won't need to be particularly aggressive or smart. The only really major catch is that #222222 will not antialias the same as #FFFFFF, and trying to make one look like the other will look either really dim or really pukey, so the caching system would also need to cache each color of each character that it sees. However, this is not actually totally the end of the world, since glyph tables don't actually take up all that much space, as I've just noted. Very mathematically inelegant, but quite possibly worth it in practice. That's the point I would be stopping at; you may be interested in going full crazy with something like https://news.ycombinator.com/item?id=11440599 https://news.ycombinator.com/item?id=11440599 (this looks like a lot of fun to play with). What's the builtin fallback font, out of curiosity? Also, I want to clarify and emphasize that, running the terminal in arcan on my old ATI card, the size of the terminal window is directly proportionate to the input+video lag. As I resize the terminal smaller (in floating mode) it speeds up, as I resize it bigger it sl-ow-s ddoowwnn and gets stuttery and glitchy. Lastly, I just discovered an extremely curious phenomenon I thought I'd mention. I wanted to screencap the terminal cursor to get the font size for the calculation above. After learning about "mouse lock > no" (good riddance :D) so I could take the screenshot, I soon found that the input lag I'd experienced was actually affecting my entire X session. Moving the arcan window offscreen seems to alleviate it; moving it back onscreen and eg running htop (inside a fullscreen terminal >:D) bogs everything down so badly that typing into Chrome (running on the i3 GPU, on :0.1) is very very very noticeably slow, and resizing xterm is... well I can sit there for 10-20 seconds watching it repaint. The weird thing: my CPU was near 0% utilization. This is either a bottleneck in my GPU, X or both (or X blocking on GPU bottlenecks). I'm not highlighting any of this to make arcan look bad; I personally find it really interesting to throw code at suboptimal hardware and seeing what, if anything, can be done to speed it up - because if code runs well on worst-case scenario hardware, it'll fly on average kit. So I thought I'd mention the above in case it's interesting. If you have any ideas for benchmarks I can run or timing information I can collect I'm fine with supplying that. ^^