[9fans] ugliness in vesa

[9fans] ugliness in vesa

[john]

So, I finally got tired of slow desktop switching with the nvidia
driver and thought I'd give vesa another shot.  However, upon
rebooting with vesa in 1600x1200x16 mode, I'm seeing strange artifacts
when using vncv and fgb's equis; an example from vnc is shown at
http://csplan9.rit.edu/users/john/ugh.png

Is this a problem with the programs, or with the driver?  I didn't see
anything relating to this in a quick 9fans search, but then I may have
been using the wrong search terms.  If anyone has other programs to
test, I'd be interested to hear; I'm finding that vesa works nicely on
my terminal in terms of speed, and I'm not seeing any difference in 16
bit vs.  32 bit color.


John

Re: [9fans] ugliness in vesa

[erik quanstrom]

On Mon Jul 13 19:58:54 EDT 2009, john@csplan9.rit.edu wrote:
> So, I finally got tired of slow desktop switching with the nvidia
> driver and thought I'd give vesa another shot.

i have had trouble with vesa cursor in 1600x1200.  generally when
i have trouble, the cursor won't move at all.  one problem i
did not finish looking at were the spill-over bits in vga register 13.

nvidia is slow, but have you tried with the newly-integrated mtrr or
the pat stuff?  my pentium iv terminal is pretty snappy in 1600x1200x32 + pat
my amd terminal with a pcie card + pat is even snapper, until the screen is read.
one of these days i'll figure out why the radeon driver is broken for me and/or
integrate aki's double buffer.  even with WT memory, that only speeds the
write path.

- erik

Re: [9fans] ugliness in vesa

[lucio]

> I'm finding that vesa works nicely on
> my terminal in terms of speed, and I'm not seeing any difference in 16
> bit vs.  32 bit color.

VESA has stopped being useful on my SiS 55x, flash based workstation.
The symptoms are an insistence that the video inputs are incorrect
(the monitor complains).  aux/vga -p seems to return valid
information, but there's not much I can check.

I didn't find VESA all that useful when it did work (it was over a
year ago) because of artifacts such as leaving a cursor trail, but at
least I could get some graphics.  Nevertheless, I'm sure all the hard
work at Bell Labs should not go to waste.  Can somebody explain in
some details how rsc's 8i would be used to make VESA more useful as
has been suggested in the past?

++L

Re: [9fans] ugliness in vesa

[John Floren]

On Mon, Jul 13, 2009 at 7:42 PM, erik quanstrom<quanstro@quanstro.net> wrote:
> On Mon Jul 13 19:58:54 EDT 2009, john@csplan9.rit.edu wrote:
>> So, I finally got tired of slow desktop switching with the nvidia
>> driver and thought I'd give vesa another shot.
>
> i have had trouble with vesa cursor in 1600x1200.  generally when
> i have trouble, the cursor won't move at all.  one problem i
> did not finish looking at were the spill-over bits in vga register 13.
>
> nvidia is slow, but have you tried with the newly-integrated mtrr or
> the pat stuff?  my pentium iv terminal is pretty snappy in 1600x1200x32 + pat
> my amd terminal with a pcie card + pat is even snapper, until the screen is read.
> one of these days i'll figure out why the radeon driver is broken for me and/or
> integrate aki's double buffer.  even with WT memory, that only speeds the
> write path.
>
> - erik
>
>

I didn't seem to see any improvement after applying the mtrr patch...
did you make any changes to the vganvidia file before compiling? I
haven't looked at the 'pat' thing, I'll have to check that out.


John
-- 
"I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba

Re: [9fans] ugliness in vesa

[cinap_lenrek]

[-- Attachment #1: Type: text/plain, Size: 193 bytes --]

it happens when changing image contents directly with loadimage only.
then the software cursor is overdrawn and on mouse move it restores
the previous content below the cursor.

--
cinap

[-- Attachment #2: Type: message/rfc822, Size: 2565 bytes --]

From: john@csplan9.rit.edu
To: 9fans@9fans.net
Subject: [9fans] ugliness in vesa
Date: Mon, 13 Jul 2009 19:57:48 -0400
Message-ID: <4d10630f2637158f9286f12b4fc85d48@csplan9.rit.edu>

So, I finally got tired of slow desktop switching with the nvidia
driver and thought I'd give vesa another shot.  However, upon
rebooting with vesa in 1600x1200x16 mode, I'm seeing strange artifacts
when using vncv and fgb's equis; an example from vnc is shown at
http://csplan9.rit.edu/users/john/ugh.png

Is this a problem with the programs, or with the driver?  I didn't see
anything relating to this in a quick 9fans search, but then I may have
been using the wrong search terms.  If anyone has other programs to
test, I'd be interested to hear; I'm finding that vesa works nicely on
my terminal in terms of speed, and I'm not seeing any difference in 16
bit vs.  32 bit color.


John

Re: [9fans] ugliness in vesa

[erik quanstrom]

> I didn't seem to see any improvement after applying the mtrr patch...
> did you make any changes to the vganvidia file before compiling? I
> haven't looked at the 'pat' thing, I'll have to check that out.
>

for the pat business, i did:

/n/sources/plan9//sys/src/9/pc/vganvidia.c:371,377 - vganvidia.c:371,377
  		if(scr->storage <= scr->apsize)
  			nv.dmabase = (ulong*)((uchar*)scr->vaddr + scr->storage - 128*1024);
  		else{
- 			nv.dmabase = (void*)vmap(scr->paddr + scr->storage - 128*1024, 128*1024);
+ 			nv.dmabase = (void*)vmappat(scr->paddr + scr->storage - 128*1024, 128*1024, PATWT);
  			if(nv.dmabase == 0){
  				hwaccel = 0;
  				hwblank = 0;

a quick explainer.  the pat patch just keeps a look-aside
table of memory of special types.  any time the mmu
code is asked to map that memory, it is mapped with
the special type given.  this means that if you wanted
to, for example (the current interface is better than
this unless you want a user-space driver), map pci space
in a segment accessable from user space, you could do
this and you would get the proper NC memory type.

it's fun when the explination's longer than the code.

- erik

Re: [9fans] ugliness in vesa

[John Floren]

On Tue, Jul 14, 2009 at 5:06 AM, erik quanstrom<quanstro@quanstro.net> wrote:
>> I didn't seem to see any improvement after applying the mtrr patch...
>> did you make any changes to the vganvidia file before compiling? I
>> haven't looked at the 'pat' thing, I'll have to check that out.
>>
>
> for the pat business, i did:
>
> /n/sources/plan9//sys/src/9/pc/vganvidia.c:371,377 - vganvidia.c:371,377
>                if(scr->storage <= scr->apsize)
>                        nv.dmabase = (ulong*)((uchar*)scr->vaddr + scr->storage - 128*1024);
>                else{
> -                       nv.dmabase = (void*)vmap(scr->paddr + scr->storage - 128*1024, 128*1024);
> +                       nv.dmabase = (void*)vmappat(scr->paddr + scr->storage - 128*1024, 128*1024, PATWT);
>                        if(nv.dmabase == 0){
>                                hwaccel = 0;
>                                hwblank = 0;
>
> a quick explainer.  the pat patch just keeps a look-aside
> table of memory of special types.  any time the mmu
> code is asked to map that memory, it is mapped with
> the special type given.  this means that if you wanted
> to, for example (the current interface is better than
> this unless you want a user-space driver), map pci space
> in a segment accessable from user space, you could do
> this and you would get the proper NC memory type.
>
> it's fun when the explination's longer than the code.
>
> - erik
>
>

I believe I properly applied the pat patch, but I'm not really seeing
any improvement. At least, it still takes fully two seconds to bring
one large window in front of another.

Did you change anything with the nvidia driver when applying the mtrr
patch? I was under the impression that the applied patch only affected
the vesa driver.


John
-- 
"I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba

Re: [9fans] ugliness in vesa

[erik quanstrom]

> I believe I properly applied the pat patch, but I'm not really seeing
> any improvement. At least, it still takes fully two seconds to bring
> one large window in front of another.

that's because the screen is not double-buffered.  pat or mtrr do
not improve reads from video memory.  there is no such thing
as read combining.  and on some nvidia cards, especially the pcie
ones i have, reads from video memory are really slow.

> Did you change anything with the nvidia driver when applying the mtrr
> patch? I was under the impression that the applied patch only affected
> the vesa driver.

only the one line previously posted.  (a similar change was made to the
vesa driver, of course.)

- erik

Re: [9fans] ugliness in vesa

[John Floren]

On Tue, Jul 14, 2009 at 9:10 AM, erik quanstrom<quanstro@coraid.com> wrote:
>> I believe I properly applied the pat patch, but I'm not really seeing
>> any improvement. At least, it still takes fully two seconds to bring
>> one large window in front of another.
>
> that's because the screen is not double-buffered.  pat or mtrr do
> not improve reads from video memory.  there is no such thing
> as read combining.  and on some nvidia cards, especially the pcie
> ones i have, reads from video memory are really slow.

I haven't done much graphics hacking, but I remember that implementing
double buffering in the few programs I wrote was extremely easy and
gave a really cheap performance boost. Would it be similarly easy to
add double-buffering to the driver? I'm willing to put in some time,
but not too much or Ron will smack me ;)

>
>> Did you change anything with the nvidia driver when applying the mtrr
>> patch? I was under the impression that the applied patch only affected
>> the vesa driver.
>
> only the one line previously posted.  (a similar change was made to the
> vesa driver, of course.)
>
> - erik
>

As I'm reading it, the change to vganvidia.c you posted above
(re-pasted below) does pat stuff. Am I confused? I don't think pat and
mtrr are the same thing...

nv.dmabase = (void*)vmappat(scr->paddr + scr->storage - 128*1024,
128*1024, PATWT);


John
-- 
"I've tried programming Ruby on Rails, following TechCrunch in my RSS
reader, and drinking absinthe. It doesn't work. I'm going back to C,
Hunter S. Thompson, and cheap whiskey." -- Ted Dziuba

Re: [9fans] ugliness in vesa

[erik quanstrom]

> As I'm reading it, the change to vganvidia.c you posted above
> (re-pasted below) does pat stuff. Am I confused? I don't think pat and
> mtrr are the same thing...

they're not.  mtrr operates at the physical address level and
it's just a bunch of registers that control caching of a (limited set of)
fixed and variable ranges.  pat on the other hand, works on
page tables (and directories).

however the net result is that for pci space (or the vga ap)
which is normally UC (or is it UC-), if you use a mtrr range to
mark it as WT or pat entries to market it as WT, there is no
difference.

- erik