mesa3d-users

Re: [Mesa3d-users] Fastest way to grab pixel values in to memory (and file)

[tom f. <tf...@al...>]

Srimal Jayawardena <sr...@gm...> writes:
> Hi
> 
> > How complex is the image recognition algorithm?
>
> Well the function involves a matrix operations, calculating
> expected values, covariances etc and obtaining the minimum
> of the function values from the 100 frames.
> 
> Can GLSL calculate an arbitrary function like that?

In general, it's hard to get a GPU to perform an arbitrary algorithm.
That said, matrix operations are what a GPU was designed to do, and I
recommended GLSL because GPUs are exceptionally good at doing the types
of per-fragment operations that come up frequently in image processing.

> Any good pointers for me to get started?

  http://www.opengl.org/documentation/glsl/

the wikipedia page is a good meta starting point:

  http://en.wikipedia.org/wiki/GLSL

note the 'References'.  Some quick google searches turn up:

  http://gamma.cs.unc.edu/GPGP/lectures/imgproc.pdf
  http://www.cs.berkeley.edu/~kubitron/courses/cs252-F03/projects/reports/project12_report_ver2.pdf

-tom

> > You might consider implementing your algorithm in GLSL.
[snip]

Re: [Mesa3d-users] [Fwd: r600_cmdbuf.c:323: error: storage size of ‘cs_cmd’ isn’t known]

[Chris J. <cjn...@gm...>]

On Sun, Aug 02, 2009 at 01:12:54AM EDT, Arthur Marsh wrote:
> Hi, I'm trying to build mesa using the instructions at:
> 
> http://www.x.org/wiki/radeonhd%3Aexperimental_3D
> 
> and get the error:
> 
> make[5]: Entering directory `/usr/src/sound/mesa/src/mesa/drivers/dri/r600'
> gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
> -I../../../../../include -I../../../../../src/mesa
> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
> -I/usr/include/drm    -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fno-strict-aliasing -g  -fPIC  -DUSE_X86_64_ASM
> -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  -DCOMPILE_R600 -DR200_MERGED=0
> -DRADEON_COMMON=1 -DRADEON_COMMON_FOR_R600  r600_cmdbuf.c -o r600_cmdbuf.o
> r600_cmdbuf.c: In function ‘r600_cs_emit’:
> r600_cmdbuf.c:323: error: storage size of ‘cs_cmd’ isn’t known
> r600_cmdbuf.c:324: error: array type has incomplete element type
> r600_cmdbuf.c:342: error: ‘RADEON_CHUNK_ID_IB’ undeclared (first use in
> this function)
> r600_cmdbuf.c:342: error: (Each undeclared identifier is reported only once
> r600_cmdbuf.c:342: error: for each function it appears in.)
> r600_cmdbuf.c:347: error: ‘RADEON_CHUNK_ID_RELOCS’ undeclared (first use
> in this function)
> r600_cmdbuf.c:362: error: ‘DRM_RADEON_CS’ undeclared (first use in this
> function)
> r600_cmdbuf.c:324: warning: unused variable ‘cs_chunk’
> r600_cmdbuf.c:323: warning: unused variable ‘cs_cmd’
> make[5]: *** [r600_cmdbuf.o] Error 1
> 
> Any suggestions?
> 
> Arthur.
> 
> 
> ------------------------------------------------------------------------------
> 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: Chris Jones <cjn...@gm...>
To: Andrei Popescu <and...@gm...>
Cc: 
Bcc: 
Subject: Re: vim linebreaks in Mutt
Reply-To: 
In-Reply-To: <20090802073214.GC4006@think.homelan>

On Sun, Aug 02, 2009 at 03:32:14AM EDT, Andrei Popescu wrote:
> On Sat,01.Aug.09, 21:56:46, Rob Owens wrote:
> > What's the proper setting to get good line breaks in Mutt (using vim),
> > without manually hitting the enter key?  (So that this paragraph, for
> > instance, is not one long line of text, but rather several shorter lines of
> > text).
> > 
> > I currently have this in .muttrc:
> > 
> > set editor="vim -c 'set wrapmargin=5'"
> 
> If filetype plugins are active[1] vim should "know" you are editing a 
> mail and will already set textwidth=72 and use also some syntax coloring 
> (ex. quotes and your .sig will show in a different color). 
> 
> Additionally I have this in my .vimrc
> 
> autocmd FileType mail set spell spelllang=ro,de,en fo+=aw       " spell and autowrap text in emails
> 
> [1] they have been disabled by default in Debian, but my .vimrc is based 
> on the example in /usr/share/vim/vimcurrent/vimrc_example.vim which 
> enables them
> 
> Regards,
> Andrei
> -- 
> If you can't explain it simply, you don't understand it well enough.
> (Albert Einstein)

Re: [Mesa3d-users] Posted by accident - Please ignore. ‘cs_cmd’ isn’t known]

[Chris J. <cjn...@gm...>]

On Sun, Aug 02, 2009 at 01:12:54AM EDT, Arthur Marsh wrote:

Oops.. apologies - was having issues with my mailer.

Re: [Mesa3d-users] Fastest way to grab pixel values in to memory (and file)

[Srimal J. <sr...@gm...>]

Hi

> How complex is the image recognition algorithm?
Well the function involves a matrix operations, calculating
expected values, covariances etc and obtaining the minimum
of the function values from the 100 frames.

Can GLSL calculate an arbitrary function like that?

Any good pointers for me to get started?

Many thanks

Srimal.

>
> You might consider implementing your algorithm in GLSL.  Then you'd do
> one readback at the end just to get the result.  If your bottleneck is
> the readback, you'd get much better performance.  Plus a modern GPU
> will greatly accelerate the GLSL operations.
>
> Cheers,
>
> -tom
>
> ------------------------------------------------------------------------------
> 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
>



-- 
~
Srimal Jayawardena
BSc (Engineering), BIT, MIET
PhD Student, Australian National University.

Phone(Mobile): +61 422 684 854
Phone(Office): +61 2 6125 1771
Phone(Home): +61 2 6125 1413


ANU Contact Info : http://arp.anu.edu.au/user/3788

http://srimal.sri-lankan.net/
http://srimal-techdiary.blogspot.com/

Re: [Mesa3d-users] [Fwd: r600_cmdbuf.c:323: error: storage size of ‘cs_cmd’ isn’t known]

[Chris J. <cjn...@gm...>]

On Sun, Aug 02, 2009 at 01:12:54AM EDT, Arthur Marsh wrote:
> Hi, I'm trying to build mesa using the instructions at:
> 
> http://www.x.org/wiki/radeonhd%3Aexperimental_3D
> 
> and get the error:
> 
> make[5]: Entering directory `/usr/src/sound/mesa/src/mesa/drivers/dri/r600'
> gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
> -I../../../../../include -I../../../../../src/mesa
> -I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
> -I/usr/include/drm    -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fno-strict-aliasing -g  -fPIC  -DUSE_X86_64_ASM
> -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  -DCOMPILE_R600 -DR200_MERGED=0
> -DRADEON_COMMON=1 -DRADEON_COMMON_FOR_R600  r600_cmdbuf.c -o r600_cmdbuf.o
> r600_cmdbuf.c: In function ‘r600_cs_emit’:
> r600_cmdbuf.c:323: error: storage size of ‘cs_cmd’ isn’t known
> r600_cmdbuf.c:324: error: array type has incomplete element type
> r600_cmdbuf.c:342: error: ‘RADEON_CHUNK_ID_IB’ undeclared (first use in
> this function)
> r600_cmdbuf.c:342: error: (Each undeclared identifier is reported only once
> r600_cmdbuf.c:342: error: for each function it appears in.)
> r600_cmdbuf.c:347: error: ‘RADEON_CHUNK_ID_RELOCS’ undeclared (first use
> in this function)
> r600_cmdbuf.c:362: error: ‘DRM_RADEON_CS’ undeclared (first use in this
> function)
> r600_cmdbuf.c:324: warning: unused variable ‘cs_chunk’
> r600_cmdbuf.c:323: warning: unused variable ‘cs_cmd’
> make[5]: *** [r600_cmdbuf.o] Error 1
> 
> Any suggestions?
> 
> Arthur.
> 
> 
> ------------------------------------------------------------------------------
> 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

[Mesa3d-users] [Fwd: r600_cmdbuf.c:323: error: storage size of ‘cs_cmd’ isn’t known]

[Arthur M. <art...@in...>]

Hi, I'm trying to build mesa using the instructions at:

http://www.x.org/wiki/radeonhd%3Aexperimental_3D

and get the error:

make[5]: Entering directory `/usr/src/sound/mesa/src/mesa/drivers/dri/r600'
gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri
-I/usr/include/drm    -g -O2 -Wall -Wmissing-prototypes -std=c99
-ffast-math -fno-strict-aliasing -g  -fPIC  -DUSE_X86_64_ASM
-D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  -DCOMPILE_R600 -DR200_MERGED=0
-DRADEON_COMMON=1 -DRADEON_COMMON_FOR_R600  r600_cmdbuf.c -o r600_cmdbuf.o
r600_cmdbuf.c: In function ‘r600_cs_emit’:
r600_cmdbuf.c:323: error: storage size of ‘cs_cmd’ isn’t known
r600_cmdbuf.c:324: error: array type has incomplete element type
r600_cmdbuf.c:342: error: ‘RADEON_CHUNK_ID_IB’ undeclared (first use in
this function)
r600_cmdbuf.c:342: error: (Each undeclared identifier is reported only once
r600_cmdbuf.c:342: error: for each function it appears in.)
r600_cmdbuf.c:347: error: ‘RADEON_CHUNK_ID_RELOCS’ undeclared (first use
in this function)
r600_cmdbuf.c:362: error: ‘DRM_RADEON_CS’ undeclared (first use in this
function)
r600_cmdbuf.c:324: warning: unused variable ‘cs_chunk’
r600_cmdbuf.c:323: warning: unused variable ‘cs_cmd’
make[5]: *** [r600_cmdbuf.o] Error 1

Any suggestions?

Arthur.

Re: [Mesa3d-users] Fastest way to grab pixel values in to memory (and file)

[tom f. <tf...@al...>]

Brian Paul <br...@vm...> writes:
> Srimal Jayawardena wrote:
> > I'm working on a Image recognition project . . .
> > 
> > I am hoping to use OpenGL to obtain 2D pixel values from different 3D
> > view points, in the hope that the 3d h/w processing will do things a
> > lot faster for me.
[snip]
> > At the moment I am using glReadPixels() to read transformed pixel
> > values into memory.
> > 
> > Is  there a faster way? Or would you recommend a
> > better approach?

How complex is the image recognition algorithm?

You might consider implementing your algorithm in GLSL.  Then you'd do
one readback at the end just to get the result.  If your bottleneck is
the readback, you'd get much better performance.  Plus a modern GPU
will greatly accelerate the GLSL operations.

Cheers,

-tom

Re: [Mesa3d-users] Fastest way to grab pixel values in to memory (and file)

[Brian P. <br...@vm...>]

Srimal Jayawardena wrote:
> Hi all
> 
> 
> I'm working on a Image recognition project where I need to do
> calculations on different views (more than 100 frames)
> of a 3d model within an order of less than 1 sec, in order to
> calculate a particular optimization function.
> 
> I am hoping to use OpenGL to obtain 2D pixel values from different 3D
> view points, in the hope that the 3d h/w processing will do things a
> lot faster for me.
> 
> I need to render 100frames of 20,000 triangles
> in less than 1sec.
> 
> At the moment I am using glReadPixels() to read transformed pixel
> values into memory.
> 
> This is a bit slow and it takes around 10sec to grab 100 frames .
> 
> Is  there a faster way? Or would you recommend a
> better approach?
> 
> I've heard of buffer object ? but am not quite sure how they can
> be used to grab pixel data into memory.
> 
> Rendering the pixels into some virtual buffer is fine with my application
> as long as reading the pixel values happens in less than 1 sec.
> 
> 
> Any pointers would be much appreciated.
> 
> Thanks in advance

Which hardware/driver are you using?

The only thing I can suggest is trying different format/type 
parameters to glReadPixels().  A combo such as 
GL_BGRA/GL_UNSIGNED_INT_8_8_8_8 might be a better match for the 
hardware layout and allow the driver to avoid swizzling.  But this can 
vary from one gpu/driver to another.

-Brian

[Mesa3d-users] Fastest way to grab pixel values in to memory (and file)

[Srimal J. <sr...@gm...>]

Hi all


I'm working on a Image recognition project where I need to do
calculations on different views (more than 100 frames)
of a 3d model within an order of less than 1 sec, in order to
calculate a particular optimization function.

I am hoping to use OpenGL to obtain 2D pixel values from different 3D
view points, in the hope that the 3d h/w processing will do things a
lot faster for me.

I need to render 100frames of 20,000 triangles
in less than 1sec.

At the moment I am using glReadPixels() to read transformed pixel
values into memory.

This is a bit slow and it takes around 10sec to grab 100 frames .

Is  there a faster way? Or would you recommend a
better approach?

I've heard of buffer object ? but am not quite sure how they can
be used to grab pixel data into memory.

Rendering the pixels into some virtual buffer is fine with my application
as long as reading the pixel values happens in less than 1 sec.


Any pointers would be much appreciated.

Thanks in advance

Srimal.

[Mesa3d-users] problem compiling Mesa-7.5 to get GLwCreateMDrawingArea library

[Karl J. <joh...@pi...>]

hi all,
thank you for taking care of my problem and your mails.
Because of a short holiday I myself can react not till next week.
Karl

Re: [Mesa3d-users] Visual Studio project files broken?

[Karl S. <kar...@gm...>]

I took a look, and I think that:

gl.h has:

#if defined(_WIN32) && !defined(__WIN32__) && !defined(__CYGWIN__)
#define __WIN32__
#endif

and compiler.h has:

#if defined(_WIN32) && !defined(__WIN32__) && !defined(__CYGWIN__) &&
!defined(BUILD_FOR_SNAP)
#  define __WIN32__
#  define finite _finite
#endif


So if gl.h gets included before compiler.h, finite will not get defined.
And that is the real problem.

So, probably, between the last two releases, some of the includes got
reordered or reorganized and exposed this problem.

The "fix" in the patch works because the project files now "force include"
compiler.h, which makes the compiler include compiler.h first, before
pulling in any other code.  I think of this "force include" as a way to work
around compiler inconsistencies, and this finite/_finite thing is a good
example.  Thus, compiler.h is perfect for using with this sort of compiler
option.

The use of this feature is somewhat debatable.  It is sort of robust because
if someone uses that macro in a file someplace else that doesn't otherwise
include compiler.h, the "forced include" always is in effect.  It kind of
makes sense to address a compiler/libc weirdness at the source of the
weirdness.   OTOH, it is sort of an ugly hack and not the sort of thing most
people would look for in VisStudio.  I'll try to decide what to do before
the next release.  That will probably involve just removing
!defined(__WIN32__) from the check to define _finite.  Sort of seems wrong
anyway.

Thanks,
Karl


On Mon, Jul 27, 2009 at 3:50 PM, Brian Paul <br...@vm...> wrote:

> OK, I committed those files.  I didn't see how they fixed the "finite"
> problem but I'll take your word for it. :)
>
> -Brian
>
> Karl Schultz wrote:
>
>> Yeah, someone else opened a bug and I put the patch there.
>>
>> http://bugs.freedesktop.org/show_bug.cgi?id=22882
>>
>> On Mon, Jul 27, 2009 at 1:46 PM, Brian Paul <br...@vm... <mailto:
>> br...@vm...>> wrote:
>>
>>
>>    I don't see how this problem is happening.  The files which failed
>>    to find "finite" (such as s_lines.c) come from use of the
>>    IS_INF_OR_NAN() macro from imports.h.  But imports.h already
>>    #includes compiler.h
>>
>>    Did either of you have a patch to fix this?
>>
>>    -Brian
>>
>>    Jianrong Shu wrote:
>>
>>        Please go ahead and submit patches as you see fit.
>>
>>        On Tue, Jul 21, 2009 at 12:46 PM, Karl
>>        Schultz<kar...@gm...
>>        <mailto:kar...@gm...>> wrote:
>>
>>            Ooops, I didn't see that it got moved to compiler.h.
>>
>>            No, it should not be in two header files; I just didn't see
>>            that it got
>>            moved to compiler.h.  It should not be in glheader.h.
>>
>>            One correct fix is to add an "#include main/compiler.h" to
>>            just the files
>>            that need it.  It sort of looks like just a few files were
>>            missed when the
>>            macro was moved.  Easy to miss these since finite is buried
>>            inside of other
>>            macros.
>>
>>            I suppose your solution of forcing the include in all the
>>            files does the
>>            same thing and may be less fragile.
>>
>>            Another fix is to add "finite=_finite" to the list of "-D"
>>            compiler options
>>            in the mesa and osmesa project files, for all build targets.
>>             Then, the
>>            macro definition could be removed from compiler.h.  But this
>>            might force a
>>            change in the scons build files as well.  I don't know,
>>            because I am not
>>            familiar with scons.
>>
>>            I'll settle on something and submit patches, unless you'd
>>            like to do that.
>>
>>            Karl
>>
>>
>>            On Tue, Jul 21, 2009 at 12:24 PM, Jianrong Shu
>>            <jia...@gm... <mailto:jia...@gm...>>
>>            wrote:
>>
>>                Thanks. My fix to this was to force including
>>                'compiler.h' in the
>>                project settings. Was there a specific reason that you
>>                defined the
>>                same macro in two header files?
>>
>>                Jianrong
>>
>>                On Mon, Jul 20, 2009 at 11:47 PM, Karl
>>                Schultz<kar...@gm...
>>                <mailto:kar...@gm...>>
>>                wrote:
>>
>>                    It looks like glheader.h (thankfully) got cleaned up
>>                    quite a bit since
>>                    7.4.
>>                    In the process, the following was lost:
>>
>>                    #if defined(_WIN32) && !defined(__WIN32__) &&
>>                    !defined(__CYGWIN__) &&
>>                    !defined(BUILD_FOR_SNAP)
>>                    #  define __WIN32__
>>                    #  define finite _finite
>>                    #endif
>>
>>
>>                    Adding back the above will get you going again.
>>
>>                    Also, you'll need to:
>>
>>                    Add to the mesa project:
>>
>>                    cpuinfo.[ch]
>>                    prog_optimize.[ch]
>>                    texgetimage.[ch]
>>
>>                    Remove from mesa.def:
>>
>>                    _mesa_get_program_register
>>
>>
>>                    On Fri, Jul 17, 2009 at 4:20 PM, Jianrong Shu
>>                    <jia...@gm... <mailto:jia...@gm...
>> >>
>>
>>                    wrote:
>>
>>                        I fixed most of the problems except that the
>>                        linker couldn't find the
>>                        definition of _finite function, which is
>>                        Microsoft's implementation of
>>                        isfinite. The error messages as follows:
>>
>>                        1>mesa.lib(s_aatriangle.obj) : error LNK2001:
>>                        unresolved external
>>                        symbol
>>                        _finite
>>                        1>mesa.lib(s_aaline.obj) : error LNK2001:
>>                        unresolved external symbol
>>                        _finite
>>                        1>mesa.lib(prog_execute.obj) : error LNK2019:
>>                        unresolved external
>>                        symbol _finite referenced in function
>>                        __mesa_execute_program
>>                        1>mesa.lib(s_triangle.obj) : error LNK2001:
>>                        unresolved external symbol
>>                        _finite
>>                        1>mesa.lib(s_lines.obj) : error LNK2001:
>>                        unresolved external symbol
>>                        _finite
>>                        1>mesa.lib(s_points.obj) : error LNK2001:
>>                        unresolved external symbol
>>                        _finite
>>
>>                        This problem might be caused by some settings in
>>                        the project file, but
>>                        I couldn't figure out. Any ideas?
>>
>>                        Thanks,
>>                        Jianrong
>>
>>                        On Wed, Jun 24, 2009 at 4:24 PM, Brian
>>                        Paul<br...@vm...
>>                        <mailto:br...@vm...>> wrote:
>>
>>                            Jianrong Shu wrote:
>>
>>                                Hi there,
>>
>>                                I tried to build Mesa 7.5 branch on
>>                                Windows using Visual Studio 2008
>>                                and the VC8 solution file and got
>>                                several errors.
>>
>>                                First, the "mesa" project included a
>>                                file "prog_debug.c", which
>>                                doesn't exist. After deleting it from
>>                                the project, I was able to
>>                                compile it successfully. Then, when
>>                                building the "gdi" project, I
>>                                got
>>                                the following error messages:
>>
>>                                1>Linking...
>>                                1>mesa.def : error LNK2001: unresolved
>>                                external symbol
>>                                _mesa_get_compressed_teximage
>>                                1>mesa.def : error LNK2001: unresolved
>>                                external symbol
>>                                _mesa_get_program_register
>>                                1>mesa.def : error LNK2001: unresolved
>>                                external symbol
>>                                _mesa_get_teximage
>>                                1>mesa.def : error LNK2001: unresolved
>>                                external symbol
>>                                _mglapi_check_multithread
>>                                1>mesa.def : error LNK2001: unresolved
>>                                external symbol
>>                                _mglapi_get_proc_address
>>
>>                                I also tried the master branch and the
>>                                same problem exists. Any fix
>>                                to
>>                                this?
>>
>>                            The Visual Studio project files haven't been
>>                            actively maintained
>>                            lately
>>                            (we've been using scons on Windows).
>>
>>                            If you can provide updated project files,
>>                            that'd be great.  It's just
>>                            a
>>                            matter of removing references to old/removed
>>                            files and adding the new
>>                            ones.
>>
>>                            -Brian
>>
>>
>>
>>
>>
>>  ------------------------------------------------------------------------------
>>                        Enter the BlackBerry Developer Challenge
>>                        This is your chance to win up to $100,000 in
>>                        prizes! For a limited
>>                        time,
>>                        vendors submitting new applications to
>>                        BlackBerry App World(TM) will
>>                        have
>>                        the opportunity to enter the BlackBerry
>>                        Developer Challenge. See full
>>                        prize
>>                        details at: http://p.sf.net/sfu/Challenge
>>                        _______________________________________________
>>                        Mesa3d-users mailing list
>>                        Mes...@li...
>>                        <mailto:Mes...@li...>
>>
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>
>>
>>
>>
>>
>>  ------------------------------------------------------------------------------
>>
>>        _______________________________________________
>>        Mesa3d-users mailing list
>>        Mes...@li...
>>        <mailto:Mes...@li...>
>>        https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>        .
>>
>>
>>
>>
>

Re: [Mesa3d-users] Visual Studio project files broken?

[Brian P. <br...@vm...>]

OK, I committed those files.  I didn't see how they fixed the "finite" 
problem but I'll take your word for it. :)

-Brian

Karl Schultz wrote:
> Yeah, someone else opened a bug and I put the patch there.
> 
> http://bugs.freedesktop.org/show_bug.cgi?id=22882
> 
> On Mon, Jul 27, 2009 at 1:46 PM, Brian Paul <br...@vm... 
> <mailto:br...@vm...>> wrote:
> 
> 
>     I don't see how this problem is happening.  The files which failed
>     to find "finite" (such as s_lines.c) come from use of the
>     IS_INF_OR_NAN() macro from imports.h.  But imports.h already
>     #includes compiler.h
> 
>     Did either of you have a patch to fix this?
> 
>     -Brian
> 
>     Jianrong Shu wrote:
> 
>         Please go ahead and submit patches as you see fit.
> 
>         On Tue, Jul 21, 2009 at 12:46 PM, Karl
>         Schultz<kar...@gm...
>         <mailto:kar...@gm...>> wrote:
> 
>             Ooops, I didn't see that it got moved to compiler.h.
> 
>             No, it should not be in two header files; I just didn't see
>             that it got
>             moved to compiler.h.  It should not be in glheader.h.
> 
>             One correct fix is to add an "#include main/compiler.h" to
>             just the files
>             that need it.  It sort of looks like just a few files were
>             missed when the
>             macro was moved.  Easy to miss these since finite is buried
>             inside of other
>             macros.
> 
>             I suppose your solution of forcing the include in all the
>             files does the
>             same thing and may be less fragile.
> 
>             Another fix is to add "finite=_finite" to the list of "-D"
>             compiler options
>             in the mesa and osmesa project files, for all build targets.
>              Then, the
>             macro definition could be removed from compiler.h.  But this
>             might force a
>             change in the scons build files as well.  I don't know,
>             because I am not
>             familiar with scons.
> 
>             I'll settle on something and submit patches, unless you'd
>             like to do that.
> 
>             Karl
> 
> 
>             On Tue, Jul 21, 2009 at 12:24 PM, Jianrong Shu
>             <jia...@gm... <mailto:jia...@gm...>>
>             wrote:
> 
>                 Thanks. My fix to this was to force including
>                 'compiler.h' in the
>                 project settings. Was there a specific reason that you
>                 defined the
>                 same macro in two header files?
> 
>                 Jianrong
> 
>                 On Mon, Jul 20, 2009 at 11:47 PM, Karl
>                 Schultz<kar...@gm...
>                 <mailto:kar...@gm...>>
>                 wrote:
> 
>                     It looks like glheader.h (thankfully) got cleaned up
>                     quite a bit since
>                     7.4.
>                     In the process, the following was lost:
> 
>                     #if defined(_WIN32) && !defined(__WIN32__) &&
>                     !defined(__CYGWIN__) &&
>                     !defined(BUILD_FOR_SNAP)
>                     #  define __WIN32__
>                     #  define finite _finite
>                     #endif
> 
> 
>                     Adding back the above will get you going again.
> 
>                     Also, you'll need to:
> 
>                     Add to the mesa project:
> 
>                     cpuinfo.[ch]
>                     prog_optimize.[ch]
>                     texgetimage.[ch]
> 
>                     Remove from mesa.def:
> 
>                     _mesa_get_program_register
> 
> 
>                     On Fri, Jul 17, 2009 at 4:20 PM, Jianrong Shu
>                     <jia...@gm... <mailto:jia...@gm...>>
>                     wrote:
> 
>                         I fixed most of the problems except that the
>                         linker couldn't find the
>                         definition of _finite function, which is
>                         Microsoft's implementation of
>                         isfinite. The error messages as follows:
> 
>                         1>mesa.lib(s_aatriangle.obj) : error LNK2001:
>                         unresolved external
>                         symbol
>                         _finite
>                         1>mesa.lib(s_aaline.obj) : error LNK2001:
>                         unresolved external symbol
>                         _finite
>                         1>mesa.lib(prog_execute.obj) : error LNK2019:
>                         unresolved external
>                         symbol _finite referenced in function
>                         __mesa_execute_program
>                         1>mesa.lib(s_triangle.obj) : error LNK2001:
>                         unresolved external symbol
>                         _finite
>                         1>mesa.lib(s_lines.obj) : error LNK2001:
>                         unresolved external symbol
>                         _finite
>                         1>mesa.lib(s_points.obj) : error LNK2001:
>                         unresolved external symbol
>                         _finite
> 
>                         This problem might be caused by some settings in
>                         the project file, but
>                         I couldn't figure out. Any ideas?
> 
>                         Thanks,
>                         Jianrong
> 
>                         On Wed, Jun 24, 2009 at 4:24 PM, Brian
>                         Paul<br...@vm...
>                         <mailto:br...@vm...>> wrote:
> 
>                             Jianrong Shu wrote:
> 
>                                 Hi there,
> 
>                                 I tried to build Mesa 7.5 branch on
>                                 Windows using Visual Studio 2008
>                                 and the VC8 solution file and got
>                                 several errors.
> 
>                                 First, the "mesa" project included a
>                                 file "prog_debug.c", which
>                                 doesn't exist. After deleting it from
>                                 the project, I was able to
>                                 compile it successfully. Then, when
>                                 building the "gdi" project, I
>                                 got
>                                 the following error messages:
> 
>                                 1>Linking...
>                                 1>mesa.def : error LNK2001: unresolved
>                                 external symbol
>                                 _mesa_get_compressed_teximage
>                                 1>mesa.def : error LNK2001: unresolved
>                                 external symbol
>                                 _mesa_get_program_register
>                                 1>mesa.def : error LNK2001: unresolved
>                                 external symbol
>                                 _mesa_get_teximage
>                                 1>mesa.def : error LNK2001: unresolved
>                                 external symbol
>                                 _mglapi_check_multithread
>                                 1>mesa.def : error LNK2001: unresolved
>                                 external symbol
>                                 _mglapi_get_proc_address
> 
>                                 I also tried the master branch and the
>                                 same problem exists. Any fix
>                                 to
>                                 this?
> 
>                             The Visual Studio project files haven't been
>                             actively maintained
>                             lately
>                             (we've been using scons on Windows).
> 
>                             If you can provide updated project files,
>                             that'd be great.  It's just
>                             a
>                             matter of removing references to old/removed
>                             files and adding the new
>                             ones.
> 
>                             -Brian
> 
> 
> 
> 
>                         ------------------------------------------------------------------------------
>                         Enter the BlackBerry Developer Challenge
>                         This is your chance to win up to $100,000 in
>                         prizes! For a limited
>                         time,
>                         vendors submitting new applications to
>                         BlackBerry App World(TM) will
>                         have
>                         the opportunity to enter the BlackBerry
>                         Developer Challenge. See full
>                         prize
>                         details at: http://p.sf.net/sfu/Challenge
>                         _______________________________________________
>                         Mesa3d-users mailing list
>                         Mes...@li...
>                         <mailto:Mes...@li...>
>                         https://lists.sourceforge.net/lists/listinfo/mesa3d-users
> 
> 
> 
> 
>         ------------------------------------------------------------------------------
> 
>         _______________________________________________
>         Mesa3d-users mailing list
>         Mes...@li...
>         <mailto:Mes...@li...>
>         https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>         .
> 
> 
> 

Re: [Mesa3d-users] Visual Studio project files broken?

[Karl S. <kar...@gm...>]

Yeah, someone else opened a bug and I put the patch there.

http://bugs.freedesktop.org/show_bug.cgi?id=22882

On Mon, Jul 27, 2009 at 1:46 PM, Brian Paul <br...@vm...> wrote:

>
> I don't see how this problem is happening.  The files which failed to find
> "finite" (such as s_lines.c) come from use of the IS_INF_OR_NAN() macro from
> imports.h.  But imports.h already #includes compiler.h
>
> Did either of you have a patch to fix this?
>
> -Brian
>
> Jianrong Shu wrote:
>
>> Please go ahead and submit patches as you see fit.
>>
>> On Tue, Jul 21, 2009 at 12:46 PM, Karl Schultz<kar...@gm...>
>> wrote:
>>
>>> Ooops, I didn't see that it got moved to compiler.h.
>>>
>>> No, it should not be in two header files; I just didn't see that it got
>>> moved to compiler.h.  It should not be in glheader.h.
>>>
>>> One correct fix is to add an "#include main/compiler.h" to just the files
>>> that need it.  It sort of looks like just a few files were missed when
>>> the
>>> macro was moved.  Easy to miss these since finite is buried inside of
>>> other
>>> macros.
>>>
>>> I suppose your solution of forcing the include in all the files does the
>>> same thing and may be less fragile.
>>>
>>> Another fix is to add "finite=_finite" to the list of "-D" compiler
>>> options
>>> in the mesa and osmesa project files, for all build targets.  Then, the
>>> macro definition could be removed from compiler.h.  But this might force
>>> a
>>> change in the scons build files as well.  I don't know, because I am not
>>> familiar with scons.
>>>
>>> I'll settle on something and submit patches, unless you'd like to do
>>> that.
>>>
>>> Karl
>>>
>>>
>>> On Tue, Jul 21, 2009 at 12:24 PM, Jianrong Shu <jia...@gm...>
>>> wrote:
>>>
>>>> Thanks. My fix to this was to force including 'compiler.h' in the
>>>> project settings. Was there a specific reason that you defined the
>>>> same macro in two header files?
>>>>
>>>> Jianrong
>>>>
>>>> On Mon, Jul 20, 2009 at 11:47 PM, Karl Schultz<kar...@gm...
>>>> >
>>>> wrote:
>>>>
>>>>> It looks like glheader.h (thankfully) got cleaned up quite a bit since
>>>>> 7.4.
>>>>> In the process, the following was lost:
>>>>>
>>>>> #if defined(_WIN32) && !defined(__WIN32__) && !defined(__CYGWIN__) &&
>>>>> !defined(BUILD_FOR_SNAP)
>>>>> #  define __WIN32__
>>>>> #  define finite _finite
>>>>> #endif
>>>>>
>>>>>
>>>>> Adding back the above will get you going again.
>>>>>
>>>>> Also, you'll need to:
>>>>>
>>>>> Add to the mesa project:
>>>>>
>>>>> cpuinfo.[ch]
>>>>> prog_optimize.[ch]
>>>>> texgetimage.[ch]
>>>>>
>>>>> Remove from mesa.def:
>>>>>
>>>>> _mesa_get_program_register
>>>>>
>>>>>
>>>>> On Fri, Jul 17, 2009 at 4:20 PM, Jianrong Shu <jia...@gm...>
>>>>> wrote:
>>>>>
>>>>>> I fixed most of the problems except that the linker couldn't find the
>>>>>> definition of _finite function, which is Microsoft's implementation of
>>>>>> isfinite. The error messages as follows:
>>>>>>
>>>>>> 1>mesa.lib(s_aatriangle.obj) : error LNK2001: unresolved external
>>>>>> symbol
>>>>>> _finite
>>>>>> 1>mesa.lib(s_aaline.obj) : error LNK2001: unresolved external symbol
>>>>>> _finite
>>>>>> 1>mesa.lib(prog_execute.obj) : error LNK2019: unresolved external
>>>>>> symbol _finite referenced in function __mesa_execute_program
>>>>>> 1>mesa.lib(s_triangle.obj) : error LNK2001: unresolved external symbol
>>>>>> _finite
>>>>>> 1>mesa.lib(s_lines.obj) : error LNK2001: unresolved external symbol
>>>>>> _finite
>>>>>> 1>mesa.lib(s_points.obj) : error LNK2001: unresolved external symbol
>>>>>> _finite
>>>>>>
>>>>>> This problem might be caused by some settings in the project file, but
>>>>>> I couldn't figure out. Any ideas?
>>>>>>
>>>>>> Thanks,
>>>>>> Jianrong
>>>>>>
>>>>>> On Wed, Jun 24, 2009 at 4:24 PM, Brian Paul<br...@vm...> wrote:
>>>>>>
>>>>>>> Jianrong Shu wrote:
>>>>>>>
>>>>>>>> Hi there,
>>>>>>>>
>>>>>>>> I tried to build Mesa 7.5 branch on Windows using Visual Studio 2008
>>>>>>>> and the VC8 solution file and got several errors.
>>>>>>>>
>>>>>>>> First, the "mesa" project included a file "prog_debug.c", which
>>>>>>>> doesn't exist. After deleting it from the project, I was able to
>>>>>>>> compile it successfully. Then, when building the "gdi" project, I
>>>>>>>> got
>>>>>>>> the following error messages:
>>>>>>>>
>>>>>>>> 1>Linking...
>>>>>>>> 1>mesa.def : error LNK2001: unresolved external symbol
>>>>>>>> _mesa_get_compressed_teximage
>>>>>>>> 1>mesa.def : error LNK2001: unresolved external symbol
>>>>>>>> _mesa_get_program_register
>>>>>>>> 1>mesa.def : error LNK2001: unresolved external symbol
>>>>>>>> _mesa_get_teximage
>>>>>>>> 1>mesa.def : error LNK2001: unresolved external symbol
>>>>>>>> _mglapi_check_multithread
>>>>>>>> 1>mesa.def : error LNK2001: unresolved external symbol
>>>>>>>> _mglapi_get_proc_address
>>>>>>>>
>>>>>>>> I also tried the master branch and the same problem exists. Any fix
>>>>>>>> to
>>>>>>>> this?
>>>>>>>>
>>>>>>> The Visual Studio project files haven't been actively maintained
>>>>>>> lately
>>>>>>> (we've been using scons on Windows).
>>>>>>>
>>>>>>> If you can provide updated project files, that'd be great.  It's just
>>>>>>> a
>>>>>>> matter of removing references to old/removed files and adding the new
>>>>>>> ones.
>>>>>>>
>>>>>>> -Brian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Enter the BlackBerry Developer Challenge
>>>>>> This is your chance to win up to $100,000 in prizes! For a limited
>>>>>> time,
>>>>>> vendors submitting new applications to BlackBerry App World(TM) will
>>>>>> have
>>>>>> the opportunity to enter the BlackBerry Developer Challenge. See full
>>>>>> prize
>>>>>> details at: http://p.sf.net/sfu/Challenge
>>>>>> _______________________________________________
>>>>>> Mesa3d-users mailing list
>>>>>> Mes...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>>>>>
>>>>>
>>>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Mesa3d-users mailing list
>> Mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>> .
>>
>>
>

Re: [Mesa3d-users] Visual Studio project files broken?

[Brian P. <br...@vm...>]

I don't see how this problem is happening.  The files which failed to 
find "finite" (such as s_lines.c) come from use of the IS_INF_OR_NAN() 
macro from imports.h.  But imports.h already #includes compiler.h

Did either of you have a patch to fix this?

-Brian

Jianrong Shu wrote:
> Please go ahead and submit patches as you see fit.
> 
> On Tue, Jul 21, 2009 at 12:46 PM, Karl Schultz<kar...@gm...> wrote:
>> Ooops, I didn't see that it got moved to compiler.h.
>>
>> No, it should not be in two header files; I just didn't see that it got
>> moved to compiler.h.  It should not be in glheader.h.
>>
>> One correct fix is to add an "#include main/compiler.h" to just the files
>> that need it.  It sort of looks like just a few files were missed when the
>> macro was moved.  Easy to miss these since finite is buried inside of other
>> macros.
>>
>> I suppose your solution of forcing the include in all the files does the
>> same thing and may be less fragile.
>>
>> Another fix is to add "finite=_finite" to the list of "-D" compiler options
>> in the mesa and osmesa project files, for all build targets.  Then, the
>> macro definition could be removed from compiler.h.  But this might force a
>> change in the scons build files as well.  I don't know, because I am not
>> familiar with scons.
>>
>> I'll settle on something and submit patches, unless you'd like to do that.
>>
>> Karl
>>
>>
>> On Tue, Jul 21, 2009 at 12:24 PM, Jianrong Shu <jia...@gm...>
>> wrote:
>>> Thanks. My fix to this was to force including 'compiler.h' in the
>>> project settings. Was there a specific reason that you defined the
>>> same macro in two header files?
>>>
>>> Jianrong
>>>
>>> On Mon, Jul 20, 2009 at 11:47 PM, Karl Schultz<kar...@gm...>
>>> wrote:
>>>> It looks like glheader.h (thankfully) got cleaned up quite a bit since
>>>> 7.4.
>>>> In the process, the following was lost:
>>>>
>>>> #if defined(_WIN32) && !defined(__WIN32__) && !defined(__CYGWIN__) &&
>>>> !defined(BUILD_FOR_SNAP)
>>>> #  define __WIN32__
>>>> #  define finite _finite
>>>> #endif
>>>>
>>>>
>>>> Adding back the above will get you going again.
>>>>
>>>> Also, you'll need to:
>>>>
>>>> Add to the mesa project:
>>>>
>>>> cpuinfo.[ch]
>>>> prog_optimize.[ch]
>>>> texgetimage.[ch]
>>>>
>>>> Remove from mesa.def:
>>>>
>>>> _mesa_get_program_register
>>>>
>>>>
>>>> On Fri, Jul 17, 2009 at 4:20 PM, Jianrong Shu <jia...@gm...>
>>>> wrote:
>>>>> I fixed most of the problems except that the linker couldn't find the
>>>>> definition of _finite function, which is Microsoft's implementation of
>>>>> isfinite. The error messages as follows:
>>>>>
>>>>> 1>mesa.lib(s_aatriangle.obj) : error LNK2001: unresolved external
>>>>> symbol
>>>>> _finite
>>>>> 1>mesa.lib(s_aaline.obj) : error LNK2001: unresolved external symbol
>>>>> _finite
>>>>> 1>mesa.lib(prog_execute.obj) : error LNK2019: unresolved external
>>>>> symbol _finite referenced in function __mesa_execute_program
>>>>> 1>mesa.lib(s_triangle.obj) : error LNK2001: unresolved external symbol
>>>>> _finite
>>>>> 1>mesa.lib(s_lines.obj) : error LNK2001: unresolved external symbol
>>>>> _finite
>>>>> 1>mesa.lib(s_points.obj) : error LNK2001: unresolved external symbol
>>>>> _finite
>>>>>
>>>>> This problem might be caused by some settings in the project file, but
>>>>> I couldn't figure out. Any ideas?
>>>>>
>>>>> Thanks,
>>>>> Jianrong
>>>>>
>>>>> On Wed, Jun 24, 2009 at 4:24 PM, Brian Paul<br...@vm...> wrote:
>>>>>> Jianrong Shu wrote:
>>>>>>> Hi there,
>>>>>>>
>>>>>>> I tried to build Mesa 7.5 branch on Windows using Visual Studio 2008
>>>>>>> and the VC8 solution file and got several errors.
>>>>>>>
>>>>>>> First, the "mesa" project included a file "prog_debug.c", which
>>>>>>> doesn't exist. After deleting it from the project, I was able to
>>>>>>> compile it successfully. Then, when building the "gdi" project, I
>>>>>>> got
>>>>>>> the following error messages:
>>>>>>>
>>>>>>> 1>Linking...
>>>>>>> 1>mesa.def : error LNK2001: unresolved external symbol
>>>>>>> _mesa_get_compressed_teximage
>>>>>>> 1>mesa.def : error LNK2001: unresolved external symbol
>>>>>>> _mesa_get_program_register
>>>>>>> 1>mesa.def : error LNK2001: unresolved external symbol
>>>>>>> _mesa_get_teximage
>>>>>>> 1>mesa.def : error LNK2001: unresolved external symbol
>>>>>>> _mglapi_check_multithread
>>>>>>> 1>mesa.def : error LNK2001: unresolved external symbol
>>>>>>> _mglapi_get_proc_address
>>>>>>>
>>>>>>> I also tried the master branch and the same problem exists. Any fix
>>>>>>> to
>>>>>>> this?
>>>>>> The Visual Studio project files haven't been actively maintained
>>>>>> lately
>>>>>> (we've been using scons on Windows).
>>>>>>
>>>>>> If you can provide updated project files, that'd be great.  It's just
>>>>>> a
>>>>>> matter of removing references to old/removed files and adding the new
>>>>>> ones.
>>>>>>
>>>>>> -Brian
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Enter the BlackBerry Developer Challenge
>>>>> This is your chance to win up to $100,000 in prizes! For a limited
>>>>> time,
>>>>> vendors submitting new applications to BlackBerry App World(TM) will
>>>>> have
>>>>> the opportunity to enter the BlackBerry Developer Challenge. See full
>>>>> prize
>>>>> details at: http://p.sf.net/sfu/Challenge
>>>>> _______________________________________________
>>>>> Mesa3d-users mailing list
>>>>> Mes...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
>>>>
>>
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Mesa3d-users mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-users
> .
> 

[Mesa3d-users] Re : [Mesa3d-dev] libdrm-poulsbo & libgl1-mesa-dri-psb

[Nicolas C. <nic...@ym...>]

So, what are the sources that I have when I do apt-get source libgl1-mesa-dri-psb ?

 
________________________________
Nicolas Cadio
ENSSAT, EII3
nc...@en...
cad...@ya...
________________________________





________________________________
De : Julien Cristau <jcr...@de...>
À : Nicolas Cadio <nic...@ym...>
Cc : mes...@li...; mes...@li...
Envoyé le : Lundi, 27 Juillet 2009, 18h28mn 47s
Objet : Re: [Mesa3d-dev] libdrm-poulsbo & libgl1-mesa-dri-psb

On Mon, Jul 27, 2009 at 16:22:37 +0000, Nicolas Cadio wrote:

> So, how I do to compile mesa for Poulsbo ?
> 
You don't.  Poulsbo is a proprietary driver.

Cheers,
Julien



      

[Mesa3d-users] libdrm-poulsbo & libgl1-mesa-dri-psb

[Nicolas C. <nic...@ym...>]

Hi all,

I work on ubuntu 9.04, and I compiled the package libdrm-poulsbo1 (version 2.3.0-ubuntu1~904um1). Now I try to compile libgl1-mesa-dri-psb (version 0.25-0ubuntu1~810um1.1) but there are many errors : 

intel_screen.c: In function ‘intelUpdateScreenFromSAREA’:
intel_screen.c:274: erreur: ‘struct drm_i915_sarea’ has no member named ‘front_bo_handle’
intel_screen.c:275: erreur: ‘struct drm_i915_sarea’ has no member named ‘back_bo_handle’
intel_screen.c:276: erreur: ‘struct drm_i915_sarea’ has no member named ‘third_bo_handle’
intel_screen.c:277: erreur: ‘struct drm_i915_sarea’ has no member named ‘depth_bo_handle’
intel_screen.c: In function ‘intelInitScreen2’:
intel_screen.c:839: erreur: ‘I915_PARAM_CHIPSET_ID’ undeclared (first use in this function)
intel_screen.c:839: erreur: (Each undeclared identifier is reported only once
intel_screen.c:839: erreur: for each function it appears in.)
make[5]: *** [intel_screen.o] Erreur 1
make[5]: quittant le répertoire « /home/innes/temp/build/libgl1-mesa-dri-psb-0.25/src/mesa/drivers/dri/i915 »
make[4]: *** [subdirs] Erreur 1
make[4]: quittant le répertoire « /home/innes/temp/build/libgl1-mesa-dri-psb-0.25/src/mesa/drivers/dri »
make[3]: *** [linux-solo] Erreur 2
make[3]: quittant le répertoire « /home/innes/temp/build/libgl1-mesa-dri-psb-0.25/src/mesa »
make[2]: *** [default] Erreur 1
make[2]: quittant le répertoire « /home/innes/temp/build/libgl1-mesa-dri-psb-0.25/src/mesa »
make[1]: *** [subdirs] Erreur 1
make[1]: quittant le répertoire « /home/innes/temp/build/libgl1-mesa-dri-psb-0.25/src »
make: *** [default] Erreur 1
Failed to make libgl1-mesa-dri-psb-0.25.

In fact, the struture drm_i915_sarea, defined in the file i915_drm.h has no member 'front_bo_handle’.

So, how I do to compile mesa for Poulsbo ?

Thanks

Nico



      

[Mesa3d-users] problem compiling Mesa-7.5 to get GLwCreateMDrawingArea library

[Karl J. <joh...@pi...>]

hi,
My machine: laptop acer ubuntu x86-64
normal compiling Mesa-7.5 works well,
but I need 'GLwCreateMDrawingArea'.
When trying to configurate and compile:

$ configure --enable-motif --disable-gallium --disable-gallium-intel 
--enable-64-bit

I get the output:

*******************************************************************************
> checking build system type... x86_64-unknown-linux-gnu
> checking host system type... x86_64-unknown-linux-gnu
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking how to run the C preprocessor... gcc -E
> checking for gcc... (cached) gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking for g++... g++
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> checking for gmake... no
> checking for make... make
> checking for makedepend... no
> checking for sed... /bin/sed
> checking for pkg-config... /usr/bin/pkg-config
> checking pkg-config is at least version 0.9.0... yes
> checking whether to enable assembly... yes, x86_64
> checking for gcc option to produce PIC... -fPIC
> checking for dlopen... no
> checking for dlopen in -ldl... yes
> checking for posix_memalign... yes
> checking pkg-config files for X11 are available... yes
> checking for LIBDRM... yes
> checking for DRI2PROTO... yes
> checking for DRIGL... yes
> checking expat.h usability... yes
> checking expat.h presence... yes
> checking for expat.h... yes
> checking for XML_ParserCreate in -lexpat... yes
> checking for EGL... yes
> checking for GLW... yes
> checking for motif-config... no
> checking Xm/PrimitiveP.h usability... yes
> checking Xm/PrimitiveP.h presence... yes
> checking for Xm/PrimitiveP.h... yes
> checking for XmGetPixmap in -lXm... yes
> configure: creating ./config.status
> config.status: creating configs/autoconf
> config.status: executing configs commands
>
>       prefix:          /usr/local
>       exec_prefix:     ${prefix}
>       libdir:          ${exec_prefix}/lib
>       includedir:      ${prefix}/include
>
>       Driver:          dri
>       OSMesa:          no
>       DRI drivers:     i915 i965 mach64 mga r128 r200 r300 radeon savage
> tdfx unichrome swrast
>       DRI driver dir:  ${libdir}/dri
>       Use XCB:         no
>
>       Gallium:         no
>
>       Shared libs:     yes
>       Static libs:     no
>       EGL:             yes
>       GLU:             yes
>       GLw:             yes (Motif: yes)
>       glut:            no
>       Demos:           no
>
>       CFLAGS:          -g -O2 -Wall -Wmissing-prototypes -std=c99
> -ffast-math -fno-strict-aliasing -fPIC
>       CXXFLAGS:        -g -O2 -Wall -fno-strict-aliasing -fPIC
>       Macros:          -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DUSE_X86_64_ASM
>
>       Run 'make' to build Mesa
> *****************************************************************************
> $ make
> make[1]: Entering directory `/home/joh/Dokumente/Mesa-7.5/src'
> Making sources for autoconf
> make[2]: Entering directory `/home/joh/Dokumente/Mesa-7.5/src/glx/x11'
> rm -f depend
> touch depend
> fdepend -I/usr/lib/gcc/x86_64-linux-gnu/4.3.3/include
> -I/usr/lib/gcc/x86_64-linux-gnu/4.3.3/include-fixed -I. -I../../../include
> -I../../../include/GL/internal -I../../../src/mesa -I../../../src/mesa/glapi
> -I/usr/include/drm     glcontextmodes.c clientattrib.c compsize.c eval.c
> glxcmds.c glxcurrent.c glxext.c glxextensions.c indirect.c indirect_init.c
> indirect_size.c indirect_window_pos.c indirect_texture_compression.c
> indirect_transpose_matrix.c indirect_vertex_array.c
> indirect_vertex_program.c pixel.c pixelstore.c render2.c renderpix.c
> single2.c singlepix.c vertarr.c xfont.c glx_pbuffer.c glx_query.c
> drisw_glx.c dri_common.c dri_glx.c XF86dri.c glxhash.c dri2_glx.c dri2.c \
>       ../../../src/mesa/main/dispatch.c ../../../src/mesa/glapi/glapi.c
> ../../../src/mesa/glapi/glapi_getproc.c ../../../src/mesa/glapi/glthread.c
> ../../../src/mesa/x86-64/glapi_x86-64.S
> /bin/bash: fdepend: command not found
> make[2]: [depend] Error 127 (ignored)
> make[2]: Leaving directory `/home/joh/Dokumente/Mesa-7.5/src/glx/x11'
> make[2]: Entering directory `/home/joh/Dokumente/Mesa-7.5/src/glx/x11'
> gcc -c -I. -I../../../include -I../../../include/GL/internal
> -I../../../src/mesa -I../../../src/mesa/glapi -I/usr/include/drm     -g -O2
> -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -m64
>  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DXF86VIDMODE -D_REENTRANT
> -UIN_DRI_DRIVER -DDEFAULT_DRIVER_DIR=\"/usr/local/lib/dri\" glcontextmodes.c
> -o glcontextmodes.o
> glcontextmodes.c:42:23: error: GL/glxint.h: No such file or directory
> In file included from glcontextmodes.c:67:
> glcontextmodes.h:39: warning: type defaults to 'int' in declaration of
> '__GLXvisualConfig'
> glcontextmodes.h:39: error: expected ';', ',' or ')' before '*' token
> glcontextmodes.c:132: warning: type defaults to 'int' in declaration of
> '__GLXvisualConfig'
> glcontextmodes.c:132: error: expected ';', ',' or ')' before '*' token
> make[2]: *** [glcontextmodes.o] Error 1
> make[2]: Leaving directory `/home/joh/Dokumente/Mesa-7.5/src/glx/x11'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/home/joh/Dokumente/Mesa-7.5/src'
> *****************************************************************************************************************
$

What can I do?
Thanks
Karl

(Karl Johannsen)

Re: [Mesa3d-users] Capture Window pixel values using glReadPixels

[Srimal J. <sr...@gm...>]

Thanks a lot tom

Your right .

I've changed everything to C style and , removed the iostream.h and
included stdio.h

and it works now.

Regs

Srimal.

On Mon, Jul 27, 2009 at 11:02 AM, tom fogal<tf...@al...> wrote:
> Srimal Jayawardena <sr...@gm...> writes:
>>         GLvoid* data;
>>         data =3D (GLvoid *) malloc (1024*768);
>>         glReadPixels (0,0,1024,768,GL_RED, GL_UNSIGNED_BYTE, data);
>>         for(int i=3D0; i<1024*768; i++)
>>         cout << data[i];
>>         free(data);
>>
>> But it gives this error:
>>
>> $ make
>> g++ -Wall -o render main.cpp -lglut
>> main.cpp: In function =E2=80=98void drawScene()=E2=80=99:
>> main.cpp:154: error: pointer of type =E2=80=98void *=E2=80=99 used in arith=
>> metic
>> main.cpp:154: error: =E2=80=98GLvoid*=E2=80=99 is not a pointer-to-object t=
>> ype
>> make: *** [render] Error 1
>>
>> Am I missing something here?
>
> Yep.  In short, your types are wrong.  You can't have a void object, so
> you can't directly dereference a void pointer.  Try a GLubyte instead.
>
> That said, you might want to read up on C.  I suggest the white book:
>
>  http://cm.bell-labs.com/cm/cs/cbook/
>
> Though your `cout' implies you actually want to write C++, contrary to
> malloc/free.  Stroustrup's book is the classic text here:
>
>  http://www.research.att.com/~bs/3rd.html
>
>> Is there a better way to do this?
>
> Somewhere in the Mesa demos (IIRC) there's some code for reading the
> current image buffer into a ppm file.  If not there, some simple
> googling should bring up code to do this.
>
> -tom
>



-- 
~
Srimal Jayawardena
BSc (Engineering), BIT, MIET
PhD Student, Australian National University.

Phone(Offilce): 0011 612 6125 1771
Phone(Home): 0011 612 6125 5413

ANU Contact Info : http://arp.anu.edu.au/user/3788

http://srimal.sri-lankan.net/
http://srimal-techdiary.blogspot.com/

Re: [Mesa3d-users] Capture Window pixel values using glReadPixels

[tom f. <tf...@al...>]

Srimal Jayawardena <sr...@gm...> writes:
>         GLvoid* data;
>         data =3D (GLvoid *) malloc (1024*768);
>         glReadPixels (0,0,1024,768,GL_RED, GL_UNSIGNED_BYTE, data);
>         for(int i=3D0; i<1024*768; i++)
>         cout << data[i];
>         free(data);
> 
> But it gives this error:
> 
> $ make
> g++ -Wall -o render main.cpp -lglut
> main.cpp: In function =E2=80=98void drawScene()=E2=80=99:
> main.cpp:154: error: pointer of type =E2=80=98void *=E2=80=99 used in arith=
> metic
> main.cpp:154: error: =E2=80=98GLvoid*=E2=80=99 is not a pointer-to-object t=
> ype
> make: *** [render] Error 1
> 
> Am I missing something here?

Yep.  In short, your types are wrong.  You can't have a void object, so
you can't directly dereference a void pointer.  Try a GLubyte instead.

That said, you might want to read up on C.  I suggest the white book:

  http://cm.bell-labs.com/cm/cs/cbook/

Though your `cout' implies you actually want to write C++, contrary to
malloc/free.  Stroustrup's book is the classic text here:

  http://www.research.att.com/~bs/3rd.html

> Is there a better way to do this?

Somewhere in the Mesa demos (IIRC) there's some code for reading the
current image buffer into a ppm file.  If not there, some simple
googling should bring up code to do this.

-tom

[Mesa3d-users] Capture Window pixel values using glReadPixels

[Srimal J. <sr...@gm...>]

Hi

I'm new to mesa(and OpenGL) .

I need to get the pixel values of whats rendered on screen (window) to a
text file for an Image Recognition Application.

First I tried to just print the values on screen using this code:

        GLvoid* data;
        data = (GLvoid *) malloc (1024*768);
        glReadPixels (0,0,1024,768,GL_RED, GL_UNSIGNED_BYTE, data);
        for(int i=0; i<1024*768; i++)
        cout << data[i];
        free(data);

But it gives this error:

$ make
g++ -Wall -o render main.cpp -lglut
main.cpp: In function ‘void drawScene()’:
main.cpp:154: error: pointer of type ‘void *’ used in arithmetic
main.cpp:154: error: ‘GLvoid*’ is not a pointer-to-object type
make: *** [render] Error 1


Am I missing something here?

Is there a better way to do this?

Thanks in advance

Srimal.
~
Srimal Jayawardena
BSc (Engineering), BIT, MIET
PhD Student, Australian National University.

Phone(Offilce): 0011 612 6125 1771
Phone(Home): 0011 612 6125 5413

ANU Contact Info : http://arp.anu.edu.au/user/3788

http://srimal.sri-lankan.net/
http://srimal-techdiary.blogspot.com/

Re: [Mesa3d-users] Software driver support

[tom f. <tf...@al...>]

Jason Erickson <vip...@gm...> writes:
> Thank you very much.  That helped me get the game up.

You're welcome, glad you got it working.

> I understand the patent issue and maybe this isnt something you
> can fix, but using compressed DXT1 all of the alpha showed on the
> images with a greyish background instead of the actual color.  For my
> purposes this isnt an end game issue (automated testing that doesnt
> care about graphics.) however it would be nice to fix.  If a screen
> shot is required I will talk to my bosses to see if that can be sent.

I should clarify that I'm not a Mesa developer.  That said, I think you
should file a bug for this.  A screenshot is a great idea and I imagine
very useful.

> I do have another issue.  Our games run on multi-monitor setups.
> When using mesa3d, everything seems to be drawn only on the last
> monitor initialize (in our case usually monitor #2 or #3).  This does
> not occur using hardware opengl.

I take it you're running the "xlib" driver, then (e.g. via `./configure
--with-driver=xlib')?  You might want to see if any of the environment
variables Mesa provides for debugging are relevant.

  http://mesa3d.org/envvars.html

Regardless, I think you should file this as another bug.  Note how
you build Mesa in both cases, and it would probably save a level of
runaround if you'd test with the recently-released 7.5 version before
submitting.


You can report bugs at https://bugs.freedesktop.org/ .

Cheers,

-tom

> On Fri, Jul 24, 2009 at 11:19 AM, tom fogal<tf...@al...> wrote:
> > Jason Erickson <vip...@gm...> writes:
> >> My problem is that it doesnt support GL_COMPRESSED_RGB_S3TC_DXT1_EXT
> >> for 2D textures.  Whenever I try to get my program to run the mesa3d
> >> dll returns an invalid enum.
> > [snip]
> >> So I'm basically asking if support for GL_COMPRESSED_RGB_S3TC_DXT1_EXT
> >> can be added to the software driver.
> >
> > You can enable this yourself by hacking extensions.c, I would bet
> > (haven't tested, just looks like it).  That texture compression format
> > is protected by patents; it doesn't seem like a good idea to rely on
> > your users having it.  From previous responses on a related subject,
> > I would say it's unlikely to get enabled by default until the patent
> > issue is fixed.
> >
> > Check the "IP Status" of:
> >  http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3t
> c.txt
> >
> > I've never played with compressed textures myself, but it seems like
> > one can do so in a `generic' way -- just use a non-algorithm-specific
> > compression format such as GL_COMPRESSED_RGB_ARB.  ref. ``The OpenGL
> > Extensions Guide'':
> >
> >  http://books.google.com/books?id=VDqw6MK5NJMC&pg=PA89&lpg=PA89&dq=opengl+co
> mpressed+texture+formats&source=bl&ots=VbV-79E47J&sig=avobPE2x-usa6DZp4xHFpjI
> GHNU&hl=en&ei=mPlpSu6cEIzgswPakP2WBQ&sa=X&oi=book_result&ct=result&resnum=1
> >
> > Cheers,
> >
> > -tom
> >

Re: [Mesa3d-users] Software driver support

[Jason E. <vip...@gm...>]

Thank you very much.  That helped me get the game up.  I understand
the patent issue and maybe this isnt something you can fix, but using
compressed DXT1 all of the alpha showed on the images with a greyish
background instead of the actual color.  For my purposes this isnt an
end game issue (automated testing that doesnt care about graphics.)
however it would be nice to fix.  If a screen shot is required I will
talk to my bosses to see if that can be sent.

I do have another issue.  Our games run on multi-monitor setups.  When
using mesa3d, everything seems to be drawn only on the last monitor
initialize (in our case usually monitor #2 or #3).  This does not
occur using hardware opengl.

On Fri, Jul 24, 2009 at 11:19 AM, tom fogal<tf...@al...> wrote:
> Jason Erickson <vip...@gm...> writes:
>> My problem is that it doesnt support GL_COMPRESSED_RGB_S3TC_DXT1_EXT
>> for 2D textures.  Whenever I try to get my program to run the mesa3d
>> dll returns an invalid enum.
> [snip]
>> So I'm basically asking if support for GL_COMPRESSED_RGB_S3TC_DXT1_EXT
>> can be added to the software driver.
>
> You can enable this yourself by hacking extensions.c, I would bet
> (haven't tested, just looks like it).  That texture compression format
> is protected by patents; it doesn't seem like a good idea to rely on
> your users having it.  From previous responses on a related subject,
> I would say it's unlikely to get enabled by default until the patent
> issue is fixed.
>
> Check the "IP Status" of:
>  http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt
>
> I've never played with compressed textures myself, but it seems like
> one can do so in a `generic' way -- just use a non-algorithm-specific
> compression format such as GL_COMPRESSED_RGB_ARB.  ref. ``The OpenGL
> Extensions Guide'':
>
>  http://books.google.com/books?id=VDqw6MK5NJMC&pg=PA89&lpg=PA89&dq=opengl+compressed+texture+formats&source=bl&ots=VbV-79E47J&sig=avobPE2x-usa6DZp4xHFpjIGHNU&hl=en&ei=mPlpSu6cEIzgswPakP2WBQ&sa=X&oi=book_result&ct=result&resnum=1
>
> Cheers,
>
> -tom
>

Re: [Mesa3d-users] Software driver support

[tom f. <tf...@al...>]

Jason Erickson <vip...@gm...> writes:
> My problem is that it doesnt support GL_COMPRESSED_RGB_S3TC_DXT1_EXT
> for 2D textures.  Whenever I try to get my program to run the mesa3d
> dll returns an invalid enum.
[snip]
> So I'm basically asking if support for GL_COMPRESSED_RGB_S3TC_DXT1_EXT
> can be added to the software driver.

You can enable this yourself by hacking extensions.c, I would bet
(haven't tested, just looks like it).  That texture compression format
is protected by patents; it doesn't seem like a good idea to rely on
your users having it.  From previous responses on a related subject,
I would say it's unlikely to get enabled by default until the patent
issue is fixed.

Check the "IP Status" of:
  http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt

I've never played with compressed textures myself, but it seems like
one can do so in a `generic' way -- just use a non-algorithm-specific
compression format such as GL_COMPRESSED_RGB_ARB.  ref. ``The OpenGL
Extensions Guide'':

  http://books.google.com/books?id=VDqw6MK5NJMC&pg=PA89&lpg=PA89&dq=opengl+compressed+texture+formats&source=bl&ots=VbV-79E47J&sig=avobPE2x-usa6DZp4xHFpjIGHNU&hl=en&ei=mPlpSu6cEIzgswPakP2WBQ&sa=X&oi=book_result&ct=result&resnum=1

Cheers,

-tom

[Mesa3d-users] Software driver support

[Jason E. <vip...@gm...>]

I'm currently am trying to use mesa3d in a VMware environment.  I
compile it on a Windows XP and then copy the DLLs into the VMware
environment (Also running Windows XP).

My problem is that it doesnt support GL_COMPRESSED_RGB_S3TC_DXT1_EXT
for 2D textures.  Whenever I try to get my program to run the mesa3d
dll returns an invalid enum.  I tracked it down to the
compressed_texture_error_check and the check that calls
is_compressed_format.  If I uncompress my textures mesa3d runs just
fine.  On the host machine the compressed textures run fine as well.

So I'm basically asking if support for GL_COMPRESSED_RGB_S3TC_DXT1_EXT
can be added to the software driver.

[Mesa3d-users] Mesa with a Poulsbo chipset

[Nicolas C. <nic...@ym...>]

Hi,

I work on Ubuntu 9.04 and I try to compil and install mesa. My PC has a poulsbo chipset, so I have installed the librairies : 
    libdrm-poulsbo1 (version 2.3.0)
    libdrm-poulsbo-dev (version 2.3.0)
    libdrm-poulsbo1-dbg (version 2.3.0)

Now, i try to compil libgl1-mesa-dri-psb (version 0.25 - Implementation of the OpenGl API -- for Pouslbo (psb)). But the configure of the libgl1-mesa-dri-psb needs the version 2.3.1 of libdrm. But I don't found libdrm-poulsbo1-2.3.1.

So, I have modified the varaible LIBDRM_REQUIRED (LIBDRM_REQUIRED=2.3.0 #My version of libdrm-poulsbo) of the configure of libgl1-mesa-dri-psb.

I recompile  libgl1-mesa-dri-psb, but there is an error :
intel_screen.c:839: erreur: 'I915_PARAM_CHIPSET_ID' undeclared (first use in this function)

How do to succes to compile mesa with a poulsbo chipset ???
Thanks



 
________________________________
Nicolas Cadio
ENSSAT, EII3
nc...@en...
cad...@ya...
________________________________