Menu
▾
▴
mesa3d-users
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
(11) |
Apr
(46) |
May
(65) |
Jun
(85) |
Jul
(94) |
Aug
(99) |
Sep
(62) |
Oct
(58) |
Nov
(85) |
Dec
(39) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(90) |
Feb
(29) |
Mar
(90) |
Apr
(96) |
May
(78) |
Jun
(58) |
Jul
(44) |
Aug
(65) |
Sep
(40) |
Oct
(38) |
Nov
(79) |
Dec
(63) |
| 2002 |
Jan
(53) |
Feb
(61) |
Mar
(43) |
Apr
(53) |
May
(35) |
Jun
(59) |
Jul
(18) |
Aug
(12) |
Sep
(28) |
Oct
(61) |
Nov
(54) |
Dec
(23) |
| 2003 |
Jan
(16) |
Feb
(42) |
Mar
(38) |
Apr
(35) |
May
(20) |
Jun
(9) |
Jul
(10) |
Aug
(30) |
Sep
(22) |
Oct
(32) |
Nov
(25) |
Dec
(21) |
| 2004 |
Jan
(39) |
Feb
(36) |
Mar
(59) |
Apr
(32) |
May
(21) |
Jun
(4) |
Jul
(8) |
Aug
(21) |
Sep
(11) |
Oct
(21) |
Nov
(22) |
Dec
(19) |
| 2005 |
Jan
(62) |
Feb
(24) |
Mar
(17) |
Apr
(16) |
May
(16) |
Jun
(17) |
Jul
(26) |
Aug
(14) |
Sep
(13) |
Oct
(8) |
Nov
(23) |
Dec
(20) |
| 2006 |
Jan
(41) |
Feb
(18) |
Mar
(21) |
Apr
(47) |
May
(13) |
Jun
(33) |
Jul
(32) |
Aug
(21) |
Sep
(27) |
Oct
(34) |
Nov
(19) |
Dec
(46) |
| 2007 |
Jan
(21) |
Feb
(26) |
Mar
(13) |
Apr
(22) |
May
(5) |
Jun
(19) |
Jul
(56) |
Aug
(43) |
Sep
(37) |
Oct
(31) |
Nov
(53) |
Dec
(22) |
| 2008 |
Jan
(74) |
Feb
(31) |
Mar
(15) |
Apr
(35) |
May
(23) |
Jun
(26) |
Jul
(17) |
Aug
(27) |
Sep
(35) |
Oct
(30) |
Nov
(29) |
Dec
(17) |
| 2009 |
Jan
(35) |
Feb
(39) |
Mar
(44) |
Apr
(28) |
May
(20) |
Jun
(28) |
Jul
(49) |
Aug
(53) |
Sep
(23) |
Oct
(13) |
Nov
(12) |
Dec
(11) |
| 2010 |
Jan
(45) |
Feb
(28) |
Mar
(41) |
Apr
(11) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nicholas L. <Nic...@gm...> - 2009-08-17 12:51:23
|
I'm attempting to develop off-screen rendering using OpenVG but am having trouble (I'm new to the whole graphics universe...surfaces, contexts, windows, oy!). Off-screen rendering means a PBuffer but I can only bind a VGImage to a Pbuffer. So what about VGPaths? I can render a blue triangle on-screen and now I'm trying to render ultimately to a ppm file. Therefore I need to know the location of the data, but all I have is the EGLDisplay, EGLSurface (a Pbuffer, right?) and EGLContext. There's no opportunity for me to malloc some memory and use it. The only thing I can think to maybe try is draw my VGPath to presumably the surface, then call either vgReadPixels to add it to memory and then create a ppm file. Does that make sense? -- View this message in context: http://www.nabble.com/Is-Off-screen-rendering-possible-with-EGL-and-OpenVG--tp24977640p24977640.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: Brian P. <br...@vm...> - 2009-08-14 14:20:18
|
The Mesa GLES code is still on a separate openg-es branch in git. I'm
planning tomerge it to master for the 7.6 release.
-Brian
vinit bansal wrote:
> >>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 <kar...@gm...
> <mailto:kar...@gm...>> 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
> <ban...@gm... <mailto:ban...@gm...>> 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
> <kar...@gm... <mailto:kar...@gm...>> 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
> <ban...@gm... <mailto:ban...@gm...>> 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
> <kar...@gm...
> <mailto:kar...@gm...>> 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
> <ban...@gm...
> <mailto:ban...@gm...>> 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
> <br...@vm... <mailto:br...@vm...>>
> 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
> Mes...@li...
> <mailto:Mes...@li...>
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>
>
>
>
>
>
>
|
|
From: vinit b. <ban...@gm...> - 2009-08-14 05:33:09
|
>>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 <kar...@gm...>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 <ban...@gm...>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 <kar...@gm...
>> > 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 <ban...@gm...>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 <
>>>> kar...@gm...> 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 <
>>>>> ban...@gm...> 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 <br...@vm...>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
>>>>>> Mes...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Karl S. <kar...@gm...> - 2009-08-14 04:31:45
|
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 <ban...@gm...>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 <kar...@gm...>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 <ban...@gm...>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 <
>>> kar...@gm...> 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 <
>>>> ban...@gm...> 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 <br...@vm...> 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
>>>>> Mes...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: tom f. <tf...@al...> - 2009-08-14 04:16:04
|
vinit bansal <ban...@gm...> writes: > 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 ? You just need to load the functions you need at runtime via wglGetProcAddress. That's a pain though. I recommend GLEW (glew.sf.net). Cheers, -tom > On Thu, Aug 13, 2009 at 8:14 PM, Karl Schultz <kar...@gm...>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 <ban...@gm...>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 < > >> kar...@gm...> 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 expla > in > >>> 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 <ban...@gm... > >>> > 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 <br...@vm...> 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 > >>>> Mes...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users > >>>> > >>>> > >>> > >> > > > > --000e0cd2e59655151b0471117e7e > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > <div>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 ? </div> > <div>My basic aim is to use 2.0 program for my application, for 1.1 i have = > n number of options.<br><br></div> > <div class=3D"gmail_quote">On Thu, Aug 13, 2009 at 8:14 PM, Karl Schultz <s= > pan dir=3D"ltr"><<a href=3D"mailto:kar...@gm...">karl.w.schu= > lt...@gm...</a>></span> wrote:<br> > <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= > px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">No.=A0 That would require that a= > driver be written for each graphics card.=A0 Since vendors already supply = > OpenGL drivers on Windows, there is little incentive to repeat the work in = > Mesa for Windows.=A0 I suppose that one could do it if they had the appropr= > iate hw specs.<br> > <br>A couple of notes back in this thread you said that you had a wrapper f= > or opengl-es functions, which supposedly called Mesa.=A0 Why not just use t= > he stock Windows OpenGL and the drivers that are appropriate for your graph= > ics card?=A0 IOW, why use Mesa at all for this?=A0 Why don't you simply= > call OpenGL on Windows from your wrapper?=20 > <div> > <div></div> > <div class=3D"h5"><br><br> > <div class=3D"gmail_quote">On Wed, Aug 12, 2009 at 9:08 PM, vinit bansal <s= > pan dir=3D"ltr"><<a href=3D"mailto:ban...@gm..." target=3D"_bl= > ank">ban...@gm...</a>></span> wrote:<br> > <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0= > pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> > <div>Hi Karl,</div> > <div>Thanks for your reply.</div> > <div>Yes, you are right. I am using MESA on windows.</div> > <div>But is there a way to use h/w accelaration in MESA on windows?</div> > <div>=A0</div> > <div>Thanks & Regards</div> > <div>Vinit<font color=3D"#888888"><br><br></font></div> > <div> > <div></div> > <div> > <div class=3D"gmail_quote">On Wed, Aug 12, 2009 at 10:57 PM, Karl Schultz <= > span dir=3D"ltr"><<a href=3D"mailto:kar...@gm..." target=3D"= > _blank">kar...@gm...</a>></span> wrote:<br> > <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= > px 0px 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Are you using the Me= > sa windows (gdi) driver?=A0 It is 100% software, so performance will be slo= > w.<br> > <br>Also, if you are on Windows, the standard timer is very low resolution.= > =A0 If I remember right, that timer has about a 16 ms period, which may exp= > lain the values you are getting.=A0 If you want higher resolution, then use= > the multimedia timer, or time things that take longer.<br> > <br> > <div class=3D"gmail_quote"> > <div> > <div></div> > <div>On Tue, Aug 11, 2009 at 10:52 PM, vinit bansal <span dir=3D"ltr"><<= > a href=3D"mailto:ban...@gm..." target=3D"_blank">bansal.itbhu@gma= > il.com</a>></span> wrote:<br></div></div> > <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0= > pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> > <div> > <div></div> > <div> > <div>Hi Brian,</div> > <div>Actually i wrote a wrapper for all opengl-es functions so that it'= > ll call our gl fuction only.</div> > <div>for ex for glorthox, internally in my wrapper i'll call glotho onl= > y.</div> > <div>this way i m able to run my opengl-es program using MESA .. :D:D</div> > <div>=A0</div> > <div>My aim is , I want to know how much time my WGL calls are taking.</div= > > > <div>So i used clock function.</div> > <div>=A0</div> > <div>here is my code:</div> > <div>=A0</div> > <div>long start,end,time;</div> > <div>start =3D clock();</div> > <div>wglcreatecontext();</div> > <div>end =3D clock();</div> > <div>time =3D end-start;</div> > <div>fprintf("print this time in file");</div> > <div>=A0</div> > <div>same i did for wglmakecurrent/glreadpixels etc ...</div> > <div>prob is , i am drawing a single frame again and again still i m gettin= > g every time diff value.</div> > <div>=A0</div> > <div>please find my attach logs.</div> > <div>=A0</div> > <div>for <b>glreadpixels:</b></div> > <div><b>glreadpixels : 0.000000 mSec</b></div> > <div><b>glreadpixels : 16.000000 mSec</b></div> > <div><b>glreadpixels : 16.000000 mSec</b></div> > <div><b>glreadpixels : 0.000000 mSec</b></div> > <div><b>glreadpixels : 0.000000 mSec</b></div> > <div><b>glreadpixels : 16.000000 mSec</b></div> > <div><b>glreadpixels : 0.000000 mSec</b></div> > <div><b>glreadpixels : 15.000000 mSec</b></div> > <div><b>glreadpixels : 16.000000 mSec</b></div> > <div><b>glreadpixels : 0.000000 mSec</b></div> > <div><b>glreadpixels : 0.000000 mSec</b></div> > <div><b>glreadpixels : 16.000000 mSec</b></div> > <div><b>glreadpixels : 0.000000 mSec</b></div> > <div><b>glreadpixels : 16.000000 mSec</b></div> > <div><b>glreadpixels : 0.000000 mSec</b></div> > <div><b>glreadpixels : 16.000000 mSec<br></b></div> > <div>=A0</div> > <div>for <b>wglCreateContext and wglMakeCurrent:</b></div> > <div><b>wglCreateContext : 0.000000 mSec<br>wglMakeCurrent : 16.000000 msec= > </b></div> > <div><b></b>=A0</div> > <div><b>wglCreateContext : 0.000000 mSec<br>wglMakeCurrent : 16.000000 msec= > </b></div> > <div><br><b>wglCreateContext : 0.000000 mSec<br>wglMakeCurrent : 0.000000 m= > sec</b></div> > <div><b></b>=A0</div> > <div>I dont know why this time is different in each call?</div> > <div><b></b>=A0</div> > <div><b>Best regards</b></div> > <div><b>Vinit</b></div> > <div> > <div></div> > <div> > <div><br><br>=A0</div> > <div class=3D"gmail_quote">On Tue, Aug 11, 2009 at 8:14 PM, Brian Paul <spa= > n dir=3D"ltr"><<a href=3D"mailto:br...@vm..." target=3D"_blank">br= > ia...@vm...</a>></span> wrote:<br> > <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= > px 0px 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid"> > <div>vinit bansal wrote:<br> > <blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0= > px 0px 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Hi All,<br>I tried s= > ome opengl 2.0 es example using MESA.<br>I am able to render it properly bu= > t performance is not so good.<br> > Is there any flag i need to enable to use optimized performance from Mesa?<= > br>=A0What is the meaning of performance data ?<br>What all it should inclu= > de?<br></blockquote><br></div>So you're using the opengl-es branch? =A0= > You're probably using the "softpipe" gallium driver.<br> > <br>What kind of GPU do you have?<br><font color=3D"#888888"><br>-Brian<br>= > <br><br></font></blockquote></div><br></div></div><br></div></div>---------= > ---------------------------------------------------------------------<br> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day= > <br>trial. Simplify your report design, integration and deployment - and fo= > cus on<br>what you do best, core application coding. Discover what's ne= > w with<br> > Crystal Reports now. =A0<a href=3D"http://p.sf.net/sfu/bobj-july" target=3D= > "_blank">http://p.sf.net/sfu/bobj-july</a><br>_____________________________= > __________________<br>Mesa3d-users mailing list<br><a href=3D"mailto:Mesa3d= > -u...@li..." target=3D"_blank">Mes...@li...urcefo= > rge.net</a><br> > <a href=3D"https://lists.sourceforge.net/lists/listinfo/mesa3d-users" targe= > t=3D"_blank">https://lists.sourceforge.net/lists/listinfo/mesa3d-users</a><= > br><br></blockquote></div><br></blockquote></div><br></div></div></blockquo= > te> > </div><br></div></div></blockquote></div><br> > > --000e0cd2e59655151b0471117e7e-- > > > --===============8036142131938267590== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > ----------------------------------------------------------------------------- > - > 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 > --===============8036142131938267590== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > > --===============8036142131938267590==-- > |
|
From: vinit b. <ban...@gm...> - 2009-08-14 03:24:56
|
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 <kar...@gm...>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 <ban...@gm...>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 <
>> kar...@gm...> 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 <ban...@gm...
>>> > 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 <br...@vm...> 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
>>>> Mes...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>>>
>>>>
>>>
>>
>
|
|
From: Karl S. <kar...@gm...> - 2009-08-13 14:44:25
|
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 <ban...@gm...>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 <kar...@gm...>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 <ban...@gm...>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 <br...@vm...> 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
>>> Mes...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>>
>>>
>>
>
|
|
From: Gabriel Z. <gab...@gm...> - 2009-08-13 14:09:21
|
Hi,
here is my simplified directfb+mesa example which i tested on arm based
board and it worked without any problems. If your directfb/mesa is compiled
OK you shouldn't have any problems running it as well. Its simply just a red
triangle rotating in front of white background forever.. I compiled it like
this:
arm-linux-g++ -I/usr/local/arm/include -I/usr/local/arm/include/directfb
-L/usr/local/arm/lib -lGL -lGLU -ldirectfb -lfusion -ldirect -o test
./test.cxx
the standard directfb output was this:
#
./test
~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.4.0
|~~~~~~~~~~~~~~~~~~~~~~~~~~
(c) 2001-2009 The world wide DirectFB Open Source
Community
(c) 2000-2004 Convergence (integrated media)
GmbH
----------------------------------------------------------------
(*) DirectFB/Core: Multi Application Core.
(2009-07-17_08:03)
(*) Direct/Memcpy: Using
armasm_memcpy()
(*) Fusion/Init: Builtin Implementation is still experimental!
Crash/Deadlocks might occur!
(*) Fusion/SHM: Using MADV_REMOVE (2.6.29.0 >=
2.6.19.2)
(*) Direct/Thread: Started 'Fusion Dispatch' (562) [MESSAGING OTHER/OTHER
0/0] <8388608>...
(*) Direct/Thread: Started 'VT Switcher' (565) [CRITICAL OTHER/OTHER 0/0]
<8388608>...
(*) Direct/Thread: Started 'VT Flusher' (-1) [DEFAULT OTHER/OTHER 0/0]
<8388608>...
(*) DirectFB/FBDev: Found 's3c2410fb' (ID 0) with frame buffer at
0x33900000, 150k (MMIO 0x00000000, 0k)
(*) DirectFB/Graphics: Generic Software Rasterizer 0.6 (directfb.org)
(*) DirectFB/Core/WM: Default 0.3 (directfb.org)
(*) FBDev/Mode: Setting 240x320
RGB16
(*) FBDev/Mode: Switched to 240x320 (virtual 240x320) at 16 bit (RGB16),
pitch 480
(*) FBDev/Surface: Allocated 240x320 16 bit RGB16 buffer (index 0) at offset
0 and pitch 480.
(*) FBDev/Mode: Setting 240x320
RGB16
(*) FBDev/Mode: Switched to 240x320 (virtual 240x320) at 16 bit (RGB16),
pitch 480
(*) FBDev/Surface: Allocated 240x320 16 bit RGB16 buffer (index 0) at offset
0 and pitch 480.
(*) Direct/Interface: Loaded 'Mesa' implementation of 'IDirectFBGL'.
and finally the source of the test follows:
test.cxx
-------------------------------------------------------------------------------------------------------------------------------
/*
directfb/mesa test example
Written by Gabriel Zabusek <gabriel.zabusek_at_gmail.com>
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the
Free Software Foundation, Inc., 59 Temple Place - Suite 330,
Boston, MA 02111-1307, USA.
*/
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <math.h>
#include <unistd.h>
#include <GL/gl.h>
#include <GL/glu.h>
#include <directfb.h>
#include <directfbgl.h>
#include <iostream>
#include <sstream>
#include <string>
using namespace std;
IDirectFB *dfb;
IDirectFBSurface *primary;
IDirectFBGL *primary_gl;
#define DFBCHECK(x...) \
{ \
err =
x; \
if (err != DFB_OK)
{ \
fprintf( stderr, "%s <%d>:\n\t", __FILE__, __LINE__
); \
DirectFBErrorFatal( #x, err
); \
} \
}
static int screen_width, screen_height;
void InitGL(void)
{
glClearColor(0.f, 0.f, 0.f, 0.f);
glClearDepth(1.0);
glDepthFunc(GL_LESS);
glEnable(GL_DEPTH_TEST);
glShadeModel(GL_FLAT);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(45.0f,(GLfloat)screen_width/(GLfloat)screen_height,0.1f,100.0f);
// Calculate The Aspect Ratio Of The Window
glMatrixMode(GL_MODELVIEW);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
}
unsigned int angle_troj = 0;
unsigned int angle_spce = 0;
unsigned int angle_stvo = 0;
void DrawGLScene()
{
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glLoadIdentity();
glPushMatrix();
glTranslatef(-1.5f,0.0f,-10.0f);
angle_troj+=2;
angle_stvo+=4;
glPushMatrix();
glRotatef(angle_troj, 0.f,1.f,0.f);
// draw a triangle
glBegin(GL_POLYGON);
glColor3f(1.f,0.f,0.f);
glVertex3f( 0.0f, 1.0f, 0.0f);
glColor3f(0.f,1.f,0.f);
glVertex3f( 1.0f,-1.0f, 0.0f);
glColor3f(0.f,0.f,1.f);
glVertex3f(-1.0f,-1.0f, 0.0f);
glEnd();
glPopMatrix();
glFlush();
glPopMatrix();
}
int main( int argc, char *argv[] )
{
int quit = 0;
DFBResult err;
DFBSurfaceDescription dsc;
DFBCHECK(DirectFBInit( &argc, &argv ));
DFBCHECK(DirectFBCreate( &dfb ));
dfb->SetCooperativeLevel( dfb, DFSCL_FULLSCREEN );
dsc.flags = DSDESC_CAPS;
dsc.caps = (DFBSurfaceCapabilities)(DSCAPS_PRIMARY | DSCAPS_DOUBLE);
DFBCHECK(dfb->CreateSurface( dfb, &dsc, &primary ));
DFBCHECK(primary->GetSize( primary, &screen_width, &screen_height ));
DFBCHECK(primary->FillRectangle( primary, 0, 0, screen_width,
screen_height ));
primary->Flip( primary, NULL, (DFBSurfaceFlipFlags)0 );
DFBCHECK(primary->GetGL( primary, &primary_gl ));
DFBCHECK(primary_gl->Lock( primary_gl ));
//init GL
InitGL();
DFBCHECK(primary_gl->Unlock( primary_gl ));
while (1) {
DFBCHECK(primary_gl->Lock( primary_gl ));
//draw stuff
DrawGLScene();
DFBCHECK(primary_gl->Unlock( primary_gl ));
primary->Flip( primary, NULL, (DFBSurfaceFlipFlags)0 );
}
primary_gl->Release( primary_gl );
primary->Release( primary );
dfb->Release( dfb );
return 0;
}
Hope this helps you solve your issue!
Have a nice day,
Gabriel Zabusek
On Thu, Aug 13, 2009 at 2:54 PM, Christophe Khamly <wet...@gm...>wrote:
> Hi,
>
> I compiled mesa using directfb under sh4 architechture for my Set-top-box.
> The compilation was completed successfuly. But I tried to run a demo like
> gears, unfortunately nothing is displaying on the screen.
> The directfb layer works fine, I can blit a gif on my TV screen through
> HDMI connection.
> So maybe someone knows where the problem come from?
> Might be caused by swapbuffers?
>
> Thanks for your answers
>
> --
> Christophe KHAMLY
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>
>
--
..............................................................................................................................................
"...the finding of new proofs for known truths is often at least as
important as the discovery itself..."
|
|
From: Christophe K. <wet...@gm...> - 2009-08-13 12:54:37
|
Hi, I compiled mesa using directfb under sh4 architechture for my Set-top-box. The compilation was completed successfuly. But I tried to run a demo like gears, unfortunately nothing is displaying on the screen. The directfb layer works fine, I can blit a gif on my TV screen through HDMI connection. So maybe someone knows where the problem come from? Might be caused by swapbuffers? Thanks for your answers -- Christophe KHAMLY |
|
From: vinit b. <ban...@gm...> - 2009-08-13 03:08:28
|
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 <kar...@gm...>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 <ban...@gm...>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 <br...@vm...> 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
>> Mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>
>>
>
|
|
From: Viral P. <Vir...@an...> - 2009-08-12 18:11:19
|
That does look like you are hitting the timer resolution threshold. You
might want to try:
QueryPerformanceFrequency
QueryPerformanceCounter
For high resolution timing.
Something like:
inline __int64 currentTime()
{
LARGE_INTEGER li;
QueryPerformanceCounter(&li);
return li.QuadPart;
}
inline __int64 counterFreq()
{
LARGE_INTEGER li;
QueryPerformanceFrequency(&li);
return li.QuadPart;
}
const __int64 start = currentTime();
... STUFF
const __int64 totalTime = currentTime() - start;
if (time == 0)
return 0;
double msec = double(time) / double(counterFreq()) * 1000.0;
From: Karl Schultz [mailto:kar...@gm...]
Sent: 12 August 2009 18:27
To: vinit bansal
Cc: mes...@li...
Subject: Re: [Mesa3d-users] Regarding Performance in Mesa
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 <ban...@gm...>
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 <br...@vm...> 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
Mes...@li...
https://lists.sourceforge.net/lists/listinfo/mesa3d-users
|
|
From: Karl S. <kar...@gm...> - 2009-08-12 17:27:31
|
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 <ban...@gm...>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 <br...@vm...> 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
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>
>
|
|
From: Nicolas C. <nic...@ym...> - 2009-08-12 15:07:10
|
To use the function intelSwapBuffers, I change the function called by dri2SwapBuffers with (*pdraw->psc->core->swapBuffers)(pdraw->driDrawable);.
Now, I can use the function intelSwapBuffers but in the function intelCopyBuffer (intel_blit.c), I have a segmentation fault when it does dst = intel_get_rb_region(&intel_fb->Base, BUFFER_FRONT_LEFT);
intel_get_rb_region(&intel_fb->Base, BUFFER_FRONT_LEFT) returns an irb->region = NULL.
My question is : Why the irb->region is NULL and How to do to have a correct irb->region ?
Thanks, Nicolas
De : Nicolas Cadio <nic...@ym...>
À : mes...@li...; mes...@li...
Envoyé le : Mercredi, 12 Août 2009, 15h00mn 10s
Objet : [Mesa3d-users] How to use the intelSwapBuffers function ?
Hi all,
I'm working with the intel chipset.
I want to use the function glXSwapBuffers with a vertical synchronisation.
But when I call glXSwapBuffers, glXSwapBuffers call the function dri2SwapBuffers which is in the file ...\mesa-7.4.0-1\src\mesa\src\glx\x11\dri2_glx.c. But, I want to use the function intelSwapBuffers (...\mesa-7.4.0-1\src\mesa\src\mesa\drivers\dri\intel\intel_swapbuffers.c).
So I think that glXSwapBuffers must call the function driSwapBuffers (...\mesa-7.4.0-1\src\mesa\src\glx\x11\dri_glx.c). And I think that driSwapBuffers of the dri_glx.c file call the function driSwapBuffers which is in the file ...\mesa-7.4.0-1\src\mesa\src\mesa\drivers\dri\common\dri_util.c. And to finish this function driSwapBuffers of dri_util.c call the function intelSwapBuffers.
is it right ?
If yes, how to do to use the function driSwapBuffers instead dri2SwapBuffers in glXSwapBuffers ?
Else , somebody can explain me how to use the function glXSwapBuffers with a vertical synchronisation ?
Thanks, nicolas
|
|
From: Chia-I Wu <ol...@gm...> - 2009-08-12 14:25:04
|
On Wed, Aug 12, 2009 at 05:43:02PM +0530, vinit bansal wrote: > I have little doubt. > How EGL and OpenGL are binded together? > I mean is, before making any gl calls , i have created eglsurface,eglcontext > etc... > After that i'll call lots of openGL functions. > Why openGL is rendering into that egl surface? > where is the binding of openGL and EGL happening? libEGL.so may call functions in libGL.so, which are not part of OpenGL API. For example, when you call eglCreateWindowSurface to create an EGLSurface, libEGL.so might in turn call st_create_framebuffer in libGL.so to create the real surface. Because of this, you can not take libEGL.so from vendor A and take libGL.so from vendor B, and expect them to work together. -- Regards, olv |
|
From: Nicolas C. <nic...@ym...> - 2009-08-12 13:00:20
|
Hi all,
I'm working with the intel chipset.
I want to use the function glXSwapBuffers with a vertical synchronisation.
But when I call glXSwapBuffers, glXSwapBuffers call the function dri2SwapBuffers which is in the file ...\mesa-7.4.0-1\src\mesa\src\glx\x11\dri2_glx.c. But, I want to use the function intelSwapBuffers (...\mesa-7.4.0-1\src\mesa\src\mesa\drivers\dri\intel\intel_swapbuffers.c).
So I think that glXSwapBuffers must call the function driSwapBuffers (...\mesa-7.4.0-1\src\mesa\src\glx\x11\dri_glx.c). And I think that driSwapBuffers of the dri_glx.c file call the function driSwapBuffers which is in the file ...\mesa-7.4.0-1\src\mesa\src\mesa\drivers\dri\common\dri_util.c. And to finish this function driSwapBuffers of dri_util.c call the function intelSwapBuffers.
is it right ?
If yes, how to do to use the function driSwapBuffers instead dri2SwapBuffers in glXSwapBuffers ?
Else , somebody can explain me how to use the function glXSwapBuffers with a vertical synchronisation ?
Thanks, nicolas
|
|
From: vinit b. <ban...@gm...> - 2009-08-12 12:43:09
|
Hi All, I have little doubt. How EGL and OpenGL are binded together? I mean is, before making any gl calls , i have created eglsurface,eglcontext etc... After that i'll call lots of openGL functions. Why openGL is rendering into that egl surface? where is the binding of openGL and EGL happening? Correct me if i m wrong somewhere. Thanks & Regards Vinit |
|
From: vinit b. <ban...@gm...> - 2009-08-12 04:52:56
|
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 <br...@vm...> 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
>
>
>
|
|
From: Brian P. <br...@vm...> - 2009-08-11 14:45:04
|
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 |
|
From: Gabriel Z. <gab...@gm...> - 2009-08-11 10:01:04
|
Hi again, i checked out the scripts and i am slowly remembering what the problem was :). It is actually not and issue with the ASM flags. When mesa is compiling it is using the mklib script and i remember changing it. Now in the makefile i changed this line LIBS = $(TOP)/src/mesa/libmesa.a $(TOP)/src/mesa/libglapi.a if i remember correctly both libmesa.a and libglapi.a are made with mklib and thats where the problem was. I needed it working quickly so i did it the dirty way :) simply by replacing the aforementioned line with this: LIBS = \ ../../main/api_arrayelt.o \ ../../main/api_exec.o \ ../../main/api_loopback.o \ ../../main/api_noop.o \ ../../main/api_validate.o \ ../../main/accum.o \ ../../main/attrib.o \ ../../main/arrayobj.o \ ../../main/blend.o \ ../../main/bufferobj.o \ ../../main/buffers.o \ ../../main/clear.o \ ../../main/clip.o \ ../../main/colortab.o \ ../../main/context.o \ ../../main/convolve.o \ ../../main/debug.o \ ../../main/depth.o \ ../../main/depthstencil.o \ ../../main/dlist.o \ ../../main/dlopen.o \ ../../main/drawpix.o \ ../../main/enable.o \ ../../main/enums.o \ ../../main/eval.o \ ../../main/execmem.o \ ../../main/extensions.o \ ../../main/fbobject.o \ ../../main/feedback.o \ ../../main/ffvertex_prog.o \ ../../main/fog.o \ ../../main/framebuffer.o \ ../../main/get.o \ ../../main/getstring.o \ ../../main/hash.o \ ../../main/hint.o \ ../../main/histogram.o \ ../../main/image.o \ ../../main/imports.o \ ../../main/light.o \ ../../main/lines.o \ ../../main/matrix.o \ ../../main/mipmap.o \ ../../main/mm.o \ ../../main/multisample.o \ ../../main/pixel.o \ ../../main/pixelstore.o \ ../../main/points.o \ ../../main/polygon.o \ ../../main/queryobj.o \ ../../main/rastpos.o \ ../../main/rbadaptors.o \ ../../main/readpix.o \ ../../main/renderbuffer.o \ ../../main/scissor.o \ ../../main/shaders.o \ ../../main/state.o \ ../../main/stencil.o \ ../../main/texcompress.o \ ../../main/texcompress_s3tc.o \ ../../main/texcompress_fxt1.o \ ../../main/texenv.o \ ../../main/texenvprogram.o \ ../../main/texformat.o \ ../../main/texgen.o \ ../../main/teximage.o \ ../../main/texobj.o \ ../../main/texparam.o \ ../../main/texrender.o \ ../../main/texstate.o \ ../../main/texstore.o \ ../../main/varray.o \ ../../main/vtxfmt.o \ ../../math/m_debug_clip.o \ ../../math/m_debug_norm.o \ ../../math/m_debug_xform.o \ ../../math/m_eval.o \ ../../math/m_matrix.o \ ../../math/m_translate.o \ ../../math/m_vector.o \ ../../math/m_xform.o \ ../../vbo/vbo_context.o \ ../../vbo/vbo_exec.o \ ../../vbo/vbo_exec_api.o \ ../../vbo/vbo_exec_array.o \ ../../vbo/vbo_exec_draw.o \ ../../vbo/vbo_exec_eval.o \ ../../vbo/vbo_rebase.o \ ../../vbo/vbo_split.o \ ../../vbo/vbo_split_copy.o \ ../../vbo/vbo_split_inplace.o \ ../../vbo/vbo_save.o \ ../../vbo/vbo_save_api.o \ ../../vbo/vbo_save_draw.o \ ../../vbo/vbo_save_loopback.o \ ../../tnl/t_context.o \ ../../tnl/t_pipeline.o \ ../../tnl/t_draw.o \ ../../tnl/t_rasterpos.o \ ../../tnl/t_vb_program.o \ ../../tnl/t_vb_render.o \ ../../tnl/t_vb_texgen.o \ ../../tnl/t_vb_texmat.o \ ../../tnl/t_vb_vertex.o \ ../../tnl/t_vb_cull.o \ ../../tnl/t_vb_fog.o \ ../../tnl/t_vb_light.o \ ../../tnl/t_vb_normals.o \ ../../tnl/t_vb_points.o \ ../../tnl/t_vp_build.o \ ../../tnl/t_vertex.o \ ../../tnl/t_vertex_sse.o \ ../../tnl/t_vertex_generic.o \ ../../shader/arbprogparse.o \ ../../shader/arbprogram.o \ ../../shader/atifragshader.o \ ../../shader/grammar/grammar_mesa.o \ ../../shader/nvfragparse.o \ ../../shader/nvprogram.o \ ../../shader/nvvertparse.o \ ../../shader/program.o \ ../../shader/prog_cache.o \ ../../shader/prog_debug.o \ ../../shader/prog_execute.o \ ../../shader/prog_instruction.o \ ../../shader/prog_noise.o \ ../../shader/prog_parameter.o \ ../../shader/prog_print.o \ ../../shader/prog_statevars.o \ ../../shader/prog_uniform.o \ ../../shader/programopt.o \ ../../shader/shader_api.o \ ../../swrast/s_aaline.o \ ../../swrast/s_aatriangle.o \ ../../swrast/s_accum.o \ ../../swrast/s_alpha.o \ ../../swrast/s_atifragshader.o \ ../../swrast/s_bitmap.o \ ../../swrast/s_blend.o \ ../../swrast/s_blit.o \ ../../swrast/s_buffers.o \ ../../swrast/s_copypix.o \ ../../swrast/s_context.o \ ../../swrast/s_depth.o \ ../../swrast/s_drawpix.o \ ../../swrast/s_feedback.o \ ../../swrast/s_fog.o \ ../../swrast/s_fragprog.o \ ../../swrast/s_imaging.o \ ../../swrast/s_lines.o \ ../../swrast/s_logic.o \ ../../swrast/s_masking.o \ ../../swrast/s_points.o \ ../../swrast/s_readpix.o \ ../../swrast/s_span.o \ ../../swrast/s_stencil.o \ ../../swrast/s_texcombine.o \ ../../swrast/s_texfilter.o \ ../../swrast/s_texstore.o \ ../../swrast/s_triangle.o \ ../../swrast/s_zoom.o \ ../../swrast_setup/ss_context.o \ ../../swrast_setup/ss_triangle.o \ ../../drivers/common/driverfuncs.o \ ../../x86/common_x86.o \ ../../x86/x86.o \ ../../x86/3dnow.o \ ../../x86/sse.o \ ../../x86/rtasm/x86sse.o \ ../../sparc/sparc.o \ ../../ppc/common_ppc.o \ ../../x86-64/x86-64.o \ ../../shader/slang/slang_builtin.o \ ../../shader/slang/slang_codegen.o \ ../../shader/slang/slang_compile.o \ ../../shader/slang/slang_compile_function.o \ ../../shader/slang/slang_compile_operation.o \ ../../shader/slang/slang_compile_struct.o \ ../../shader/slang/slang_compile_variable.o \ ../../shader/slang/slang_emit.o \ ../../shader/slang/slang_ir.o \ ../../shader/slang/slang_label.o \ ../../shader/slang/slang_link.o \ ../../shader/slang/slang_log.o \ ../../shader/slang/slang_mem.o \ ../../shader/slang/slang_preprocess.o \ ../../shader/slang/slang_print.o \ ../../shader/slang/slang_simplify.o \ ../../shader/slang/slang_storage.o \ ../../shader/slang/slang_typeinfo.o \ ../../shader/slang/slang_vartable.o \ ../../shader/slang/slang_utility.o \ ../../main/dispatch.o \ ../../glapi/glapi.o \ ../../glapi/glapi_getproc.o \ ../../glapi/glthread.o all the objects are build correctly so this solved the linking issue to check whether this is the problem try objdumping the libmesa.a and libglapi.a libs - if they dont contain the symbols than that should be your issue as well. I changed these files to get mine version working: sources/Mesa-7.4.4/configs/default sources/Mesa-7.4.4/configs/linux-directfb Mesa-7.4.4/bin/mklib Mesa-7.4.4/src/mesa/drivers/directfb/Makefile <-- this is where the change i mentioned is Let me know if it wont solve the isssue. Your libGL definatelly doesnt look good. Here is greped glBegin part of mine: arm-linux-objdump -T /usr/local/arm/lib/libGL.so | grep glBegin 002024b4 g DF .text 00000058 Base glBeginQuery 001fadcc g DF .text 00000044 Base glBeginFragmentShaderATI 0021221c g DF .text 00000050 Base glBegin 0020245c g DF .text 00000058 Base glBeginQueryARB as you see the symbol glBegin is properly defined. Regards, Gabriel Zabusek On Tue, Aug 11, 2009 at 11:44 AM, Christophe Khamly <wet...@gm...>wrote: > Hi Gabriel! > > Thanks to reply so quickly I didn't expect to get an answer as fast as > yours! > Well, I will be very interesseted for testing your version. > According to my sh4-linux-objdump, I have no symbols related to the > functions needed for running the demos: > > g600219@osnp1263321f:~/target/root/Mesa-7.5/lib$ sh4-linux-objdump -t > libGL.so.7.5.0 > > libGL.so.7.5.0: file format elf32-sh-linux > > SYMBOL TABLE: > 000000b4 l d .gnu.hash 00000000 .gnu.hash > 000000f0 l d .dynsym 00000000 .dynsym > 00000180 l d .dynstr 00000000 .dynstr > 00000210 l d .gnu.version 00000000 .gnu.version > 00000224 l d .gnu.version_r 00000000 .gnu.version_r > 00000244 l d .rela.dyn 00000000 .rela.dyn > 00000274 l d .rela.plt 00000000 .rela.plt > 00000280 l d .init 00000000 .init > 000002e4 l d .plt 00000000 .plt > 00000320 l d .text 00000000 .text > 00000440 l d .fini 00000000 .fini > 00000478 l d .eh_frame 00000000 .eh_frame > 0001047c l d .ctors 00000000 .ctors > 00010484 l d .dtors 00000000 .dtors > 0001048c l d .jcr 00000000 .jcr > 00010490 l d .dynamic 00000000 .dynamic > 00010570 l d .data 00000000 .data > 00010578 l d .got 00000000 .got > 00010590 l d .bss 00000000 .bss > 00000000 l d .comment 00000000 .comment > 00000000 l df *ABS* 00000000 initfini.c > 00000000 l df *ABS* 00000000 crtstuff.c > 0001047c l O .ctors 00000000 __CTOR_LIST__ > 00010484 l O .dtors 00000000 __DTOR_LIST__ > 0001048c l O .jcr 00000000 __JCR_LIST__ > 00000320 l F .text 00000000 __do_global_dtors_aux > 00010590 l O .bss 00000001 completed.5793 > 00010574 l O .data 00000000 p.5791 > 000003a0 l F .text 00000000 frame_dummy > 00000000 l df *ABS* 00000000 crtstuff.c > 00010480 l O .ctors 00000000 __CTOR_END__ > 00010488 l O .dtors 00000000 __DTOR_END__ > 00000478 l O .eh_frame 00000000 __FRAME_END__ > 0001048c l O .jcr 00000000 __JCR_END__ > 000003e0 l F .text 00000000 __do_global_ctors_aux > 00000000 l df *ABS* 00000000 initfini.c > 00010578 l O *ABS* 00000000 .hidden _GLOBAL_OFFSET_TABLE_ > 00010570 l O .data 00000000 .hidden __dso_handle > 00010490 l O *ABS* 00000000 .hidden _DYNAMIC > 00000420 w F .text 00000000 __gmon_start__ > 00000000 w *UND* 00000000 _Jv_RegisterClasses > 00000440 g F .fini 00000000 _fini > 00000000 w F *UND* 000000d0 __cxa_finalize@@GLIBC_2.2 > 00010590 g *ABS* 00000000 __bss_start > 00010594 g *ABS* 00000000 _end > 00010590 g *ABS* 00000000 _edata > 00000280 g F .init 00000000 _init > > Also I tried to search into the folder to find the functions It seemed that > everything is done in asm for X86. > For directfb, my lib works perfectly I modifed the lower layer to fit with > my STB blitter driver. > How can you send me that? > Thanks again for your help. > > > > On Tue, Aug 11, 2009 at 11:19 AM, Gabriel Zabusek < > gab...@gm...> wrote: > >> Hi Christophe, >> >> I have successfully compiled both directfb + mesa-7.4.4 for my arm board >> (also without GPU and FPU). I actually also managed to get the OpenGLES >> wrapper (dgles) running which you might be interested in. I remember i had >> similar problem to yours however i did quite a lot of changes and dont >> remember exactly which one solved this particular issue. I wrote several >> shell scripts what build everything automatically for me (my arm-linux >> board) and everything seemed to work perfectly (i did a bit of testing - >> gears and other demos were working perfectly). Changing it to the sh4-linux >> should be very easy (probably only a matter of changing arm-linux-gcc to >> sh4-linux-gcc) so if you want i can try to do that for you and send it. I am >> not certain if i should send it to the mailing list or rather share it on >> rapidshare or something like that. >> >> Also before that you might want to objdump the library if it really >> doesn't define (*UND*) the symbols - you can do that with sh4-linux-objdumb >> -t libGL.so or sh4-linux-objdump -T ... >> >> Let me know if you are interested. >> >> Regards, >> Gabriel Zabusek >> >> On Tue, Aug 11, 2009 at 10:48 AM, Christophe Khamly <wet...@gm...>wrote: >> >>> Hi all, >>> >>> I'm trying to compile Mesa-7.5 for a SetTopBox. >>> It's a SH4 architechture for STLinux-2.3 and It will use directfb for >>> rendering (my STB has no GPU). >>> I modified the current configuration in configs/linux-directfb for doing >>> some cross-compiling and disabling the X86_source_asm compilation. >>> The compilation worked fine but after that when I wanted to compile a >>> demo in progs/demos I got this: >>> >>> root@wet:~/Mesa-7.5/progs/demos# sh4-linux-gcc -I../../include -Wall -O3 >>> -ffast-math -fPIC -std=c99 -D_GNU_SOURCE -D_POSIX_SOURCE -D_SVID_SOURCE >>> -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -DPTHREADS -fno-strict-aliasing >>> gears.c readtex.o -Xlinker -rpath /usr/X11R7/lib -L../../lib -lglut -lGLEW >>> -lGLU -lGL -L../../lib -lGL -lGLU -lglut -o gears >>> /tmp/ccTkyHLx.o: In function `gear': >>> gears.c:(.text+0x208): undefined reference to `glShadeModel' >>> gears.c:(.text+0x224): undefined reference to `glNormal3f' >>> gears.c:(.text+0x230): undefined reference to `glBegin' >>> gears.c:(.text+0x250): undefined reference to `glVertex3f' >>> gears.c:(.text+0x254): undefined reference to `glVertex3f' >>> gears.c:(.text+0x258): undefined reference to `glEnd' >>> gears.c:(.text+0x25c): undefined reference to `glBegin' >>> gears.c:(.text+0x47c): undefined reference to `glVertex3f' >>> gears.c:(.text+0x48c): undefined reference to `glVertex3f' >>> gears.c:(.text+0x498): undefined reference to `glVertex3f' >>> gears.c:(.text+0x4a4): undefined reference to `glVertex3f' >>> gears.c:(.text+0x4a8): undefined reference to `glEnd' >>> gears.c:(.text+0x4ac): undefined reference to `glNormal3f' >>> gears.c:(.text+0x4b8): undefined reference to `glBegin' >>> gears.c:(.text+0x6f0): undefined reference to `glVertex3f' >>> gears.c:(.text+0x6f4): undefined reference to `glVertex3f' >>> gears.c:(.text+0x6f8): undefined reference to `glEnd' >>> gears.c:(.text+0x6fc): undefined reference to `glBegin' >>> ......and so on >>> >>> I have all the libs needed by this compilation. >>> So It seems that the problem might be caused by disabling the X86_ASM >>> flags, which contains these symbols. >>> How I can solve this problem? is there a generic code in C replacing the >>> X86_ASM? >>> >>> Thanks for your answers. >>> >>> -- >>> Christophe KHAMLY >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> Mes...@li... >>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >>> >>> >> >> >> -- >> >> .............................................................................................................................................. >> >> "...the finding of new proofs for known truths is often at least as >> important as the discovery itself..." >> >> > > > -- > Christophe KHAMLY > > -- .............................................................................................................................................. "...the finding of new proofs for known truths is often at least as important as the discovery itself..." |
|
From: Gabriel Z. <gab...@gm...> - 2009-08-11 09:22:28
|
Hi Christophe, I have successfully compiled both directfb + mesa-7.4.4 for my arm board (also without GPU and FPU). I actually also managed to get the OpenGLES wrapper (dgles) running which you might be interested in. I remember i had similar problem to yours however i did quite a lot of changes and dont remember exactly which one solved this particular issue. I wrote several shell scripts what build everything automatically for me (my arm-linux board) and everything seemed to work perfectly (i did a bit of testing - gears and other demos were working perfectly). Changing it to the sh4-linux should be very easy (probably only a matter of changing arm-linux-gcc to sh4-linux-gcc) so if you want i can try to do that for you and send it. I am not certain if i should send it to the mailing list or rather share it on rapidshare or something like that. Also before that you might want to objdump the library if it really doesn't define (*UND*) the symbols - you can do that with sh4-linux-objdumb -t libGL.so or sh4-linux-objdump -T ... Let me know if you are interested. Regards, Gabriel Zabusek On Tue, Aug 11, 2009 at 10:48 AM, Christophe Khamly <wet...@gm...>wrote: > Hi all, > > I'm trying to compile Mesa-7.5 for a SetTopBox. > It's a SH4 architechture for STLinux-2.3 and It will use directfb for > rendering (my STB has no GPU). > I modified the current configuration in configs/linux-directfb for doing > some cross-compiling and disabling the X86_source_asm compilation. > The compilation worked fine but after that when I wanted to compile a demo > in progs/demos I got this: > > root@wet:~/Mesa-7.5/progs/demos# sh4-linux-gcc -I../../include -Wall -O3 > -ffast-math -fPIC -std=c99 -D_GNU_SOURCE -D_POSIX_SOURCE -D_SVID_SOURCE > -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -DPTHREADS -fno-strict-aliasing > gears.c readtex.o -Xlinker -rpath /usr/X11R7/lib -L../../lib -lglut -lGLEW > -lGLU -lGL -L../../lib -lGL -lGLU -lglut -o gears > /tmp/ccTkyHLx.o: In function `gear': > gears.c:(.text+0x208): undefined reference to `glShadeModel' > gears.c:(.text+0x224): undefined reference to `glNormal3f' > gears.c:(.text+0x230): undefined reference to `glBegin' > gears.c:(.text+0x250): undefined reference to `glVertex3f' > gears.c:(.text+0x254): undefined reference to `glVertex3f' > gears.c:(.text+0x258): undefined reference to `glEnd' > gears.c:(.text+0x25c): undefined reference to `glBegin' > gears.c:(.text+0x47c): undefined reference to `glVertex3f' > gears.c:(.text+0x48c): undefined reference to `glVertex3f' > gears.c:(.text+0x498): undefined reference to `glVertex3f' > gears.c:(.text+0x4a4): undefined reference to `glVertex3f' > gears.c:(.text+0x4a8): undefined reference to `glEnd' > gears.c:(.text+0x4ac): undefined reference to `glNormal3f' > gears.c:(.text+0x4b8): undefined reference to `glBegin' > gears.c:(.text+0x6f0): undefined reference to `glVertex3f' > gears.c:(.text+0x6f4): undefined reference to `glVertex3f' > gears.c:(.text+0x6f8): undefined reference to `glEnd' > gears.c:(.text+0x6fc): undefined reference to `glBegin' > ......and so on > > I have all the libs needed by this compilation. > So It seems that the problem might be caused by disabling the X86_ASM > flags, which contains these symbols. > How I can solve this problem? is there a generic code in C replacing the > X86_ASM? > > Thanks for your answers. > > -- > Christophe KHAMLY > > > > ------------------------------------------------------------------------------ > 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 > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > > -- .............................................................................................................................................. "...the finding of new proofs for known truths is often at least as important as the discovery itself..." |
|
From: Christophe K. <wet...@gm...> - 2009-08-11 08:48:29
|
Hi all, I'm trying to compile Mesa-7.5 for a SetTopBox. It's a SH4 architechture for STLinux-2.3 and It will use directfb for rendering (my STB has no GPU). I modified the current configuration in configs/linux-directfb for doing some cross-compiling and disabling the X86_source_asm compilation. The compilation worked fine but after that when I wanted to compile a demo in progs/demos I got this: root@wet:~/Mesa-7.5/progs/demos# sh4-linux-gcc -I../../include -Wall -O3 -ffast-math -fPIC -std=c99 -D_GNU_SOURCE -D_POSIX_SOURCE -D_SVID_SOURCE -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -DPTHREADS -fno-strict-aliasing gears.c readtex.o -Xlinker -rpath /usr/X11R7/lib -L../../lib -lglut -lGLEW -lGLU -lGL -L../../lib -lGL -lGLU -lglut -o gears /tmp/ccTkyHLx.o: In function `gear': gears.c:(.text+0x208): undefined reference to `glShadeModel' gears.c:(.text+0x224): undefined reference to `glNormal3f' gears.c:(.text+0x230): undefined reference to `glBegin' gears.c:(.text+0x250): undefined reference to `glVertex3f' gears.c:(.text+0x254): undefined reference to `glVertex3f' gears.c:(.text+0x258): undefined reference to `glEnd' gears.c:(.text+0x25c): undefined reference to `glBegin' gears.c:(.text+0x47c): undefined reference to `glVertex3f' gears.c:(.text+0x48c): undefined reference to `glVertex3f' gears.c:(.text+0x498): undefined reference to `glVertex3f' gears.c:(.text+0x4a4): undefined reference to `glVertex3f' gears.c:(.text+0x4a8): undefined reference to `glEnd' gears.c:(.text+0x4ac): undefined reference to `glNormal3f' gears.c:(.text+0x4b8): undefined reference to `glBegin' gears.c:(.text+0x6f0): undefined reference to `glVertex3f' gears.c:(.text+0x6f4): undefined reference to `glVertex3f' gears.c:(.text+0x6f8): undefined reference to `glEnd' gears.c:(.text+0x6fc): undefined reference to `glBegin' ......and so on I have all the libs needed by this compilation. So It seems that the problem might be caused by disabling the X86_ASM flags, which contains these symbols. How I can solve this problem? is there a generic code in C replacing the X86_ASM? Thanks for your answers. -- Christophe KHAMLY |
|
From: vinit b. <ban...@gm...> - 2009-08-11 08:08:05
|
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? Thanks in advance, Best Regards, Vinit Bansal |
|
From: Nicolas C. <nic...@ym...> - 2009-08-06 14:50:13
|
Hi all,
I use the i945GME, I try to have a verticale synchronisation with the functions glXGetVideoSyncSGI and glXWaitVideoSyncSGI. But when I call the function glXGetVideoSyncSGI, the driver call the function i915_get_vblank_counter and display this message :
[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
This my xorg.conf :
################################################################################
Section "ServerLayout"
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
#InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
#Option "AIGLX" "false"
EndSection
Section "Files"
ModulePath "/usr/lib/xorg/modules"
FontPath "/usr/lib/X11/fonts/misc/"
FontPath "/usr/lib/X11/fonts/TTF/"
FontPath "/usr/lib/X11/fonts/OTF"
FontPath "/usr/lib/X11/fonts/Type1/"
FontPath "/usr/lib/X11/fonts/100dpi/"
FontPath "/usr/lib/X11/fonts/75dpi/"
EndSection
Section "Module"
Load "dbe"
Load "dri"
Load "dri2"
Load "extmod"
Load "glx"
EndSection
Section "ServerFlags"
Option "blank time" "0"
Option "standby time" "0"
Option "suspend time" "0"
Option "off time" "0"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection
#Section "InputDevice"
# Identifier "Mouse0"
# Driver "mouse"
# Option "Protocol" "auto"
# Option "Device" "/dev/input/mice"
# Option "ZAxisMapping" "4 5 6 7"
#EndSection
Section "Monitor"
Identifier "TMDS-2"
Option "DPMS"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
Modeline "1024x768 INITIAL MODE" 64.99 1024 1048 1184 1344 768 771 777 806 -HSync -VSync
Modeline "1280x720 60Hz CEA" 74.25 1280 1500 1540 1650 720 725 730 750 +HSync +VSync
ModeLine "1360x768 60Hz VESA" 85.50 1360 1392 1712 1744 768 783 791 807 +HSync +Vsync
ModeLine "1366x768 60Hz" 85.86 1366 1440 1584 1800 768 769 772 795 -HSync +Vsync
Modeline "1376x768 60Hz VESA" 85.25 1376 1448 1584 1784 768 771 781 798 -HSync +VSync
EndSection
Section "Device"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
### [arg]: arg optional
#Option "NoAccel" # [<bool>]
#Option "SWcursor" # [<bool>]
#Option "ColorKey" # <i>
#Option "CacheLines" # <i>
#Option "Dac6Bit" # [<bool>]
#Option "DRI" # [<bool>]
#Option "NoDDC" # [<bool>]
#Option "ShowCache" # [<bool>]
#Option "XvMCSurfaces" # <i>
#Option "PageFlip" # [<bool>]
Identifier "Card0"
Driver "intel"
VendorName "Unknown Vendor"
BoardName "Unknown Board"
BusID "PCI:0:2:0"
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "TMDS-2"
SubSection "Display"
Viewport 0 0
Depth 16
Modes "1024x768 INITIAL MODE" "1280x720 60Hz CEA" "1360x768 60Hz" "1366x768 60Hz" "1376x768 60Hz VESA"
EndSubSection
SubSection "Display"
Viewport 0 0
Depth 24
Modes "1024x768 INITIAL MODE" "1280x720 60Hz CEA" "1360x768 60Hz" "1366x768 60Hz" "1376x768 60Hz VESA"
EndSubSection
EndSection
################################################################################
This is my Xorg.log :
################################################################################
WW) Failed to open protocol names file /cygdrive/c/usr/software/embedded-systems/system-builders/innes/player2G/boxpc-linux-x/boxpc-linux-x-2.11/usrfs/lib/xorg/protocol.txt
This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.
X.Org X Server 1.6.99.1
Release Date: (unreleased)
X Protocol Version 11, Revision 0
Build Operating System: CYGWIN_NT-6.0 1.5.25(0.156/4/2) i686
Current Operating System: Linux mpdsbcn270 2.6.28.9 #13 SMP Wed Aug 5 19:09:21 CEST 2009 i686
Build Date: 16 June 2009 03:33:45PM
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(++) Log file: "/var/log/Xorg.log", Time: Thu Aug 6 15:37:20 2009
(==) Using config file: "/etc/xorg.conf"
(==) ServerLayout "X.org Configured"
(**) |-->Screen "Screen0" (0)
(**) | |-->Monitor "TMDS-2"
(**) | |-->Device "Card0"
(**) |-->Input Device "Keyboard0"
(**) Option "BlankTime" "0"
(**) Option "StandbyTime" "0"
(**) Option "SuspendTime" "0"
(**) Option "OffTime" "0"
(==) Not automatically adding devices
(==) Not automatically enabling devices
(WW) The directory "/usr/lib/X11/fonts/misc/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/TTF/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/OTF" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/Type1/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/100dpi/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/75dpi/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/misc/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/TTF/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/OTF" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/Type1/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/100dpi/" does not exist.
Entry deleted from font path.
(WW) The directory "/usr/lib/X11/fonts/75dpi/" does not exist.
Entry deleted from font path.
(**) FontPath set to:
built-ins
(++) ModulePath set to "/usr/lib/xorg/modules"
(==) |-->Input Device "<default pointer>"
(==) The core pointer device wasn't specified explicitly in the layout.
Using the default mouse configuration.
(II) Loader magic: 0x823c300
(II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 5.0
X.Org XInput driver : 5.0
X.Org Server Extension : 2.0
(--) using VT number 2
(--) PCI:*(0@0:2:0) unknown vendor (0x8086) unknown chipset (0x27ae) rev 3, Mem @ 0xfea80000/524288, 0xd0000000/268435456, 0xfea40000/262144, I/O @ 0x0000dc00/8
(--) PCI: (0@0:2:1) unknown vendor (0x8086) unknown chipset (0x27a6) rev 3, Mem @ 0xfe980000/524288
(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(II) System resource ranges:
[0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
(II) "extmod" will be loaded. This was enabled by default and also specified in the config file.
(II) "dbe" will be loaded. This was enabled by default and also specified in the config file.
(II) "glx" will be loaded. This was enabled by default and also specified in the config file.
(II) "dri" will be loaded. This was enabled by default and also specified in the config file.
(II) "dri2" will be loaded. This was enabled by default and also specified in the config file.
(II) LoadModule: "dbe"
(II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "dri"
(II) Loading /usr/lib/xorg/modules/extensions/libdri.so
(II) Module dri: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 1.0.0
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension XFree86-DRI
(II) LoadModule: "dri2"
(II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
(II) Module dri2: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 1.1.0
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension DRI2
(II) LoadModule: "extmod"
(II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 2.0
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 1.0.0
ABI class: X.Org Server Extension, version 2.0
(==) AIGLX enabled
(II) Loading extension GLX
(II) LoadModule: "intel"
(II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 2.7.99
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 5.0
(II) LoadModule: "kbd"
(II) Loading /usr/lib/xorg/modules/input/kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 1.3.2
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 5.0
(II) LoadModule: "mouse"
(II) Loading /usr/lib/xorg/modules/input/mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 1.4.0
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 5.0
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
E7221 (i915), 915GM, 945G, 945GM, 945GME, IGD_GM, IGD_G, 965G, G35,
965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
Mobile Intel® GM45 Express Chipset,
Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41
(II) Primary Device is: PCI 00@00:02:0
(II) resource ranges after xf86ClaimFixedResources() call:
[0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
(II) resource ranges after probing:
[0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B]
[5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B]
[6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B]
[7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[8] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
[9] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B]
[10] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/lib/xorg/modules/libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 0.1.0
ABI class: X.Org Video Driver, version 5.0
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Module "ramdac" already built-in
(++) intel(0): Depth 24, (--) framebuffer bpp 32
(==) intel(0): RGB weight 888
(==) intel(0): Default visual is TrueColor
(II) intel(0): Integrated Graphics Chipset: Intel(R) 945GME
(--) intel(0): Chipset: "945GME"
(--) intel(0): Linear framebuffer at 0xD0000000
(--) intel(0): IO registers at addr 0xFEA80000
(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB
Failed to load DMI info, MSI LVDS quirk not applied.
(--) intel(0): Using UXA for acceleration
(II) intel(0): 2 display pipes available.
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Module "ddc" already built-in
(II) Loading sub module "i2c"
(II) LoadModule: "i2c"
(II) Module "i2c" already built-in
(II) intel(0): Output VGA using monitor section TMDS-2
(II) intel(0): Output LVDS has no monitor section
(II) intel(0): I2C bus "LVDSDDC_C" initialized.
(II) intel(0): Attempting to determine panel fixed mode.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): EDID vendor "NEC", prod id 26345
(II) intel(0): Output TV has no monitor section
(II) intel(0): EDID vendor "NEC", prod id 26345
(II) intel(0): Output VGA disconnected
(II) intel(0): Output LVDS connected
(II) intel(0): Output TV disconnected
(II) intel(0): Using exact sizes for initial modes
(II) intel(0): Output LVDS using initial mode 1360x768
(II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
(II) intel(0): detected 256 kB GTT.
(II) intel(0): detected 7932 kB stolen memory.
(==) intel(0): video overlay key set to 0x101fe
(==) intel(0): DPI set to (96, 96)
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/lib/xorg/modules/libfb.so
(II) Module fb: vendor="X.Org Foundation"
compiled for 1.6.99.1, module version = 1.0.0
ABI class: X.Org ANSI C Emulation, version 0.4
(II) intel(0): Comparing regs from server start up to After PreInit
(WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd000000a
(WW) intel(0): PP_STATUS before: on, ready, sequencing idle
(WW) intel(0): PP_STATUS after: on, ready, sequencing on
(WW) intel(0): Register 0x70024 (PIPEASTAT) changed from 0x00000000 to 0x00000203
(WW) intel(0): PIPEASTAT before: status:
(WW) intel(0): PIPEASTAT after: status: VSYNC_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS
(WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x00000202 to 0x80000202
(WW) intel(0): PIPEBSTAT before: status: VSYNC_INT_STATUS VBLANK_INT_STATUS
(WW) intel(0): PIPEBSTAT after: status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS
(==) Depth 24 pixmap format is 32 bpp
(II) do I need RAC? No, I don't.
(II) resource ranges after preInit:
[0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD)
[5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD)
[6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD)
[7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B]
[8] -1 0 0x00000000 - 0x00000000 (0x1) IX[B]
[9] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU)
[10] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU)
(II) intel(0): Kernel reported 238848 total, 1 used
(II) intel(0): I830CheckAvailableMemory: 955388 kB available
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 9, (OK)
drmOpenByBusid: drmOpenMinor returns 9
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) intel(0): [DRI2] Setup complete
(**) intel(0): Framebuffer compression enabled
(**) intel(0): Tiling enabled
(==) intel(0): VideoRam: 262144 KB
(II) intel(0): Attempting memory allocation with tiled buffers.
(II) intel(0): Tiled allocation successful.
(II) intel(0): adjusting plane->pipe mappings to allow for framebuffer compression
(II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(II) UXA(0): Driver registered support for the following operations:
(II) solid
(II) copy
(II) composite (RENDER acceleration)
(==) intel(0): Backing store disabled
(==) intel(0): Silken mouse enabled
(II) intel(0): Initializing HW Cursor
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x005fffff: compressed frame buffer (6144 kB, 0x000000003f800000 physical
)
(II) intel(0): 0x00600000-0x00600fff: compressed ll buffer (4 kB, 0x000000003fe00000 physical
)
(II) intel(0): 0x00601000-0x0060afff: HW cursors (40 kB, 0x000000003fe01000 physical
)
(II) intel(0): 0x0060b000-0x0060bfff: overlay registers (4 kB, 0x000000003fe0b000 physical
)
(II) intel(0): 0x007bf000: end of stolen memory
(II) intel(0): 0x007bf000-0x0f9f3fff: DRI memory manager (248020 kB)
(II) intel(0): 0x10000000: end of aperture
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x007bf000: start of memory manager
(II) intel(0): 0x00800000-0x00ffffff: front buffer (8192 kB) X tiled
(II) intel(0): 0x0f9f4000: end of memory manager
(II) intel(0): Selecting standard 18 bit TMDS pixel format.
(II) intel(0): Output configuration:
(II) intel(0): Pipe A is off
(II) intel(0): Display plane B is now disabled and connected to pipe A.
(II) intel(0): Pipe B is on
(II) intel(0): Display plane A is now enabled and connected to pipe B.
(II) intel(0): Output VGA is connected to pipe none
(II) intel(0): Output LVDS is connected to pipe B
(II) intel(0): Output TV is connected to pipe none
(II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
(**) intel(0): DPMS enabled
(II) intel(0): Set up textured video
(II) intel(0): Set up overlay video
(II) intel(0): direct rendering: DRI2 Enabled
(--) RandR disabled
(II) Initializing built-in extension Generic Event Extension
(II) Initializing built-in extension SHAPE
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension BIG-REQUESTS
(II) Initializing built-in extension SYNC
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-MISC
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) AIGLX: enabled GLX_MESA_copy_sub_buffer
(II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
(II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
(II) AIGLX: Loaded and initialized /usr/lib/dri/i915_dri.so
(II) GLX: Initialized DRI2 GL provider for screen 0
(II) intel(0): Setting screen physical size to 359 x 203
(**) Option "CoreKeyboard"
(**) Keyboard0: always reports core events
(**) Option "Protocol" "standard"
(**) Keyboard0: Protocol: standard
(**) Option "XkbRules" "base"
(**) Keyboard0: XkbRules: "base"
(**) Option "XkbModel" "pc105"
(**) Keyboard0: XkbModel: "pc105"
(**) Option "XkbLayout" "us"
(**) Keyboard0: XkbLayout: "us"
(**) Option "CustomKeycodes" "off"
(**) Keyboard0: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)
(WW) <default pointer>: No Device specified, looking for one...
(EE) <default pointer>: Cannot find which device to use.
(==) <default pointer>: Protocol: "Auto"
(**) Option "CorePointer"
(**) <default pointer>: always reports core events
(EE) xf86OpenSerial: No Device specified.
(EE) <default pointer>: cannot open input device
(EE) PreInit failed for input device "<default pointer>"
(II) UnloadModule: "mouse"
(II) intel(0): EDID vendor "NEC", prod id 26345
(II) intel(0): Using EDID range info for horizontal sync
(II) intel(0): Using EDID range info for vertical refresh
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1360x768"x0.0 84.75 1360 1432 1568 1776 768 771 776 798 -hsync +vsync (47.7 kHz)
(II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz)
(II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz)
(II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz)
(II) intel(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "1366x768"x59.8 84.75 1366 1432 1568 1776 768 770 780 798 -hsync +vsync (47.7 kHz)
(II) intel(0): EDID vendor "NEC", prod id 26345
################################################################################
Somebody can help me to resolve my problem ?
Thanks
Nico
|
|
From: Brian P. <br...@vm...> - 2009-08-04 15:12:10
|
vinit bansal wrote: > Hi Brian, > I have one basic question. > I am using MESA 7.4 in my test application which uses openGL 1.1 as well > as 2.0 program. > > I am little confused about when to include <gl.h> and when <glext.h> > > My understanding is: > for openGL 1.1/1.2/1.3 include<gl.h> > > otherwise for higher version: > include <glext.h> > > just like we have gl.h and gl2.h, same in MESA we have gl.h and glext.h? > > correct me if i am wrong. glext.h is included by gl.h so all you ever have to include is gl.h. At least that's the way it's supposed to work. I haven't looked at other vendors' gl.h headers in a while. -Brian |
|
From: vinit b. <ban...@gm...> - 2009-08-04 05:55:00
|
Hi Brian, I have one basic question. I am using MESA 7.4 in my test application which uses openGL 1.1 as well as 2.0 program. I am little confused about when to include <gl.h> and when <glext.h> My understanding is: for openGL 1.1/1.2/1.3 include<gl.h> otherwise for higher version: include <glext.h> just like we have gl.h and gl2.h, same in MESA we have gl.h and glext.h? correct me if i am wrong. Thanks & Regards Vinit |
23 messages has been excluded from this view by a project administrator.
