Aren/haiku
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fixed overlay right-clipping: might fix NM2200+ distortions as well!

Browse Source 
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8527 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Rudolf Cornelissen 2004-08-02 13:50:25 +00:00
parent 630b1126bb
commit 12611c54ff
4 changed files with 42 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
src/add-ons/accelerants/neomagic/engine/nm_bes.c
View File

@ -287,7 +287,7 @@ status_t nm_configure_bes
bi.hsrcendv = (((uint32)((my_ov.h_start + my_ov.width) - 1)) << 16);
}
/* AND below required by hardware */
bi.hsrcendv &= 0x03fffffc;
bi.hsrcendv &= 0x03ffffff;
LOG(4,("Overlay: last horizontal (sub)pixel of input bitmap contributing %f\n", bi.hsrcendv / (float)65536));
@ -463,18 +463,30 @@ status_t nm_configure_bes
{
bi.a1orgv >>= 1;
/* horizontal source end does not use subpixelprecision: granularity is 8 pixels */
/* (horizontal source end minimizes used bandwidth) */
PCIGRPHW(0xbc, (((((bi.hsrcendv >> 16) + 7) & ~8) / 8) - 1));
/* notes:
* - correctly programming horizontal source end minimizes used bandwidth;
* - adding 9 below is in fact:
* - adding 1 to round-up to the nearest whole source-end value
(making SURE we NEVER are a (tiny) bit too low);
- adding 1 to convert 'last used position' to 'number of used pixels';
- adding 7 to round-up to the nearest higher (or equal) valid register
value (needed because of it's 8-pixel granularity). */
PCIGRPHW(0xbc, ((((bi.hsrcendv >> 16) + 9) >> 3) - 1));
}
else
{
/* NM2200 and later cards use bytes to define buffer pitch */
buf_pitch <<= 1;
/* horizontal source end does not use subpixelprecision: granularity is 16 pixels */
/* (horizontal source end minimizes used bandwidth) */
//fixme? divide by 16 instead of 8 (if >= NM2200 owners report trouble then use 8!)
//fixme? check if overlaybuffer width should also have granularity of 16 now!
PCIGRPHW(0xbc, (((((bi.hsrcendv >> 16) + 15) & ~16) / 16) - 1));
/* notes:
* - programming this register just a tiny bit too low messes up vertical
* scaling badly (also distortion stripes and flickering are reported)!
* - not programming this register correctly will mess-up the picture when
* it's partly clipping on the right side of the screen...
* - make absolutely sure the engine can fetch the last pixel needed from
* the sourcebitmap even if only to generate a tiny subpixel from it!
* (see remarks for < NM2200 cards regarding programming this register) */
PCIGRPHW(0xbc, ((((bi.hsrcendv >> 16) + 17) >> 4) - 1));
}
PCIGRPHW(BUF1ORGL, (bi.a1orgv & 0xff));
PCIGRPHW(BUF1ORGM, ((bi.a1orgv >> 8) & 0xff));

2
src/add-ons/accelerants/neomagic/engine/nm_general.c
View File

@ -47,7 +47,7 @@ status_t nm_general_powerup()
{
status_t status;
LOG(1,("POWERUP: Neomagic (open)BeOS Accelerant 0.08 running.\n"));
LOG(1,("POWERUP: Neomagic (open)BeOS Accelerant 0.09 running.\n"));
/* detect card type and power it up */
switch(CFGR(DEVID))

7
src/add-ons/kernel/drivers/graphics/neomagic/UPDATE.html
View File

@ -4,12 +4,13 @@
</head>
<body>
<p><h2>Changes done for each driverversion:</h2></p>
<p><h1>head 0.08 (Rudolf)</h1></p>
<p><h1>head 0.09 (Rudolf)</h1></p>
<ul>
<li>Added full 2D acceleration for all remaining cards that did not have that yet with this driver (still largely untested);
<li>Fixed a long standing problem with MagicMedia (all NM2200 and later) cards with overlay: buffer width is programmed correctly now. Can't believe I didn't see that before!
<li>Updated NM2200 and later cards workspace virtualsize restrictions for accelerated modes: it turns out these cards engines have the same restrictions as most older ones, being 1600x1024 resolution;
<li>Updated overlay scaling restrictions: officially the cards support upto and including 8x upscaling.
<li>Updated overlay scaling restrictions: officially the cards support upto and including 8x upscaling;
<li>Fixed error regarding calculating overlay engine register value for right-clipping video output: on NM2200 and later this was (probably) responsible for the big-time output distortions even without clipping!
</ul>
<p><h1>nm_driver 0.06 (Rudolf)</h1></p>
<ul>
@ -60,7 +61,7 @@ Acceleration engine benchmarked and tested for errors with BeRoMeter V1.2.6.
<p><h1>Still todo:</h1></p>
<ul>
<li>fix for trouble with booting into modes above 800x600 resolution on some cards (please report this behaviour!);
<li>MagicMedia series overlay update: still contains errors.
<li>MagicMedia series overlay update: still contains errors???.
</ul>
</p>
</body>

24
src/add-ons/kernel/drivers/graphics/neomagic/driver.c
View File

@ -944,18 +944,30 @@ void drv_program_bes_ISA(nm_bes_data *bes)
{
bes->a1orgv >>= 1;
/* horizontal source end does not use subpixelprecision: granularity is 8 pixels */
/* (horizontal source end minimizes used bandwidth) */
KISAGRPHW(0xbc, (((((bes->hsrcendv >> 16) + 7) & ~8) / 8) - 1));
/* notes:
* - correctly programming horizontal source end minimizes used bandwidth;
* - adding 9 below is in fact:
* - adding 1 to round-up to the nearest whole source-end value
(making SURE we NEVER are a (tiny) bit too low);
- adding 1 to convert 'last used position' to 'number of used pixels';
- adding 7 to round-up to the nearest higher (or equal) valid register
value (needed because of it's 8-pixel granularity). */
KISAGRPHW(0xbc, ((((bes->hsrcendv >> 16) + 9) >> 3) - 1));
}
else
{
/* NM2200 and later cards use bytes to define buffer pitch */
buf_pitch <<= 1;
/* horizontal source end does not use subpixelprecision: granularity is 16 pixels */
/* (horizontal source end minimizes used bandwidth) */
//fixme? divide by 16 instead of 8 (if >= NM2200 owners report trouble then use 8!)
//fixme? check if overlaybuffer width should also have granularity of 16 now!
KISAGRPHW(0xbc, (((((bes->hsrcendv >> 16) + 15) & ~16) / 16) - 1));
/* notes:
* - programming this register just a tiny bit too low messes up vertical
* scaling badly (also distortion stripes and flickering are reported)!
* - not programming this register correctly will mess-up the picture when
* it's partly clipping on the right side of the screen...
* - make absolutely sure the engine can fetch the last pixel needed from
* the sourcebitmap even if only to generate a tiny subpixel from it!
* (see remarks for < NM2200 cards regarding programming this register) */
KISAGRPHW(0xbc, ((((bes->hsrcendv >> 16) + 17) >> 4) - 1));
}
KISAGRPHW(BUF1ORGL, (bes->a1orgv & 0xff));
KISAGRPHW(BUF1ORGM, ((bes->a1orgv >> 8) & 0xff));