Skip to main content

Merging sysmem & vram

9 replies [Last post]
bitshit
Offline
Joined: 2004-04-22

Hi,

I have a situation where I want to do a hybrid of volatile image blits & sysmem image blits. The software image blits are just pixel arrays that get drawn into an bufferedimage representing the screen (framebuffer). I use this for images I'd like to do certain operations on only doable in software. Next to those images I also want to draw volatile images from vram directly (using hw accelerated operations like scaling/rotation etc); because for these images it would be nice to use that gpu power otherwise doing nothing (and freeing a bit of cpu time otherwise needed for these operations).

Now is there a way to mix this? As my framebuffer is blitted as one image, overlaps dont mix well with the vram images (i have to blit or the vram images, or the framebuffer first, and they will overlap in that order).

But ideally i'd like to have them overlap in the way they are called, i know the order that they're called in my program, so is there a way i could set certain masks to pixels in my framebuffer or something?

Thanks!

Martijn

Message was edited by: bitshit

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Michele Puccini

Maybe it could be interesting for the java2d team too. Read it as a kind-of
warning.
Looks like the new 169.21 whql NVidia drivers and above (new betas) have
some problems in dealing with the PCIe bus, making it run at 1x instead of
16x.
This problem does not affect the previous 163.75 whql driver which runs
smoothly at 16x.

Is there someone here with the same performance issue ?

my config Log (use the NV control panel, click on the "system information"
text):

--
NVIDIA System Information report created on: 01/14/2008 09:20:57
System name: MIK

[Display]
Processor: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2400 MHz)
Operating System: Microsoft Windows XP (Service Pack 2)
DirectX version: 9.0c
GPU processor: GeForce 8600 GTS
ForceWare version: 169.28
Memory: 512 MB
Video BIOS version: 60.84.41.00.00
IRQ: 16
Bus: PCI Express x1

[Components]

nvCpl.cpl 1.5.600.01 NVIDIA Control Panel Applet
nvExpBar.dll 1.5.600.01 NVIDIA Control Panel
nvCplUI.exe 1.5.600.01 NVIDIA Control Panel
nvWSS.dll 6.14.11.6928 NVIDIA Workstation Server
nvViTvS.dll 6.14.11.6928 NVIDIA Video and TV Server
nvMoblS.dll 6.14.11.6928 NVIDIA Mobile Server
NVMCTRAY.DLL 6.14.11.6928 NVIDIA Media Center Library
NVOGLNT.DLL 6.14.11.6928 NVIDIA Compatible OpenGL ICD
nvDispS.dll 6.14.11.6928 NVIDIA Display Server
NVCPL.DLL 6.14.11.6928 NVIDIA Compatible Windows 2000 Display driver,
Version 169.28
NV4_MINI.SYS 6.14.11.6928 NVIDIA Compatible Windows 2000 Miniport Driver,
Version 169.28
NV4_DISP.DLL 6.14.11.6928 NVIDIA Compatible Windows 2000 Display driver,
Version 169.28
nvGameS.dll 6.14.11.6928 NVIDIA 3D Settings Server
--

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Dmitri Trembovetski

Thanks for the info Michele. We haven't ran
any benchmarks on the new drivers.

Do you know if the issue affects opengl only or
is it generic?

Thanks,
Dmitri

Michele Puccini wrote:
> Maybe it could be interesting for the java2d team too. Read it as a
> kind-of warning.
> Looks like the new 169.21 whql NVidia drivers and above (new betas) have
> some problems in dealing with the PCIe bus, making it run at 1x instead
> of 16x.
> This problem does not affect the previous 163.75 whql driver which runs
> smoothly at 16x.
>
> Is there someone here with the same performance issue ?
>
> my config Log (use the NV control panel, click on the "system
> information" text):
>
> --
> NVIDIA System Information report created on: 01/14/2008 09:20:57
> System name: MIK
>
> [Display]
> Processor: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2400 MHz)
> Operating System: Microsoft Windows XP (Service Pack 2)
> DirectX version: 9.0c
> GPU processor: GeForce 8600 GTS
> ForceWare version: 169.28
> Memory: 512 MB
> Video BIOS version: 60.84.41.00.00
> IRQ: 16
> Bus: PCI Express x1
>
> [Components]
>
> nvCpl.cpl 1.5.600.01 NVIDIA Control Panel Applet
> nvExpBar.dll 1.5.600.01 NVIDIA Control Panel
> nvCplUI.exe 1.5.600.01 NVIDIA Control Panel
> nvWSS.dll 6.14.11.6928 NVIDIA Workstation Server
> nvViTvS.dll 6.14.11.6928 NVIDIA Video and TV Server
> nvMoblS.dll 6.14.11.6928 NVIDIA Mobile Server
> NVMCTRAY.DLL 6.14.11.6928 NVIDIA Media Center Library
> NVOGLNT.DLL 6.14.11.6928 NVIDIA Compatible OpenGL ICD
> nvDispS.dll 6.14.11.6928 NVIDIA Display Server
> NVCPL.DLL 6.14.11.6928 NVIDIA Compatible Windows 2000 Display driver,
> Version 169.28
> NV4_MINI.SYS 6.14.11.6928 NVIDIA Compatible Windows 2000 Miniport
> Driver, Version 169.28
> NV4_DISP.DLL 6.14.11.6928 NVIDIA Compatible Windows 2000 Display
> driver, Version 169.28
> nvGameS.dll 6.14.11.6928 NVIDIA 3D Settings Server

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Michele Puccini

Hi Dmitri,

I suppose that the problem with the new drivers (if confirmed) affects the
way pixels are displayed onscreen. It should have little or nothing to do
with opengl itself, but it could heavily affect the repaint speed of java
(-65% in my case).

I'll investigate further on the problem. I'll try to prepare a twin machine
with new drivers and do some test.

The test itself should be very simple: create an int argb BufferedImage (a
640x480 array based image, not volatile, not accelerated) and paint it
onscreen as fast as you can while measuring the fps.

>From a more "hardware" point of view, the PCI-Express x1, x16 issue is quite
surely an NVidia winxp driver problem. My suggestion is to always check the
speed of the board by first taking a look at the NVidia control panel System
information, (bottom left in the control panel window).

Cheers,

Mik
--

----- Original Message -----
From: "Dmitri Trembovetski"
To:
Sent: Monday, January 14, 2008 8:05 PM
Subject: Re: [JAVA2D] nvidia drivers -> pci express running at x1 instead of
16x

> Thanks for the info Michele. We haven't ran
> any benchmarks on the new drivers.
>
> Do you know if the issue affects opengl only or
> is it generic?
>
> Thanks,
> Dmitri
>
>
> Michele Puccini wrote:
>> Maybe it could be interesting for the java2d team too. Read it as a
>> kind-of warning.
>> Looks like the new 169.21 whql NVidia drivers and above (new betas) have
>> some problems in dealing with the PCIe bus, making it run at 1x instead
>> of 16x.
>> This problem does not affect the previous 163.75 whql driver which runs
>> smoothly at 16x.
>>
>> Is there someone here with the same performance issue ?
>>
>> my config Log (use the NV control panel, click on the "system
>> information" text):
>>
>> --
>> NVIDIA System Information report created on: 01/14/2008 09:20:57
>> System name: MIK
>>
>> [Display]
>> Processor: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2400 MHz)
>> Operating System: Microsoft Windows XP (Service Pack 2)
>> DirectX version: 9.0c
>> GPU processor: GeForce 8600 GTS
>> ForceWare version: 169.28
>> Memory: 512 MB
>> Video BIOS version: 60.84.41.00.00
>> IRQ: 16
>> Bus: PCI Express x1
>>
>> [Components]
>>
>> nvCpl.cpl 1.5.600.01 NVIDIA Control Panel Applet
>> nvExpBar.dll 1.5.600.01 NVIDIA Control Panel
>> nvCplUI.exe 1.5.600.01 NVIDIA Control Panel
>> nvWSS.dll 6.14.11.6928 NVIDIA Workstation Server
>> nvViTvS.dll 6.14.11.6928 NVIDIA Video and TV Server
>> nvMoblS.dll 6.14.11.6928 NVIDIA Mobile Server
>> NVMCTRAY.DLL 6.14.11.6928 NVIDIA Media Center Library
>> NVOGLNT.DLL 6.14.11.6928 NVIDIA Compatible OpenGL ICD
>> nvDispS.dll 6.14.11.6928 NVIDIA Display Server
>> NVCPL.DLL 6.14.11.6928 NVIDIA Compatible Windows 2000 Display driver,
>> Version 169.28
>> NV4_MINI.SYS 6.14.11.6928 NVIDIA Compatible Windows 2000 Miniport
>> Driver, Version 169.28
>> NV4_DISP.DLL 6.14.11.6928 NVIDIA Compatible Windows 2000 Display
>> driver, Version 169.28
>> nvGameS.dll 6.14.11.6928 NVIDIA 3D Settings Server
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the
> body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Dmitri Trembovetski

Hi,

I don't quite understand the question. Why couldn't you just
render all your images (the "sysmem" ones, which I assume are
BufferedImages) and the vram-based ones (VolatileImages or
cached BufferedImages?) to your back-buffer (which resides in
vram)?

Whatever order you draw them in is up to you - they will "appear"
in the destination image in that order.

Thanks
Dmitri

java2d@JAVADESKTOP.ORG wrote:
> Hi,
>
> I have a situation where I want to do a hybrid of vram image blits & sysmem image blits. The software image blits are just pixel arrays that get drawn into a big array representing the screen (framebuffer). I use this for images I'd like to do certain operations on only doable in software. Next to those images I also want to draw "normal" images from vram directly (using fixed function pipeline operations (scaling/rotation etc); because for these images it would be nice to use that gpu power otherwise doing nothing (and freeing a bit of cpu time otherwise needed for these operations).
>
> Now is there a way to mix this? As my framebuffer is blitted as one image, overlaps dont mix well with the vram images (i have to blit or the vram images, or the framebuffer first, and they will overlap in that order).
>
> But ideally i'd like to have them overlap in the way they are called, i know the order that they're called in my program, so is there a way i could set certain masks to pixels in my framebuffer or something?
>
> Thanks!
>
> Martijn
> [Message sent by forum member 'bitshit' (bitshit)]
>
> http://forums.java.net/jive/thread.jspa?messageID=253568
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

bitshit
Offline
Joined: 2004-04-22

Yeah well I was being a bit stupid.

I wanted to copy all my sysmem images (just plain int[]'s) to the int[] data of one big bufferedimage (the framebuffer). Obviously blitting all those sysmem images individually to vram using a bufferedimage per sysmem image would add more overhead vs one framebuffer blit. But all "overlaps" between sysmem & direct vram blits are lost that way ofcourse... So I guess there's no way around doing one bufferedimage per sysmem image.

Jim Graham

The per-pixel overhead of accessing VRAM would probably be more
noticeable than the per-operation overhead of getting the pixels into
the pipeline - unless there was a lot of overlap between the sysmem images.

With little or no overlap then it might even be faster to blit the
component sysmem images rather than a single blit of the "framebuffer"
image - depending on the difference in the number of pixels touched...

...jim

java2d@JAVADESKTOP.ORG wrote:
> Yeah well I was being a bit stupid.
>
> I wanted to copy all my sysmem images (just plain int[]'s) to the int[] data of one big bufferedimage (the framebuffer). Obviously blitting all those sysmem images individually to vram using a bufferedimage per sysmem image would add more overhead vs one framebuffer blit. But all "overlaps" between sysmem & direct vram blits are lost that way ofcourse... So I guess there's no way around doing one bufferedimage per sysmem image.
> [Message sent by forum member 'bitshit' (bitshit)]
>
> http://forums.java.net/jive/thread.jspa?messageID=253587
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

bitshit
Offline
Joined: 2004-04-22

> The per-pixel overhead of accessing VRAM would
> probably be more
> noticeable than the per-operation overhead of getting
> the pixels into
> the pipeline - unless there was a lot of overlap
> between the sysmem images.
>
> With little or no overlap then it might even be
> faster to blit the
> component sysmem images rather than a single blit of
> the "framebuffer"
> image - depending on the difference in the number of
> pixels touched...

How come overlapping sysmem images would descrease performance vs non overlapping sysmem images when doing per image blits?

Jim Graham

If VRAM is expensive to store per-pixel then the cost you pay to do the
blit(s) is dependent on the number of pixels.

If you are writing to the same VRAM pixels over and over because the
sysmem images overlap then you pay the cost to access pixels that will
later be overwritten.

By contrast if you blit all of the sysmem images to a temporary memory
buffer then the redundant writes to the same pixels will be only at the
cost of system memory access which tends to be much faster - later when
you copy the temporary buffer to the screen then you only access each
VRAM pixel once so there is no wasted or redundant effort with respect
to any overlap.

What it comes down to is comparing the number of sysmem pixels written
by each method and then comparing the costs of writing to VRAM vs.
writing to sysmem. If there is little to no overlap in the sysmem
images then the answer is a no-brainer since you will write the same or
fewer pixels to blit the sysmem images directly to the VRAM than to blit
them to a temporary sysmem buffer. If the total number of pixels in the
sysmem images is less than the number of pixels in the temporary buffer,
then again the cost of doing the blits directly to VRAM will be less
because you have fewer pixels to write (even if there is overlap). If
there is overlap and the total number of pixels in the sysmem images is
larger than the total number of pixels in the temporary buffer, then it
depends on the ratios above as to which will be faster...

...jim

java2d@JAVADESKTOP.ORG wrote:
>> The per-pixel overhead of accessing VRAM would
>> probably be more
>> noticeable than the per-operation overhead of getting
>> the pixels into
>> the pipeline - unless there was a lot of overlap
>> between the sysmem images.
>>
>> With little or no overlap then it might even be
>> faster to blit the
>> component sysmem images rather than a single blit of
>> the "framebuffer"
>> image - depending on the difference in the number of
>> pixels touched...
>
> How come overlapping sysmem images would descrease performance vs non overlapping sysmem images when doing per image blits?
> [Message sent by forum member 'bitshit' (bitshit)]
>
> http://forums.java.net/jive/thread.jspa?messageID=253855
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

bitshit
Offline
Joined: 2004-04-22

Ah yes, i thought you where referring to overlaps in the framebuffer in sysmem.

There's probably a turning point indeed, when the framebuffer in sysmem would be more efficient than individual draws directly to vram (depending on the videocard specs). Unfortunatly there doesnt seem to be a way to determine this easily from java (reading videocards capabilities or something) :(