Bug in devg-rage

Believe me, I was very hesitant to blame this on the driver. I know that
what I’m doing is very new to me so I naturally assumed what was happening
was my fault.

Here’s what’s happening:

I’m drawing into a off screen context and blitting the image to a PtRaw
Widget. When I fill up the screen I blit the off screen context left by
200 pixels. That works fine. I then refill those right most 200 pixels
with 2 color stripes. Here is that code:

void colorize_horizontal_data_channels ( int left, int right )
{
static const PgColor_t channel_colors[ 2 ] = { PgRGB( 215, 255, 255 ), PgRGB( 255, 215, 215 ) };
PhRect_t sample_rect;

sample_rect.ul.x = left;
sample_rect.lr.x = right;
sample_rect.ul.y = 0;
bool color_count = 0;

for( int nc = 0; nc < NUM_SC_CHANNELS; nc++ )
{
// determine which data channels need to be displayed
if( format.formats[ nc ].ch != NOT_USED
&& format.formats[ nc ].osd_pixels )
{
PgSetFillColor( channel_colors[ color_count ] );
sample_rect.lr.y = sample_rect.ul.y + format.formats[ nc ].osd_pixels - 1;
PgDrawRect( &sample_rect, Pg_DRAW_FILL );
sample_rect.ul.y = sample_rect.lr.y + 1;
color_count = !color_count;
}
}
}

This same code in called at startup and works fine. But when it’s called
to replace just the right most 200 pixels is’t as if it isn’t even
happening. I have verified that it IS being called.

What finally convinced me that it was a driver problem and not my code is
this: I copied the whole application onto my laptop to take it home to
work on. But when I got home, it worked the very first time without any
modification.

Here are the details:

I am running the card at 1280x1024 in 32 bit resolution.
My PtRaw widget takes up most of the screen, 1263x929,
just in case this matters.

Desktop at work: 2.4 GHz w/1GB RAM
Graphics card:
Class = Display (VGA)
Vendor ID = 1002h, ATI Technologies
Device ID = 4750h, Rage 3D Pro PCI Graphics Accelerator
PCI index = 0h
Class Codes = 030000h
Revision ID = 5ch
Bus number = 2
Device number = 7
Function num = 0
Status Reg = 280h
Command Reg = 86h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 40h
Cache Line Size= 10h un-cacheable
PCI Mem Address = f8000000h prefetchable 32bit length 16777216 enabled
PCI IO Address = e800h length 256 disabled
PCI Mem Address = ff8fe000h 32bit length 4096 enabled
Subsystem Vendor ID = 1002h
Subsystem ID = 80h
PCI Expansion ROM = 80000000h length 131072 disabled
Max Lat = 0ns
Min Gnt = 8ns
PCI Int Pin = INT A
Interrupt line = 11
CPU Interrupt = bh

pidin -Pio-graphics me says:
479264 1 on/bin/io-graphics 12r RECEIVE 88K 4676K 12K(516K)*
479264 2 on/bin/io-graphics 12r REPLY 88K 4676K 4096(516K)
479264 3 on/bin/io-graphics 12r REPLY 88K 4676K 8192(132K)
ldqnx.so.2 @b0300000 344K 16K
libgri.so.2 @b8200000 40K 4096
libfont.so.1 @b820b000 40K 4096
libm.so.2 @b8216000 104K 8192
libdisputil.so.2 @b8232000 32K 8192
phfont.so @b823c000 124K 20K
tharnessutils.so.1 @b8260000 16K 4096
FCcore.so @b8265000 32K 8192
libblkcache.so.2 @b826f000 12K 4096
libFF-T2K-fm.so.1 @b8273000 12K 4096
bFF-T2K-cache.so.2 @b8277000 8192 4096
libFF-T2K.so.2 @b827a000 232K 12K
PHFcore.so @b82b7000 24K 4096
libfontutils.so.1 @b82be000 4096 4096
ttfFFcore.so @b82c0000 36K 4096
devg-rage.so @b82ca000 28K 4096
libffb.so.2 @b82d2000 44K 4096
gri-photon.so @b82de000 56K 8192
libphrender.so.2 @b82ee000 204K 8192
/dev/mem @40100000 ( 0) 4096
/dev/mem @40101000 ( 10000) 128K
/dev/mem @40121000 ( 0) 8192K
/dev/mem @40921000 (f87ff000) 4096
/dev/mem @40922000 ( 0) 32K
/dev/mem @4092a000 ( 0) 3840K

Mt laptop system is using an ATI Technologies (VendorD 1002),
Mobility M3 AGP 2x (DeviceID 4c46)
Driver devg-vesabios.so (The new and improved version that what’s his
name did). And it is running in 1024x768x32 bit mode.

So, whay can’t I reinitialize those right most 200 bytes but only on the
desktop system?

Is there a circumvention?

If it will help I can tarball up the whole application with a data file
and send it along. I warn you, it IS quite large.

Is it possible that this is a synchronization issue?

Do I need to do some kind of graphic wait or lock?
Remember I’m doing this immediateyl after a context blit.

I am not yet using these functions and I’m not sure
when they are needed.


Bill Caroselli <qtps@earthlink.net> wrote:
BC > Believe me, I was very hesitant to blame this on the driver. I know that
BC > what I’m doing is very new to me so I naturally assumed what was happening
BC > was my fault.

BC > Here’s what’s happening:

BC > I’m drawing into a off screen context and blitting the image to a PtRaw
BC > Widget. When I fill up the screen I blit the off screen context left by
BC > 200 pixels. That works fine. I then refill those right most 200 pixels
BC > with 2 color stripes. Here is that code:

BC > void colorize_horizontal_data_channels ( int left, int right )
BC > {
BC > static const PgColor_t channel_colors[ 2 ] = { PgRGB( 215, 255, 255 ), PgRGB( 255, 215, 215 ) };
BC > PhRect_t sample_rect;

BC > sample_rect.ul.x = left;
BC > sample_rect.lr.x = right;
BC > sample_rect.ul.y = 0;
BC > bool color_count = 0;

BC > for( int nc = 0; nc < NUM_SC_CHANNELS; nc++ )
BC > {
BC > // determine which data channels need to be displayed
BC > if( format.formats[ nc ].ch != NOT_USED
BC > && format.formats[ nc ].osd_pixels )
BC > {
BC > PgSetFillColor( channel_colors[ color_count ] );
BC > sample_rect.lr.y = sample_rect.ul.y + format.formats[ nc ].osd_pixels - 1;
BC > PgDrawRect( &sample_rect, Pg_DRAW_FILL );
BC > sample_rect.ul.y = sample_rect.lr.y + 1;
BC > color_count = !color_count;
BC > }
BC > }
BC > }

BC > This same code in called at startup and works fine. But when it’s called
BC > to replace just the right most 200 pixels is’t as if it isn’t even
BC > happening. I have verified that it IS being called.

BC > What finally convinced me that it was a driver problem and not my code is
BC > this: I copied the whole application onto my laptop to take it home to
BC > work on. But when I got home, it worked the very first time without any
BC > modification.

BC > Here are the details:

BC > I am running the card at 1280x1024 in 32 bit resolution.
BC > My PtRaw widget takes up most of the screen, 1263x929,
BC > just in case this matters.

BC > Desktop at work: 2.4 GHz w/1GB RAM
BC > Graphics card:
BC > Class = Display (VGA)
BC > Vendor ID = 1002h, ATI Technologies
BC > Device ID = 4750h, Rage 3D Pro PCI Graphics Accelerator
BC > PCI index = 0h
BC > Class Codes = 030000h
BC > Revision ID = 5ch
BC > Bus number = 2
BC > Device number = 7
BC > Function num = 0
BC > Status Reg = 280h
BC > Command Reg = 86h
BC > Header type = 0h Single-function
BC > BIST = 0h Build-in-self-test not supported
BC > Latency Timer = 40h
BC > Cache Line Size= 10h un-cacheable
BC > PCI Mem Address = f8000000h prefetchable 32bit length 16777216 enabled
BC > PCI IO Address = e800h length 256 disabled
BC > PCI Mem Address = ff8fe000h 32bit length 4096 enabled
BC > Subsystem Vendor ID = 1002h
BC > Subsystem ID = 80h
BC > PCI Expansion ROM = 80000000h length 131072 disabled
BC > Max Lat = 0ns
BC > Min Gnt = 8ns
BC > PCI Int Pin = INT A
BC > Interrupt line = 11
BC > CPU Interrupt = bh

BC > pidin -Pio-graphics me says:
BC > 479264 1 on/bin/io-graphics 12r RECEIVE 88K 4676K 12K(516K)*
BC > 479264 2 on/bin/io-graphics 12r REPLY 88K 4676K 4096(516K)
BC > 479264 3 on/bin/io-graphics 12r REPLY 88K 4676K 8192(132K)
BC > ldqnx.so.2 @b0300000 344K 16K
BC > libgri.so.2 @b8200000 40K 4096
BC > libfont.so.1 @b820b000 40K 4096
BC > libm.so.2 @b8216000 104K 8192
BC > libdisputil.so.2 @b8232000 32K 8192
BC > phfont.so @b823c000 124K 20K
BC > tharnessutils.so.1 @b8260000 16K 4096
BC > FCcore.so @b8265000 32K 8192
BC > libblkcache.so.2 @b826f000 12K 4096
BC > libFF-T2K-fm.so.1 @b8273000 12K 4096
BC > bFF-T2K-cache.so.2 @b8277000 8192 4096
BC > libFF-T2K.so.2 @b827a000 232K 12K
BC > PHFcore.so @b82b7000 24K 4096
BC > libfontutils.so.1 @b82be000 4096 4096
BC > ttfFFcore.so @b82c0000 36K 4096
BC > devg-rage.so @b82ca000 28K 4096
BC > libffb.so.2 @b82d2000 44K 4096
BC > gri-photon.so @b82de000 56K 8192
BC > libphrender.so.2 @b82ee000 204K 8192
BC > /dev/mem @40100000 ( 0) 4096
BC > /dev/mem @40101000 ( 10000) 128K
BC > /dev/mem @40121000 ( 0) 8192K
BC > /dev/mem @40921000 (f87ff000) 4096
BC > /dev/mem @40922000 ( 0) 32K
BC > /dev/mem @4092a000 ( 0) 3840K

BC > Mt laptop system is using an ATI Technologies (VendorD 1002),
BC > Mobility M3 AGP 2x (DeviceID 4c46)
BC > Driver devg-vesabios.so (The new and improved version that what’s his
BC > name did). And it is running in 1024x768x32 bit mode.

BC > So, whay can’t I reinitialize those right most 200 bytes but only on the
BC > desktop system?

BC > Is there a circumvention?

BC > If it will help I can tarball up the whole application with a data file
BC > and send it along. I warn you, it IS quite large.


Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number
qtps@earthlink.net

Bill Caroselli <qtps@earthlink.net> wrote:
BC > Is it possible that this is a synchronization issue?

BC > Do I need to do some kind of graphic wait or lock?
BC > Remember I’m doing this immediateyl after a context blit.

BC > I am not yet using these functions and I’m not sure
BC > when they are needed.

Aparently, putting these three lines back to back solved that problem.
PgContextBlit( &os_context, &from, &os_context, &to );
PgFlush();
PgWaitHWIdle();
Should it be necessary to do this after a context blit?

I.E. Is this a bug or something that needs to be documented?


BC > Bill Caroselli <qtps@earthlink.net> wrote:
BC > BC > Believe me, I was very hesitant to blame this on the driver. I know that
BC > BC > what I’m doing is very new to me so I naturally assumed what was happening
BC > BC > was my fault.

BC > BC > Here’s what’s happening:

BC > BC > I’m drawing into a off screen context and blitting the image to a PtRaw
BC > BC > Widget. When I fill up the screen I blit the off screen context left by
BC > BC > 200 pixels. That works fine. I then refill those right most 200 pixels
BC > BC > with 2 color stripes. Here is that code:

BC > BC > void colorize_horizontal_data_channels ( int left, int right )
BC > BC > {
BC > BC > static const PgColor_t channel_colors[ 2 ] = { PgRGB( 215, 255, 255 ), PgRGB( 255, 215, 215 ) };
BC > BC > PhRect_t sample_rect;

BC > BC > sample_rect.ul.x = left;
BC > BC > sample_rect.lr.x = right;
BC > BC > sample_rect.ul.y = 0;
BC > BC > bool color_count = 0;

BC > BC > for( int nc = 0; nc < NUM_SC_CHANNELS; nc++ )
BC > BC > {
BC > BC > // determine which data channels need to be displayed
BC > BC > if( format.formats[ nc ].ch != NOT_USED
BC > BC > && format.formats[ nc ].osd_pixels )
BC > BC > {
BC > BC > PgSetFillColor( channel_colors[ color_count ] );
BC > BC > sample_rect.lr.y = sample_rect.ul.y + format.formats[ nc ].osd_pixels - 1;
BC > BC > PgDrawRect( &sample_rect, Pg_DRAW_FILL );
BC > BC > sample_rect.ul.y = sample_rect.lr.y + 1;
BC > BC > color_count = !color_count;
BC > BC > }
BC > BC > }
BC > BC > }

BC > BC > This same code in called at startup and works fine. But when it’s called
BC > BC > to replace just the right most 200 pixels is’t as if it isn’t even
BC > BC > happening. I have verified that it IS being called.

BC > BC > What finally convinced me that it was a driver problem and not my code is
BC > BC > this: I copied the whole application onto my laptop to take it home to
BC > BC > work on. But when I got home, it worked the very first time without any
BC > BC > modification.

BC > BC > Here are the details:

BC > BC > I am running the card at 1280x1024 in 32 bit resolution.
BC > BC > My PtRaw widget takes up most of the screen, 1263x929,
BC > BC > just in case this matters.

BC > BC > Desktop at work: 2.4 GHz w/1GB RAM
BC > BC > Graphics card:
BC > BC > Class = Display (VGA)
BC > BC > Vendor ID = 1002h, ATI Technologies
BC > BC > Device ID = 4750h, Rage 3D Pro PCI Graphics Accelerator
BC > BC > PCI index = 0h
BC > BC > Class Codes = 030000h
BC > BC > Revision ID = 5ch
BC > BC > Bus number = 2
BC > BC > Device number = 7
BC > BC > Function num = 0
BC > BC > Status Reg = 280h
BC > BC > Command Reg = 86h
BC > BC > Header type = 0h Single-function
BC > BC > BIST = 0h Build-in-self-test not supported
BC > BC > Latency Timer = 40h
BC > BC > Cache Line Size= 10h un-cacheable
BC > BC > PCI Mem Address = f8000000h prefetchable 32bit length 16777216 enabled
BC > BC > PCI IO Address = e800h length 256 disabled
BC > BC > PCI Mem Address = ff8fe000h 32bit length 4096 enabled
BC > BC > Subsystem Vendor ID = 1002h
BC > BC > Subsystem ID = 80h
BC > BC > PCI Expansion ROM = 80000000h length 131072 disabled
BC > BC > Max Lat = 0ns
BC > BC > Min Gnt = 8ns
BC > BC > PCI Int Pin = INT A
BC > BC > Interrupt line = 11
BC > BC > CPU Interrupt = bh

BC > BC > pidin -Pio-graphics me says:
BC > BC > 479264 1 on/bin/io-graphics 12r RECEIVE 88K 4676K 12K(516K)*
BC > BC > 479264 2 on/bin/io-graphics 12r REPLY 88K 4676K 4096(516K)
BC > BC > 479264 3 on/bin/io-graphics 12r REPLY 88K 4676K 8192(132K)
BC > BC > ldqnx.so.2 @b0300000 344K 16K
BC > BC > libgri.so.2 @b8200000 40K 4096
BC > BC > libfont.so.1 @b820b000 40K 4096
BC > BC > libm.so.2 @b8216000 104K 8192
BC > BC > libdisputil.so.2 @b8232000 32K 8192
BC > BC > phfont.so @b823c000 124K 20K
BC > BC > tharnessutils.so.1 @b8260000 16K 4096
BC > BC > FCcore.so @b8265000 32K 8192
BC > BC > libblkcache.so.2 @b826f000 12K 4096
BC > BC > libFF-T2K-fm.so.1 @b8273000 12K 4096
BC > BC > bFF-T2K-cache.so.2 @b8277000 8192 4096
BC > BC > libFF-T2K.so.2 @b827a000 232K 12K
BC > BC > PHFcore.so @b82b7000 24K 4096
BC > BC > libfontutils.so.1 @b82be000 4096 4096
BC > BC > ttfFFcore.so @b82c0000 36K 4096
BC > BC > devg-rage.so @b82ca000 28K 4096
BC > BC > libffb.so.2 @b82d2000 44K 4096
BC > BC > gri-photon.so @b82de000 56K 8192
BC > BC > libphrender.so.2 @b82ee000 204K 8192
BC > BC > /dev/mem @40100000 ( 0) 4096
BC > BC > /dev/mem @40101000 ( 10000) 128K
BC > BC > /dev/mem @40121000 ( 0) 8192K
BC > BC > /dev/mem @40921000 (f87ff000) 4096
BC > BC > /dev/mem @40922000 ( 0) 32K
BC > BC > /dev/mem @4092a000 ( 0) 3840K

BC > BC > Mt laptop system is using an ATI Technologies (VendorD 1002),
BC > BC > Mobility M3 AGP 2x (DeviceID 4c46)
BC > BC > Driver devg-vesabios.so (The new and improved version that what’s his
BC > BC > name did). And it is running in 1024x768x32 bit mode.

BC > BC > So, whay can’t I reinitialize those right most 200 bytes but only on the
BC > BC > desktop system?

BC > BC > Is there a circumvention?

BC > BC > If it will help I can tarball up the whole application with a data file
BC > BC > and send it along. I warn you, it IS quite large.

BC > –
BC > Bill Caroselli – Q-TPS Consulting
BC > 1-(708) 308-4956 <== Note: New Number
BC > qtps@earthlink.net


Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number
qtps@earthlink.net