support vram

[mckuhei]

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

[CoolCat467]

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"?

[IgorTimofeev]

@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)

[CoolCat467]

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]

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.

[IgorTimofeev]

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]

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

[CoolCat467]

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