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 <[EMAIL PROTECTED]> 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 > >
