>>As Brian pointed out, you also (will) have the option of using the new GLES implementation within Mesa itself, which can use >>the Gallium softpipe.  I don't know yet how/if that works with the Windows GDI driver.  I hope to look into that someday.
 
Is GLES support there in MESA 7.5 ??
I am not aware of that .. :O
I'll check it, how it works


On Fri, Aug 14, 2009 at 10:01 AM, Karl Schultz <karl.w.schultz@gmail.com> wrote:
That is more of a question about your wrapper.

If you have a GLES 1.1 -> OpenGL/Mesa wrapper, then you can use the wrapper to call into either the MSFT OpenGL implementation or the Mesa implementation.  The former is hardware accelerated and the latter is all software.

If you want to use a GLES 2.0 app, then you'll need a new wrapper for GLES 2.0 -> OpenGL/Mesa.  The wrapper is completely different, if even possible, and the same statement applies regarding performance.

As Brian pointed out, you also (will) have the option of using the new GLES implementation within Mesa itself, which can use the Gallium softpipe.  I don't know yet how/if that works with the Windows GDI driver.  I hope to look into that someday.

Finally, if your real goal is to develop GLES apps in the Windows environment, I believe AMD offers a GLES implementation that is hardware accelerated on Windows.  I played with it for awhile and started a port of the gears app to GLES 2.0.  I am not aware of a similar offering from nVidia, but it has been awhile since I looked.

Karl



On Thu, Aug 13, 2009 at 9:17 PM, vinit bansal <bansal.itbhu@gmail.com> wrote:
For 1.1 program, there should not be a problem. But what about any 2.0 application.. in that case i cant call OpenGL on Windows from my wrapper, right ?
My basic aim is to use 2.0 program for my application, for 1.1 i have n number of options.

On Thu, Aug 13, 2009 at 8:14 PM, Karl Schultz <karl.w.schultz@gmail.com> wrote:
No.  That would require that a driver be written for each graphics card.  Since vendors already supply OpenGL drivers on Windows, there is little incentive to repeat the work in Mesa for Windows.  I suppose that one could do it if they had the appropriate hw specs.

A couple of notes back in this thread you said that you had a wrapper for opengl-es functions, which supposedly called Mesa.  Why not just use the stock Windows OpenGL and the drivers that are appropriate for your graphics card?  IOW, why use Mesa at all for this?  Why don't you simply call OpenGL on Windows from your wrapper?


On Wed, Aug 12, 2009 at 9:08 PM, vinit bansal <bansal.itbhu@gmail.com> wrote:
Hi Karl,
Thanks for your reply.
Yes, you are right. I am using MESA on windows.
But is there a way to use h/w accelaration in MESA on windows?
 
Thanks & Regards
Vinit

On Wed, Aug 12, 2009 at 10:57 PM, Karl Schultz <karl.w.schultz@gmail.com> wrote:
Are you using the Mesa windows (gdi) driver?  It is 100% software, so performance will be slow.

Also, if you are on Windows, the standard timer is very low resolution.  If I remember right, that timer has about a 16 ms period, which may explain the values you are getting.  If you want higher resolution, then use the multimedia timer, or time things that take longer.

On Tue, Aug 11, 2009 at 10:52 PM, vinit bansal <bansal.itbhu@gmail.com> wrote:
Hi Brian,
Actually i wrote a wrapper for all opengl-es functions so that it'll call our gl fuction only.
for ex for glorthox, internally in my wrapper i'll call glotho only.
this way i m able to run my opengl-es program using MESA .. :D:D
 
My aim is , I want to know how much time my WGL calls are taking.
So i used clock function.
 
here is my code:
 
long start,end,time;
start = clock();
wglcreatecontext();
end = clock();
time = end-start;
fprintf("print this time in file");
 
same i did for wglmakecurrent/glreadpixels etc ...
prob is , i am drawing a single frame again and again still i m getting every time diff value.
 
please find my attach logs.
 
for glreadpixels:
glreadpixels : 0.000000 mSec
glreadpixels : 16.000000 mSec
glreadpixels : 16.000000 mSec
glreadpixels : 0.000000 mSec
glreadpixels : 0.000000 mSec
glreadpixels : 16.000000 mSec
glreadpixels : 0.000000 mSec
glreadpixels : 15.000000 mSec
glreadpixels : 16.000000 mSec
glreadpixels : 0.000000 mSec
glreadpixels : 0.000000 mSec
glreadpixels : 16.000000 mSec
glreadpixels : 0.000000 mSec
glreadpixels : 16.000000 mSec
glreadpixels : 0.000000 mSec
glreadpixels : 16.000000 mSec
 
for wglCreateContext and wglMakeCurrent:
wglCreateContext : 0.000000 mSec
wglMakeCurrent : 16.000000 msec
 
wglCreateContext : 0.000000 mSec
wglMakeCurrent : 16.000000 msec

wglCreateContext : 0.000000 mSec
wglMakeCurrent : 0.000000 msec
 
I dont know why this time is different in each call?
 
Best regards
Vinit


 
On Tue, Aug 11, 2009 at 8:14 PM, Brian Paul <brianp@vmware.com> wrote:
vinit bansal wrote:
Hi All,
I tried some opengl 2.0 es example using MESA.
I am able to render it properly but performance is not so good.
Is there any flag i need to enable to use optimized performance from Mesa?
 What is the meaning of performance data ?
What all it should include?

So you're using the opengl-es branch?  You're probably using the "softpipe" gallium driver.

What kind of GPU do you have?

-Brian




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Mesa3d-users mailing list
Mesa3d-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-users