Re: [9fans] image/memimage speed

["Aki Nyrhinen" <anyrhine@gmail.com>]

for vgavesa, you can find this on /n/sources/patch/saved/vesasoftscreen.
it's been there for a some time.

for all the cards that have support outside the vesa driver, it's probably
easiest to say monitor=vesa too, since you lose acceleration anyway.
the related mtrr or the pat patch is good to have with this, or take away
the mtrr() call from the patch.

i remember we discussed this a few years back, and you were mostly
concerned about losing accelerated ops then.

On Fri, Dec 5, 2008 at 8:27 PM, Russ Cox <rsc@swtch.com> wrote:
>> i don't think this is the case.  if you recall from the original
>> post, i have used the pat registers to set up memory types on
>> a pcie card and i do see dramatic speedups for drawing to
>> the screen.  however, reading from the screen is just as slow
>> as before.
>
> I think the problem of
>
>> can you explain what the downside of double-buffering
>> would be?  it's not like the days where we asked, hey buddy,
>> have you got 4 megs to spare?
>
> you mean using a soft screen (a kernel copy of the video
> memory, so that you only ever write to the video card).
> double buffering is switching the screen between two
> different copies of the screen image, only ever drawing
> on the one that is not currently on the screen.
>
> in answer to your question, that might be a fine thing to do
> now that memory is more plentiful.  no one has been bothered
> enough to do it.  you would lose the hardware acceleration
> for fill and scroll, since you can't have the video card editing
> the frame buffer directly--your copy would be out of sync.
> on the other hand, writes are so fast that it probably wouldn't
> matter.  the win for hw scroll is not reading from the frame buffer.
>
> i think it's a pretty trivial change, since the relevant code
> is all there for non-direct-mapped frame buffers anyway.
>
> go for it.
>
> russ
>
>