MineOS icon indicating copy to clipboard operation
MineOS copied to clipboard

support vram

Open mckuhei opened this issue 4 years ago • 7 comments

https://ocdoc.cil.li/component:gpu#video_ram_buffers

mckuhei avatar Jan 16 '21 12:01 mckuhei

MineOS has it's own double buffering protocol to best utilize the CPU/GPU by only rendering changes to the previous frame. If you want variable screen sizes (and therefore variable buffer sizes), there is already support for that too.

What do you mean by "support vram"?

CoolCat467 avatar Jan 16 '21 17:01 CoolCat467

@CoolCat467 It's a new OpenComputers GPU feature. Nice idea btw, rendering should be really fast - but MineOS development has finished. I'll keep this issue open as reminder for some day (or someone)

IgorTimofeev avatar Jan 16 '21 21:01 IgorTimofeev

Ah, ok. Oh, and I guess with a good method of saving frames, that would be pretty fast. Obviously it would use up more hard drive space, being virtual ram, but with having way more hard drive space than ram you could handle large images much easier I would think.

CoolCat467 avatar Jan 17 '21 02:01 CoolCat467

And virtual ram for not just the screen but also applications would make it possible to load tons more things, even though ram de-allocation is pretty good from what I've seen, like having full 3d games without worrying so much about the ram usage. Obviously OpenComputers computers are pretty slow, but still.

CoolCat467 avatar Jan 17 '21 02:01 CoolCat467

Yeah, sounds good. Too sad that Screen lib has too much deep os optimizations that needs to be rewritten for VRAM support...

Perfectly, support for both systems is generally needed for old versions of the mod, so that, depending on the availability of VRAM methods, the system itself can decide which rendering system to use: through virtual RAM buffers of ram or through native GPU VRAM

IgorTimofeev avatar Jan 17 '21 14:01 IgorTimofeev

Just tested VRAM buffers system - wtf, it's freaking slow. I mean ofk drawing to buffer and performing gpu.bitblc() on whole screen is way faster then basic loop of gpu.set/fill/setBackground(), but I was clearly expecting something more usable for serious graphical purposes. Moreover: the more changed pixels are contained in the VRAM buffer, the slower the bitblc operation will be, from which it follows that the VRAM buffers already have a built-in double buffering and pixel comparison methods.

Let's see what will be in the next release version of mod with this system. I sincerely hope that the performance will improve - because it is fucking not normal when a software solution is faster than a hardware one

IgorTimofeev avatar Jan 29 '21 07:01 IgorTimofeev

That is definitely not normal. That is truly unfortunate that the hardware implementation of VRAM is slow compared to software solutions.

CoolCat467 avatar Jan 29 '21 13:01 CoolCat467