From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <218917ef0812070900u4f15e817nf78f2b99e83ebc75@mail.gmail.com>
Date: Sun,  7 Dec 2008 19:00:13 +0200
From: "Aki Nyrhinen" <anyrhine@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
In-Reply-To: <dd6fe68a0812051027t5661d7ebs81cce9a4ca0a6b7f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <13426df10812042239pde2100dw696049def0160c4a@mail.gmail.com>
	<39cb2be32e592403f7336c6200cf56a3@quanstro.net>
	<dd6fe68a0812051027t5661d7ebs81cce9a4ca0a6b7f@mail.gmail.com>
Subject: Re: [9fans] image/memimage speed
Topicbox-Message-UUID: 5d2fc972-ead4-11e9-9d60-3106f5b1d025

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