Need someone to test if NBOpenGL works for you on win32

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
Hi,

i just snapshotted my stuff with various fixes, to make it load
cleanly on pharo and squeak images.

I'd like you to ask to test and load it and tell me if it works for you.

Currently it works only on win32 platform. It could work on Linux, but
i didn't had time to port it yet.

There is no automatic installation procedure right now, so here what
you should try:

- first, you need to have VM with NativeBoost plugin + NativeBoost
loaded into an image
(see http://code.google.com/p/nativeboost/wiki/Installation for instructions)


- then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL
in following order:

- NBOpenGL-Core
- NBOpenGL-Win
- NBOpenGL-TrueType
- NBOpenGL-Display
- NBOpenGL-Morphic

i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were
released recently,
and it seems works ok.
on squeak/trunk it should also work without problems.

Now, if everything went right, then we're ready to run a demo:

GLViewportMorph new "useOwnForm: true;" openInWorld

This thing should render a TrueType glyphs and animating a smooth zoom of it.
Nothing fancy, i just wanna know, if it works for you (and how well).  :)

As you may know, GPU/OpenGL implementations vary depending on vendor
and how old your hardware is,
and i don't have all of it at my disposal.

Ok.. if you got it running, and it renders the glyphs.. there's one thing left:
 - save your image and quit (without closing this morph)
 - start image

it should continue working as if nothing happens.

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Kevin-231
On Mon, 24 May 2010 09:03:24 -0500, Igor Stasenko <[hidden email]>  
wrote:

> Hi,
>
> i just snapshotted my stuff with various fixes, to make it load
> cleanly on pharo and squeak images.
>
> I'd like you to ask to test and load it and tell me if it works for you.

Beautiful!  Works exactly as you describe; I'm on an older Windows XP  
system,
2.2ghz Athlon, 512M ram, NVidia 6200 graphics card w/ 256MB.  The  
animation loop's
running fast and smooth, and doesn't seem to be giving much cpu load.

I'm using a fresh trunk image, running the VM listed in your install  
instructions.

The second line of text starts with some cyrillic-looking characters; but  
in
the Squeak system browser for GLViewportMorph>>drawOn: the string shows  
with
question marks; so I guess that thing you're doing with the truetype code  
block
might be working.

> it should continue working as if nothing happens.

Yep.  Very cool!

Kevin Kelley

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
On 24 May 2010 20:20, Kevin Kelley <[hidden email]> wrote:

> On Mon, 24 May 2010 09:03:24 -0500, Igor Stasenko <[hidden email]>
> wrote:
>
>> Hi,
>>
>> i just snapshotted my stuff with various fixes, to make it load
>> cleanly on pharo and squeak images.
>>
>> I'd like you to ask to test and load it and tell me if it works for you.
>
> Beautiful!  Works exactly as you describe; I'm on an older Windows XP
> system,
> 2.2ghz Athlon, 512M ram, NVidia 6200 graphics card w/ 256MB.  The animation
> loop's
> running fast and smooth, and doesn't seem to be giving much cpu load.
>

Well, actually it does :)
I implemented it specifically to be embedded into a squeak's Display,
so i could run it
and see what happens, without any distortion/visual artifacts and keep
working while it runs.

First, it renders everything into offscreen surface, and then it reads
results from video memory
into a display form, and then DisplayScreen + VM takes care about
blitting that form back to video memory (or anywhere else it wants).

In case if we will replace all drawing by using GL, then we won't need
to blit bits back to system memory,
and then all processing will be completely performed by GPU. It will
be much faster.

You can see how much slowdown is introduced by blitting, if you resize
the morph to cover full screen.

> I'm using a fresh trunk image, running the VM listed in your install
> instructions.
>
> The second line of text starts with some cyrillic-looking characters; but in
> the Squeak system browser for GLViewportMorph>>drawOn: the string shows with
> question marks; so I guess that thing you're doing with the truetype code
> block
> might be working.
>

Yes, it works as i described (in other thread). I subclassed
TTFontReader to support reading character maps with pId=3,
allowing you to use all glyphs of windoze fonts.

>> it should continue working as if nothing happens.
>
> Yep.  Very cool!
>
> Kevin Kelley
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
Btw, i noticed that running it full-screen in pharo is still quite
fast and smooth,
which makes me wonder, what extra a squeak image does to perform
blitting on screen.
Something slows things down there.

In both images, i used:

Display depth 32
Display isLittleEndian  true


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Levente Uzonyi-2
On Mon, 24 May 2010, Igor Stasenko wrote:

> Btw, i noticed that running it full-screen in pharo is still quite
> fast and smooth,
> which makes me wonder, what extra a squeak image does to perform
> blitting on screen.
> Something slows things down there.

Did you try the profiler (Extras menu)? I found it pretty useful when I
was hacking RFB recently.


Levente

>
> In both images, i used:
>
> Display depth 32
> Display isLittleEndian  true
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
On 24 May 2010 23:06, Levente Uzonyi <[hidden email]> wrote:

> On Mon, 24 May 2010, Igor Stasenko wrote:
>
>> Btw, i noticed that running it full-screen in pharo is still quite
>> fast and smooth,
>> which makes me wonder, what extra a squeak image does to perform
>> blitting on screen.
>> Something slows things down there.
>
> Did you try the profiler (Extras menu)? I found it pretty useful when I was
> hacking RFB recently.
>

The tally looks weird :)


 - 100146 tallies, 100419 msec.

**Tree**
--------------------------------
Process: other processes
--------------------------------
5.7% {5724ms} EventSensor>>eventTickler
  5.7% {5724ms} Delay>>wait
    5.7% {5724ms} primitives
--------------------------------
Process: (40) 43725: nil
--------------------------------
94.3% {94695ms} WorldState>>doOneCycleFor:
  94.3% {94695ms} WorldState>>doOneCycleNowFor:
    93.9% {94293ms} WorldState>>displayWorldSafely:
      93.9% {94293ms} PasteUpMorph>>displayWorld
        93.9% {94293ms} PasteUpMorph>>privateOuterDisplayWorld
          93.9% {94293ms} WorldState>>displayWorld:submorphs:
            85.6% {85959ms} WorldState>>drawWorld:submorphs:invalidAreasOn:
              |85.3% {85657ms} FormCanvas(Canvas)>>fullDrawMorph:
              |  85.3% {85657ms} FormCanvas(Canvas)>>fullDraw:
              |    85.3% {85657ms} SystemWindow(Morph)>>fullDrawOn:
              |      39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder
              |        |39.6% {39766ms} primitives
              |      34.2% {34343ms} SystemWindow(Morph)>>drawSubmorphsOn:
              |        |34.1% {34243ms} FormCanvas(Canvas)>>fullDrawMorph:
              |        |  34.1% {34243ms} FormCanvas(Canvas)>>fullDraw:
              |        |    34.1% {34243ms} GLViewportMorph(Morph)>>fullDrawOn:
              |        |      33.9% {34042ms} FormCanvas(Canvas)>>drawMorph:
              |        |        33.9% {34042ms} FormCanvas(Canvas)>>draw:
              |        |          33.9% {34042ms} GLViewportMorph>>drawOn:
              |        |            32.8% {32937ms}
NBMSAAOffscreenDisplay>>updateForm:bounds:
              |        |              32.7% {32837ms}
NBGLFrameBuffer>>bindAsDrawBuffer
              |      11.0% {11046ms} FormCanvas(Canvas)>>drawMorph:
              |        10.9% {10946ms} FormCanvas(Canvas)>>draw:
              |          10.9% {10946ms} SystemWindow(Morph)>>drawOn:
              |            10.9% {10946ms}
FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle:
              |              10.8% {10845ms}
FormCanvas>>fillRectangle:fillStyle:
              |                10.8% {10845ms}
FormCanvas>>balloonFillRectangle:fillStyle:
              |                  10.8% {10845ms}
BalloonCanvas>>fillRectangle:fillStyle:
              |                    10.8% {10845ms}
BalloonCanvas>>drawRectangle:color:borderWidth:borderColor:
              |                      10.7% {10745ms}
BalloonEngine>>drawRectangle:fill:bor...borderColor:transform:
              |                        10.7% {10745ms}
BalloonEngine>>postFlushIfNeeded
              |                          10.7% {10745ms} BalloonEngine>>copyBits
              |                            10.7% {10745ms}
BalloonEngine>>copyLoopFaster
              |                              10.7% {10745ms} primitives
            8.3% {8335ms} WorldState>>forceDamageToScreen:
              8.3% {8335ms} DisplayScreen>>forceDamageToScreen:
                8.3% {8335ms} OrderedCollection>>do:

**Leaves**
39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder
32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer
10.7% {10745ms} BalloonEngine>>copyLoopFaster
8.3% {8335ms} OrderedCollection>>do:
5.7% {5724ms} Delay>>wait

**Memory**
        old +193,508 bytes
        young +173,384 bytes
        used +366,892 bytes
        free -366,892 bytes

**GCs**
        full 0 totalling 0ms (0.0% uptime)
        incr 1331 totalling 356ms (0.0% uptime), avg 0.0ms
        tenures 2 (avg 665 GCs/tenure)
        root table 0 overflows

--------
This is weird it shows that it spends 40% of time in
SystemWindow(Morph)>>hasRolloverBorder

The actual workload should be concentrated here:
              |        |            32.8% {32937ms}
NBMSAAOffscreenDisplay>>updateForm:bounds:
              |        |              32.7% {32837ms}
NBGLFrameBuffer>>bindAsDrawBuffer

but it takes only 1/3 of all time (this is including blitting bits
back to system memory).



What is interesting, that if there is no copy to system memory,
rendering these simple things (about
60 glyphs with nice AA), takes less than 2% of time:

              |                  1.6% {689ms} GLViewportMorph>>drawOn:

while most of the time, again spent in #hasRolloverBorder
**Leaves**
61.3% {26403ms} SystemWindow(Morph)>>hasRolloverBorder
15.9% {6848ms} BalloonEngine>>copyLoopFaster
12.0% {5169ms} OrderedCollection>>do:
4.7% {2024ms} Delay>>wait

So, it could run 32%/2% ~~ 16 times faster


>
> Levente
>
>>
>> In both images, i used:
>>
>> Display depth 32
>> Display isLittleEndian  true
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Andreas.Raab
On 5/24/2010 1:28 PM, Igor Stasenko wrote:

> On 24 May 2010 23:06, Levente Uzonyi<[hidden email]>  wrote:
>> On Mon, 24 May 2010, Igor Stasenko wrote:
>>
>>> Btw, i noticed that running it full-screen in pharo is still quite
>>> fast and smooth,
>>> which makes me wonder, what extra a squeak image does to perform
>>> blitting on screen.
>>> Something slows things down there.
>>
>> Did you try the profiler (Extras menu)? I found it pretty useful when I was
>> hacking RFB recently.
>>
>
> The tally looks weird :)

http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134405.html

A real-world case of issue #3.

Cheers,
   - Andreas

>   - 100146 tallies, 100419 msec.
>
> **Tree**
> --------------------------------
> Process: other processes
> --------------------------------
> 5.7% {5724ms} EventSensor>>eventTickler
>    5.7% {5724ms} Delay>>wait
>      5.7% {5724ms} primitives
> --------------------------------
> Process: (40) 43725: nil
> --------------------------------
> 94.3% {94695ms} WorldState>>doOneCycleFor:
>    94.3% {94695ms} WorldState>>doOneCycleNowFor:
>      93.9% {94293ms} WorldState>>displayWorldSafely:
>        93.9% {94293ms} PasteUpMorph>>displayWorld
>          93.9% {94293ms} PasteUpMorph>>privateOuterDisplayWorld
>            93.9% {94293ms} WorldState>>displayWorld:submorphs:
>              85.6% {85959ms} WorldState>>drawWorld:submorphs:invalidAreasOn:
>                |85.3% {85657ms} FormCanvas(Canvas)>>fullDrawMorph:
>                |  85.3% {85657ms} FormCanvas(Canvas)>>fullDraw:
>                |    85.3% {85657ms} SystemWindow(Morph)>>fullDrawOn:
>                |      39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder
>                |        |39.6% {39766ms} primitives
>                |      34.2% {34343ms} SystemWindow(Morph)>>drawSubmorphsOn:
>                |        |34.1% {34243ms} FormCanvas(Canvas)>>fullDrawMorph:
>                |        |  34.1% {34243ms} FormCanvas(Canvas)>>fullDraw:
>                |        |    34.1% {34243ms} GLViewportMorph(Morph)>>fullDrawOn:
>                |        |      33.9% {34042ms} FormCanvas(Canvas)>>drawMorph:
>                |        |        33.9% {34042ms} FormCanvas(Canvas)>>draw:
>                |        |          33.9% {34042ms} GLViewportMorph>>drawOn:
>                |        |            32.8% {32937ms}
> NBMSAAOffscreenDisplay>>updateForm:bounds:
>                |        |              32.7% {32837ms}
> NBGLFrameBuffer>>bindAsDrawBuffer
>                |      11.0% {11046ms} FormCanvas(Canvas)>>drawMorph:
>                |        10.9% {10946ms} FormCanvas(Canvas)>>draw:
>                |          10.9% {10946ms} SystemWindow(Morph)>>drawOn:
>                |            10.9% {10946ms}
> FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle:
>                |              10.8% {10845ms}
> FormCanvas>>fillRectangle:fillStyle:
>                |                10.8% {10845ms}
> FormCanvas>>balloonFillRectangle:fillStyle:
>                |                  10.8% {10845ms}
> BalloonCanvas>>fillRectangle:fillStyle:
>                |                    10.8% {10845ms}
> BalloonCanvas>>drawRectangle:color:borderWidth:borderColor:
>                |                      10.7% {10745ms}
> BalloonEngine>>drawRectangle:fill:bor...borderColor:transform:
>                |                        10.7% {10745ms}
> BalloonEngine>>postFlushIfNeeded
>                |                          10.7% {10745ms} BalloonEngine>>copyBits
>                |                            10.7% {10745ms}
> BalloonEngine>>copyLoopFaster
>                |                              10.7% {10745ms} primitives
>              8.3% {8335ms} WorldState>>forceDamageToScreen:
>                8.3% {8335ms} DisplayScreen>>forceDamageToScreen:
>                  8.3% {8335ms} OrderedCollection>>do:
>
> **Leaves**
> 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder
> 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer
> 10.7% {10745ms} BalloonEngine>>copyLoopFaster
> 8.3% {8335ms} OrderedCollection>>do:
> 5.7% {5724ms} Delay>>wait
>
> **Memory**
> old +193,508 bytes
> young +173,384 bytes
> used +366,892 bytes
> free -366,892 bytes
>
> **GCs**
> full 0 totalling 0ms (0.0% uptime)
> incr 1331 totalling 356ms (0.0% uptime), avg 0.0ms
> tenures 2 (avg 665 GCs/tenure)
> root table 0 overflows
>
> --------
> This is weird it shows that it spends 40% of time in
> SystemWindow(Morph)>>hasRolloverBorder
>
> The actual workload should be concentrated here:
>                |        |            32.8% {32937ms}
> NBMSAAOffscreenDisplay>>updateForm:bounds:
>                |        |              32.7% {32837ms}
> NBGLFrameBuffer>>bindAsDrawBuffer
>
> but it takes only 1/3 of all time (this is including blitting bits
> back to system memory).
>
>
>
> What is interesting, that if there is no copy to system memory,
> rendering these simple things (about
> 60 glyphs with nice AA), takes less than 2% of time:
>
>                |                  1.6% {689ms} GLViewportMorph>>drawOn:
>
> while most of the time, again spent in #hasRolloverBorder
> **Leaves**
> 61.3% {26403ms} SystemWindow(Morph)>>hasRolloverBorder
> 15.9% {6848ms} BalloonEngine>>copyLoopFaster
> 12.0% {5169ms} OrderedCollection>>do:
> 4.7% {2024ms} Delay>>wait
>
> So, it could run 32%/2% ~~ 16 times faster
>
>
>>
>> Levente
>>
>>>
>>> In both images, i used:
>>>
>>> Display depth 32
>>> Display isLittleEndian  true
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>>
>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
In reply to this post by Igor Stasenko
For GLViewportMorph, it takes ~ 9ms to render a frame + blit results
to system memory:

| canv |
canv := Display getCanvas.
[ 1000 timesRepeat: [ self drawOn: canv ] ] timeToRun

9714

if i disabling blitting to system memory, then the above loop takes
789 ms
 < 1 ms per frame

Drawing a system window morph with 600@400 extent (an outer morph ,
which is a little bit bigger than GLViewportMorph which sits inside of
it):
4327

~ 4ms per frame
(its just fills the rectangle with constant color)

For the same window on pharo it takes just 1393 ms.

Scaling a system window (along with GLViewportMorph) to 1200@800

GLViewportMorph + blit to system memory  - 24611 ms
GLViewportMorph w/o blit to system memory  - 754  ms
SystemWindow -  12351

so, with increase of drawable area by 4x factor,
rendering times not changes.
blitting to  system memory is 2.5 slower
and drawing a rectangle is 4x slower - a worst result showing an exact
linear dependency from covered area.


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
In reply to this post by Andreas.Raab
On 25 May 2010 00:18, Andreas Raab <[hidden email]> wrote:

> On 5/24/2010 1:28 PM, Igor Stasenko wrote:
>>
>> On 24 May 2010 23:06, Levente Uzonyi<[hidden email]>  wrote:
>>>
>>> On Mon, 24 May 2010, Igor Stasenko wrote:
>>>
>>>> Btw, i noticed that running it full-screen in pharo is still quite
>>>> fast and smooth,
>>>> which makes me wonder, what extra a squeak image does to perform
>>>> blitting on screen.
>>>> Something slows things down there.
>>>
>>> Did you try the profiler (Extras menu)? I found it pretty useful when I
>>> was
>>> hacking RFB recently.
>>>
>>
>> The tally looks weird :)
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134405.html
>
> A real-world case of issue #3.
>

Oh, i see.
So this is actually a time spent to draw a systemwindow background.

Btw, i discovered that openGL driver distributes the load over all 4
cores of my pc.



> Cheers,
>  - Andreas
>
>>  - 100146 tallies, 100419 msec.
>>
>> **Tree**
>> --------------------------------
>> Process: other processes
>> --------------------------------
>> 5.7% {5724ms} EventSensor>>eventTickler
>>   5.7% {5724ms} Delay>>wait
>>     5.7% {5724ms} primitives
>> --------------------------------
>> Process: (40) 43725: nil
>> --------------------------------
>> 94.3% {94695ms} WorldState>>doOneCycleFor:
>>   94.3% {94695ms} WorldState>>doOneCycleNowFor:
>>     93.9% {94293ms} WorldState>>displayWorldSafely:
>>       93.9% {94293ms} PasteUpMorph>>displayWorld
>>         93.9% {94293ms} PasteUpMorph>>privateOuterDisplayWorld
>>           93.9% {94293ms} WorldState>>displayWorld:submorphs:
>>             85.6% {85959ms}
>> WorldState>>drawWorld:submorphs:invalidAreasOn:
>>               |85.3% {85657ms} FormCanvas(Canvas)>>fullDrawMorph:
>>               |  85.3% {85657ms} FormCanvas(Canvas)>>fullDraw:
>>               |    85.3% {85657ms} SystemWindow(Morph)>>fullDrawOn:
>>               |      39.6% {39766ms}
>> SystemWindow(Morph)>>hasRolloverBorder
>>               |        |39.6% {39766ms} primitives
>>               |      34.2% {34343ms} SystemWindow(Morph)>>drawSubmorphsOn:
>>               |        |34.1% {34243ms} FormCanvas(Canvas)>>fullDrawMorph:
>>               |        |  34.1% {34243ms} FormCanvas(Canvas)>>fullDraw:
>>               |        |    34.1% {34243ms}
>> GLViewportMorph(Morph)>>fullDrawOn:
>>               |        |      33.9% {34042ms}
>> FormCanvas(Canvas)>>drawMorph:
>>               |        |        33.9% {34042ms} FormCanvas(Canvas)>>draw:
>>               |        |          33.9% {34042ms} GLViewportMorph>>drawOn:
>>               |        |            32.8% {32937ms}
>> NBMSAAOffscreenDisplay>>updateForm:bounds:
>>               |        |              32.7% {32837ms}
>> NBGLFrameBuffer>>bindAsDrawBuffer
>>               |      11.0% {11046ms} FormCanvas(Canvas)>>drawMorph:
>>               |        10.9% {10946ms} FormCanvas(Canvas)>>draw:
>>               |          10.9% {10946ms} SystemWindow(Morph)>>drawOn:
>>               |            10.9% {10946ms}
>> FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle:
>>               |              10.8% {10845ms}
>> FormCanvas>>fillRectangle:fillStyle:
>>               |                10.8% {10845ms}
>> FormCanvas>>balloonFillRectangle:fillStyle:
>>               |                  10.8% {10845ms}
>> BalloonCanvas>>fillRectangle:fillStyle:
>>               |                    10.8% {10845ms}
>> BalloonCanvas>>drawRectangle:color:borderWidth:borderColor:
>>               |                      10.7% {10745ms}
>> BalloonEngine>>drawRectangle:fill:bor...borderColor:transform:
>>               |                        10.7% {10745ms}
>> BalloonEngine>>postFlushIfNeeded
>>               |                          10.7% {10745ms}
>> BalloonEngine>>copyBits
>>               |                            10.7% {10745ms}
>> BalloonEngine>>copyLoopFaster
>>               |                              10.7% {10745ms} primitives
>>             8.3% {8335ms} WorldState>>forceDamageToScreen:
>>               8.3% {8335ms} DisplayScreen>>forceDamageToScreen:
>>                 8.3% {8335ms} OrderedCollection>>do:
>>  **Leaves**
>> 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder
>> 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer
>> 10.7% {10745ms} BalloonEngine>>copyLoopFaster
>> 8.3% {8335ms} OrderedCollection>>do:
>> 5.7% {5724ms} Delay>>wait
>>
>> **Memory**
>>        old                     +193,508 bytes
>>        young           +173,384 bytes
>>        used            +366,892 bytes
>>        free            -366,892 bytes
>>
>> **GCs**
>>        full                    0 totalling 0ms (0.0% uptime)
>>        incr            1331 totalling 356ms (0.0% uptime), avg 0.0ms
>>        tenures         2 (avg 665 GCs/tenure)
>>        root table      0 overflows
>>
>> --------
>> This is weird it shows that it spends 40% of time in
>> SystemWindow(Morph)>>hasRolloverBorder
>>
>> The actual workload should be concentrated here:
>>               |        |            32.8% {32937ms}
>> NBMSAAOffscreenDisplay>>updateForm:bounds:
>>               |        |              32.7% {32837ms}
>> NBGLFrameBuffer>>bindAsDrawBuffer
>>
>> but it takes only 1/3 of all time (this is including blitting bits
>> back to system memory).
>>
>>
>>
>> What is interesting, that if there is no copy to system memory,
>> rendering these simple things (about
>> 60 glyphs with nice AA), takes less than 2% of time:
>>
>>               |                  1.6% {689ms} GLViewportMorph>>drawOn:
>>
>> while most of the time, again spent in #hasRolloverBorder
>> **Leaves**
>> 61.3% {26403ms} SystemWindow(Morph)>>hasRolloverBorder
>> 15.9% {6848ms} BalloonEngine>>copyLoopFaster
>> 12.0% {5169ms} OrderedCollection>>do:
>> 4.7% {2024ms} Delay>>wait
>>
>> So, it could run 32%/2% ~~ 16 times faster
>>
>>
>>>
>>> Levente
>>>
>>>>
>>>> In both images, i used:
>>>>
>>>> Display depth 32
>>>> Display isLittleEndian  true
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Kevin-231
In reply to this post by Igor Stasenko
On Mon, 24 May 2010 13:07:20 -0500, Igor Stasenko <[hidden email]>  
wrote:
> On 24 May 2010 20:20, Kevin Kelley <[hidden email]> wrote:
>>
>>>  The animation loop's
>> running fast and smooth, and doesn't seem to be giving much cpu load.
>>
>
> Well, actually it does :)

Okay, so the memcopy's are taking up a little bit of time; still, the big  
win
so far is having the gpu render the font glyph based on just the outline  
data,
you're getting scalable fonts on the fly effectively for free.  This is  
seriously
cool.

That GPU gems link (  
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html )
referenced in your code is a good explanation.  Shaders kind of break my  
brain,
I'm glad to see this one in and working.

Cheers,
Kevin Kelley

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
On 25 May 2010 02:13, Kevin Kelley <[hidden email]> wrote:

> On Mon, 24 May 2010 13:07:20 -0500, Igor Stasenko <[hidden email]>
> wrote:
>>
>> On 24 May 2010 20:20, Kevin Kelley <[hidden email]> wrote:
>>>
>>>>  The animation loop's
>>>
>>> running fast and smooth, and doesn't seem to be giving much cpu load.
>>>
>>
>> Well, actually it does :)
>
> Okay, so the memcopy's are taking up a little bit of time; still, the big
> win
> so far is having the gpu render the font glyph based on just the outline
> data,
> you're getting scalable fonts on the fly effectively for free.  This is
> seriously
> cool.
>
> That GPU gems link (
> http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html )
> referenced in your code is a good explanation.  Shaders kind of break my
> brain,
> I'm glad to see this one in and working.
>
Every hardware is quite stupid and primitive thing. Once you got the basics,
the rest is just a piece of cake.
Btw, this is my first shader routine i ever written :)

> Cheers,
> Kevin Kelley
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Andreas.Raab
In reply to this post by Igor Stasenko
On 5/24/2010 7:03 AM, Igor Stasenko wrote:
> - first, you need to have VM with NativeBoost plugin + NativeBoost
> loaded into an image
> (see http://code.google.com/p/nativeboost/wiki/Installation for instructions)

The page doesn't have any information on how to download the binary
plugin. Do I really need to rebuild it from sources?

> - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL
> in following order:
>
> - NBOpenGL-Core
> - NBOpenGL-Win

This fails with the following error:

--------------------------------------------------------------

This package depends on the following classes:
   NBWinTypes
   NBWinConstants
You must resolve these dependencies before you will be able to load
these definitions:
   GLPixelFormatDescriptor
   ....
--------------------------------------------------------------

> i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were
> released recently, and it seems works ok.
> on squeak/trunk it should also work without problems.

I've used 4.1 but I don't think this should matter for the above, no?

> Now, if everything went right, then we're ready to run a demo:
>
> GLViewportMorph new "useOwnForm: true;" openInWorld

And ultimately this fails too due to GLPixelFormatDescriptor not loaded.

Any ideas what's wrong with NBWinTypes and NBWinConstants?

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
On 25 May 2010 03:47, Andreas Raab <[hidden email]> wrote:

> On 5/24/2010 7:03 AM, Igor Stasenko wrote:
>>
>> - first, you need to have VM with NativeBoost plugin + NativeBoost
>> loaded into an image
>> (see http://code.google.com/p/nativeboost/wiki/Installation for
>> instructions)
>
> The page doesn't have any information on how to download the binary plugin.
> Do I really need to rebuild it from sources?
>

You can just take a prebuilt VM from
http://code.google.com/p/nativeboost/downloads/list

>> - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL
>> in following order:
>>
>> - NBOpenGL-Core
>> - NBOpenGL-Win
>
> This fails with the following error:
>
> --------------------------------------------------------------
>
> This package depends on the following classes:
>  NBWinTypes
>  NBWinConstants
> You must resolve these dependencies before you will be able to load these
> definitions:
>  GLPixelFormatDescriptor
>  ....
> --------------------------------------------------------------
>
>> i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were
>> released recently, and it seems works ok.
>> on squeak/trunk it should also work without problems.
>
> I've used 4.1 but I don't think this should matter for the above, no?
>
Yes, i  developped it in 4.1 . So, it should work at least there :)

>> Now, if everything went right, then we're ready to run a demo:
>>
>> GLViewportMorph new "useOwnForm: true;" openInWorld
>
> And ultimately this fails too due to GLPixelFormatDescriptor not loaded.
>
> Any ideas what's wrong with NBWinTypes and NBWinConstants?
>

You need to install a NativeBoost first.
NBOpenGL is separate thing which using a NativeBoost.

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Andreas.Raab
On 5/24/2010 6:17 PM, Igor Stasenko wrote:
> You can just take a prebuilt VM from
> http://code.google.com/p/nativeboost/downloads/list

Okay, good, that's what I did. FWIW, there's an installation bug for NB.
When you run "NBInstaller install" *without* the plugin, it will fail to
determine the platform id and will not install the Windows stuff. That's
what caused my later problems. I would recommend installing *all*
platform examples regardless of actual platform id to avoid issues like
these. I find Unix examples just as instructive as Windows examples ;-)

However, even after doing that, it fails to run. It blows up in
NBGLFrameBuffer>>checkStatus which needs to use "self CLASS bindingOf:
sym" to resolve the code. When I fix that it gets me to an
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT and that's where I'm at right now.
In case it helps, the offending code is in

NBMSAAOffscreenDisplay>>initDisplay
        "perform a usual initializations"
        renderFBO := NBGLFrameBuffer new initialize: self gl extent: extent.
        renderFBO createMultisampleAttachments: 4.
        renderFBO checkStatus.
        "... more stuff ..."

Any ideas what to look for? I have an ATI Mobility Radeon HD 4330
running Windows 7.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
On 25 May 2010 05:57, Andreas Raab <[hidden email]> wrote:

> On 5/24/2010 6:17 PM, Igor Stasenko wrote:
>>
>> You can just take a prebuilt VM from
>> http://code.google.com/p/nativeboost/downloads/list
>
> Okay, good, that's what I did. FWIW, there's an installation bug for NB.
> When you run "NBInstaller install" *without* the plugin, it will fail to
> determine the platform id and will not install the Windows stuff. That's
> what caused my later problems. I would recommend installing *all* platform
> examples regardless of actual platform id to avoid issues like these. I find
> Unix examples just as instructive as Windows examples ;-)
>
Oh give it a time :)

> However, even after doing that, it fails to run. It blows up in
> NBGLFrameBuffer>>checkStatus which needs to use "self CLASS bindingOf: sym"
> to resolve the code.

Thanks for finding it! I never run into that code, that's why it
wasn't tested. :)

> When I fix that it gets me to an
> GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT and that's where I'm at right now. In
> case it helps, the offending code is in
>
> NBMSAAOffscreenDisplay>>initDisplay
>        "perform a usual initializations"
>        renderFBO := NBGLFrameBuffer new initialize: self gl extent: extent.
>        renderFBO createMultisampleAttachments: 4.
>        renderFBO checkStatus.
>        "... more stuff ..."
>
> Any ideas what to look for? I have an ATI Mobility Radeon HD 4330 running
> Windows 7.
>

It either your card doesn't supports MSAA,
or driver don't likes the FBO configuration which i provided.

Check that

NBWinContextState new pixelFormatInfo extensions includes:
#GL_EXT_packed_depth_stencil

i suspect this is your problem, because you're unlucky owner of wrong
hardware/drivers :)
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=234085

Also, you could try running with MSAA turned off, go to
NBGLDisplay class>>pickImplementation
 and put comment around " ^ NBMSAAOffscreenDisplay  "


> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Andreas.Raab
On 5/24/2010 8:32 PM, Igor Stasenko wrote:
> It either your card doesn't supports MSAA,
> or driver don't likes the FBO configuration which i provided.

I think the error code indicates a problem with the FBO configuration.
For example, check out the restrictions on OpenGL ES for this stuff:

http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml

It seems as if one needs to be very picky for getting the 'right'
configuration on all platforms. Is there an enumeration by any chance
that allows one to pick the proper (supported) configuration?

> Check that
>
> NBWinContextState new pixelFormatInfo extensions includes:
> #GL_EXT_packed_depth_stencil

It's there.

> Also, you could try running with MSAA turned off, go to
> NBGLDisplay class>>pickImplementation
>   and put comment around " ^ NBMSAAOffscreenDisplay  "

That appears to work but the glyphs are drawn "improperly" (see
screenshot). I'm not sure if that's the way they're intended to be
rendered or if that's an artifact of running a different configuration.

Cheers,
   - Andreas



NBRender.jpg (65K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
On 25 May 2010 07:22, Andreas Raab <[hidden email]> wrote:

> On 5/24/2010 8:32 PM, Igor Stasenko wrote:
>>
>> It either your card doesn't supports MSAA,
>> or driver don't likes the FBO configuration which i provided.
>
> I think the error code indicates a problem with the FBO configuration. For
> example, check out the restrictions on OpenGL ES for this stuff:
>
> http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml
>
> It seems as if one needs to be very picky for getting the 'right'
> configuration on all platforms. Is there an enumeration by any chance that
> allows one to pick the proper (supported) configuration?
>
Yeah.. this is a black voodoo.
For instance, my video card rejects FBO with color+stencil only
(that's all what i need).
You may try various things in
NBGLFrameBuffer>>createMultisampleAttachments: numSamples
or in NBGLFrameBuffer>>createAttachments

>> Check that
>>
>> NBWinContextState new pixelFormatInfo extensions includes:
>> #GL_EXT_packed_depth_stencil
>
> It's there.
>
>> Also, you could try running with MSAA turned off, go to
>> NBGLDisplay class>>pickImplementation
>>  and put comment around " ^ NBMSAAOffscreenDisplay  "
>
> That appears to work but the glyphs are drawn "improperly" (see screenshot).
> I'm not sure if that's the way they're intended to be rendered or if that's
> an artifact of running a different configuration.
>
Yes, its improper. It looks like that when you don't have a stencil
buffer (or have it disabled).
Your screenshot also shows that you got my little shader running
properly which is used to render quad beziers.
And this is more important than stencil (i think it could be solved by
picking different FBO attachment formats).


> Cheers,
>  - Andreas
>


--
Best regards,
Igor Stasenko AKA sig.



GL viewport.png (39K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Josh Gargus
It works fine for me (Geforce 8800GTS).

Maybe Andreas needs updated drivers?  That's helped some people with similar problems:
http://www.gamedev.net/community/forums/topic.asp?topic_id=568410

Your GPU is way newer than in the following post, but maybe try power-of-two window dimensions:
http://forums.amd.com/devforum/messageview.cfm?catid=392&threadid=115093&enterthread=y

Cheers,
Josh



On May 24, 2010, at 9:48 PM, Igor Stasenko wrote:

> On 25 May 2010 07:22, Andreas Raab <[hidden email]> wrote:
>> On 5/24/2010 8:32 PM, Igor Stasenko wrote:
>>>
>>> It either your card doesn't supports MSAA,
>>> or driver don't likes the FBO configuration which i provided.
>>
>> I think the error code indicates a problem with the FBO configuration. For
>> example, check out the restrictions on OpenGL ES for this stuff:
>>
>> http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml
>>
>> It seems as if one needs to be very picky for getting the 'right'
>> configuration on all platforms. Is there an enumeration by any chance that
>> allows one to pick the proper (supported) configuration?
>>
> Yeah.. this is a black voodoo.
> For instance, my video card rejects FBO with color+stencil only
> (that's all what i need).
> You may try various things in
> NBGLFrameBuffer>>createMultisampleAttachments: numSamples
> or in NBGLFrameBuffer>>createAttachments
>
>>> Check that
>>>
>>> NBWinContextState new pixelFormatInfo extensions includes:
>>> #GL_EXT_packed_depth_stencil
>>
>> It's there.
>>
>>> Also, you could try running with MSAA turned off, go to
>>> NBGLDisplay class>>pickImplementation
>>>  and put comment around " ^ NBMSAAOffscreenDisplay  "
>>
>> That appears to work but the glyphs are drawn "improperly" (see screenshot).
>> I'm not sure if that's the way they're intended to be rendered or if that's
>> an artifact of running a different configuration.
>>
>
> Yes, its improper. It looks like that when you don't have a stencil
> buffer (or have it disabled).
> Your screenshot also shows that you got my little shader running
> properly which is used to render quad beziers.
> And this is more important than stencil (i think it could be solved by
> picking different FBO attachment formats).
>
>
>> Cheers,
>>  - Andreas
>>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
> <GL viewport.png>


Reply | Threaded
Open this post in threaded view
|

Re: Need someone to test if NBOpenGL works for you on win32

Igor Stasenko
On 29 May 2010 09:41, Josh Gargus <[hidden email]> wrote:
> It works fine for me (Geforce 8800GTS).
>
> Maybe Andreas needs updated drivers?  That's helped some people with similar problems:
> http://www.gamedev.net/community/forums/topic.asp?topic_id=568410
>
> Your GPU is way newer than in the following post, but maybe try power-of-two window dimensions:
> http://forums.amd.com/devforum/messageview.cfm?catid=392&threadid=115093&enterthread=y
>
Yes, its a long-standing problem with ATI drivers (i hope not with cards).
Henrik also reported that it unable to create MSAA FBO on his Radeopn HD4870.

I wonder if ATI cards/drivers ever support depth+stencil multisampling in FBOs.
Actually, i could use back buffer for rendering instead of FBO.


> Cheers,
> Josh
>
>
>
> On May 24, 2010, at 9:48 PM, Igor Stasenko wrote:
>
>> On 25 May 2010 07:22, Andreas Raab <[hidden email]> wrote:
>>> On 5/24/2010 8:32 PM, Igor Stasenko wrote:
>>>>
>>>> It either your card doesn't supports MSAA,
>>>> or driver don't likes the FBO configuration which i provided.
>>>
>>> I think the error code indicates a problem with the FBO configuration. For
>>> example, check out the restrictions on OpenGL ES for this stuff:
>>>
>>> http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml
>>>
>>> It seems as if one needs to be very picky for getting the 'right'
>>> configuration on all platforms. Is there an enumeration by any chance that
>>> allows one to pick the proper (supported) configuration?
>>>
>> Yeah.. this is a black voodoo.
>> For instance, my video card rejects FBO with color+stencil only
>> (that's all what i need).
>> You may try various things in
>> NBGLFrameBuffer>>createMultisampleAttachments: numSamples
>> or in NBGLFrameBuffer>>createAttachments
>>
>>>> Check that
>>>>
>>>> NBWinContextState new pixelFormatInfo extensions includes:
>>>> #GL_EXT_packed_depth_stencil
>>>
>>> It's there.
>>>
>>>> Also, you could try running with MSAA turned off, go to
>>>> NBGLDisplay class>>pickImplementation
>>>>  and put comment around " ^ NBMSAAOffscreenDisplay  "
>>>
>>> That appears to work but the glyphs are drawn "improperly" (see screenshot).
>>> I'm not sure if that's the way they're intended to be rendered or if that's
>>> an artifact of running a different configuration.
>>>
>>
>> Yes, its improper. It looks like that when you don't have a stencil
>> buffer (or have it disabled).
>> Your screenshot also shows that you got my little shader running
>> properly which is used to render quad beziers.
>> And this is more important than stencil (i think it could be solved by
>> picking different FBO attachment formats).
>>
>>
>>> Cheers,
>>>  - Andreas
>>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>> <GL viewport.png>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.