Menu
▾
▴
mesa3d-users
|
From: Brian P. <bri...@tu...> - 2008-05-27 19:53:18
|
The first release candidate of Mesa 7.1 (new development release) can be grabbed from http://www.mesa3d.org/beta This has been tagged in git as mesa_7_1_rc1 There's a lot of new code, the new auto-conf build system, etc. so it's important that people grab these tarballs and test. -Brian |
|
From: Benno S. <ben...@ju...> - 2008-05-27 21:32:18
|
Brian Paul wrote: > The first release candidate of Mesa 7.1 (new development release) > can be grabbed from http://www.mesa3d.org/beta Where do I find a packaged libdrm-2.3.1 or higher to go with it? Gentoo doesn't seem to have it yet. Benno |
|
From: Brian P. <bri...@tu...> - 2008-05-28 15:13:09
|
Benno Schulenberg wrote: > Brian Paul wrote: >> The first release candidate of Mesa 7.1 (new development release) >> can be grabbed from http://www.mesa3d.org/beta > > Where do I find a packaged libdrm-2.3.1 or higher to go with it? > Gentoo doesn't seem to have it yet. I think Dave Airlie is still working on it... -Brian |
|
From: sdc395 <mes...@de...> - 2008-05-28 09:32:36
|
I've attempted to build 7.1 RC 1 using Visual Studio 2005 and can report the following issues... Building mesa... > \src\mesa\main\texcompress_fxt1.c(668) : warning C4293: '<<' : shift count > negative or too big, undefined behavior > \src\mesa\main\texcompress_fxt1.c(715) : warning C4293: '<<' : shift count > negative or too big, undefined behavior > \src\mesa\main\texcompress_fxt1.c(721) : warning C4293: '<<' : shift count > negative or too big, undefined behavior > \src\mesa\main\texcompress_fxt1.c(886) : warning C4293: '<<' : shift count > negative or too big, undefined behavior > \src\mesa\main\texcompress_fxt1.c(892) : warning C4293: '<<' : shift count > negative or too big, undefined behavior > \src\mesa\main\texcompress_fxt1.c(1106) : warning C4293: '<<' : shift > count negative or too big, undefined behavior > \src\mesa\main\texcompress_fxt1.c(1275) : warning C4293: '<<' : shift > count negative or too big, undefined behavior > Can't Fx64 by typedef'd as unsigned __int64 rather then using that generic struct solution? Building gdi... > \src\mesa\drivers\windows\gdi\wgl.c(606) : warning C4013: > 'WMesaShareLists' undefined; assuming extern returning int > > mesa.def : error LNK2001: unresolved external symbol _mesa_attach_shader > mesa.def : error LNK2001: unresolved external symbol > _mesa_bind_attrib_location > mesa.def : error LNK2001: unresolved external symbol _mesa_compile_shader > mesa.def : error LNK2001: unresolved external symbol _mesa_create_program > mesa.def : error LNK2001: unresolved external symbol _mesa_create_shader > mesa.def : error LNK2001: unresolved external symbol _mesa_delete_program2 > mesa.def : error LNK2001: unresolved external symbol _mesa_delete_shader > mesa.def : error LNK2001: unresolved external symbol _mesa_detach_shader > mesa.def : error LNK2001: unresolved external symbol > _mesa_get_active_attrib > mesa.def : error LNK2001: unresolved external symbol > _mesa_get_active_uniform > mesa.def : error LNK2001: unresolved external symbol > _mesa_get_attached_shaders > mesa.def : error LNK2001: unresolved external symbol > _mesa_get_attrib_location > mesa.def : error LNK2001: unresolved external symbol _mesa_get_handle > mesa.def : error LNK2001: unresolved external symbol > _mesa_get_program_info_log > mesa.def : error LNK2001: unresolved external symbol _mesa_get_programiv > mesa.def : error LNK2001: unresolved external symbol > _mesa_get_shader_info_log > mesa.def : error LNK2001: unresolved external symbol > _mesa_get_shader_source > mesa.def : error LNK2001: unresolved external symbol _mesa_get_shaderiv > mesa.def : error LNK2001: unresolved external symbol > _mesa_get_uniform_location > mesa.def : error LNK2001: unresolved external symbol _mesa_get_uniformfv > mesa.def : error LNK2001: unresolved external symbol _mesa_is_program > mesa.def : error LNK2001: unresolved external symbol _mesa_is_shader > mesa.def : error LNK2001: unresolved external symbol _mesa_link_program > mesa.def : error LNK2001: unresolved external symbol _mesa_shader_source > mesa.def : error LNK2001: unresolved external symbol _mesa_uniform > mesa.def : error LNK2001: unresolved external symbol _mesa_uniform_matrix > mesa.def : error LNK2001: unresolved external symbol > _mesa_validate_program > All of those unresolved functions are defined as static in shader_api.c Also, it would be nice to have the project dependencies configured in the solution file. It would save me having to do it every time I download a new version. Might this release have addressed the heap corruption issue I reported? Brian Paul wrote: > > > The first release candidate of Mesa 7.1 (new development release) can be > grabbed from http://www.mesa3d.org/beta > > This has been tagged in git as mesa_7_1_rc1 > > There's a lot of new code, the new auto-conf build system, etc. so it's > important that people grab these tarballs and test. > > > -Brian > -- View this message in context: http://www.nabble.com/Mesa-7.1-release-candidate-1-tp17498578p17508617.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: sdc395 <mes...@de...> - 2008-05-28 10:59:42
|
The following functions also appear to be missing from mesa.def... > _mesa_init_glsl_driver_functions > _mesa_generate_mipmap > _mesa_enable_2_1_extensions > _mesa_enable_2_0_extensions > -- View this message in context: http://www.nabble.com/Mesa-7.1-release-candidate-1-tp17498578p17510116.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: Brian P. <bri...@tu...> - 2008-05-28 15:05:41
Attachments:
mesa.def
|
sdc395 wrote: > I've attempted to build 7.1 RC 1 using Visual Studio 2005 and can report the > following issues... > > Building mesa... > > >> \src\mesa\main\texcompress_fxt1.c(668) : warning C4293: '<<' : shift count >> negative or too big, undefined behavior >> \src\mesa\main\texcompress_fxt1.c(715) : warning C4293: '<<' : shift count >> negative or too big, undefined behavior >> \src\mesa\main\texcompress_fxt1.c(721) : warning C4293: '<<' : shift count >> negative or too big, undefined behavior >> \src\mesa\main\texcompress_fxt1.c(886) : warning C4293: '<<' : shift count >> negative or too big, undefined behavior >> \src\mesa\main\texcompress_fxt1.c(892) : warning C4293: '<<' : shift count >> negative or too big, undefined behavior >> \src\mesa\main\texcompress_fxt1.c(1106) : warning C4293: '<<' : shift >> count negative or too big, undefined behavior >> \src\mesa\main\texcompress_fxt1.c(1275) : warning C4293: '<<' : shift >> count negative or too big, undefined behavior >> > > Can't Fx64 by typedef'd as unsigned __int64 rather then using that generic > struct solution? The code in that file should probably just be rewritten to use the GLuint64EXT type that's defined in glext.h. I may take a stab at that later. > > Building gdi... > > >> \src\mesa\drivers\windows\gdi\wgl.c(606) : warning C4013: >> 'WMesaShareLists' undefined; assuming extern returning int >> >> mesa.def : error LNK2001: unresolved external symbol _mesa_attach_shader >> mesa.def : error LNK2001: unresolved external symbol >> _mesa_bind_attrib_location >> mesa.def : error LNK2001: unresolved external symbol _mesa_compile_shader >> mesa.def : error LNK2001: unresolved external symbol _mesa_create_program >> mesa.def : error LNK2001: unresolved external symbol _mesa_create_shader >> mesa.def : error LNK2001: unresolved external symbol _mesa_delete_program2 >> mesa.def : error LNK2001: unresolved external symbol _mesa_delete_shader >> mesa.def : error LNK2001: unresolved external symbol _mesa_detach_shader >> mesa.def : error LNK2001: unresolved external symbol >> _mesa_get_active_attrib >> mesa.def : error LNK2001: unresolved external symbol >> _mesa_get_active_uniform >> mesa.def : error LNK2001: unresolved external symbol >> _mesa_get_attached_shaders >> mesa.def : error LNK2001: unresolved external symbol >> _mesa_get_attrib_location >> mesa.def : error LNK2001: unresolved external symbol _mesa_get_handle >> mesa.def : error LNK2001: unresolved external symbol >> _mesa_get_program_info_log >> mesa.def : error LNK2001: unresolved external symbol _mesa_get_programiv >> mesa.def : error LNK2001: unresolved external symbol >> _mesa_get_shader_info_log >> mesa.def : error LNK2001: unresolved external symbol >> _mesa_get_shader_source >> mesa.def : error LNK2001: unresolved external symbol _mesa_get_shaderiv >> mesa.def : error LNK2001: unresolved external symbol >> _mesa_get_uniform_location >> mesa.def : error LNK2001: unresolved external symbol _mesa_get_uniformfv >> mesa.def : error LNK2001: unresolved external symbol _mesa_is_program >> mesa.def : error LNK2001: unresolved external symbol _mesa_is_shader >> mesa.def : error LNK2001: unresolved external symbol _mesa_link_program >> mesa.def : error LNK2001: unresolved external symbol _mesa_shader_source >> mesa.def : error LNK2001: unresolved external symbol _mesa_uniform >> mesa.def : error LNK2001: unresolved external symbol _mesa_uniform_matrix >> mesa.def : error LNK2001: unresolved external symbol >> _mesa_validate_program >> > > All of those unresolved functions are defined as static in shader_api.c I'm attaching a new mesa.def file. Could you please try it and see if that fixes these errors? > Also, it would be nice to have the project dependencies configured in the > solution file. It would save me having to do it every time I download a new > version. I'm not familiar with that. Maybe a Windows developer can contribute what's needed. > Might this release have addressed the heap corruption issue I reported? Can you remind me what that was? Did you file a bug report? -Brian |
|
From: sdc395 <mes...@de...> - 2008-05-28 15:56:18
|
Brian Paul wrote: > > I'm attaching a new mesa.def file. Could you please try it and see if > that fixes these errors? > That new mesa.def file has done the trick - no more linking problems. Brian Paul wrote: > >> Also, it would be nice to have the project dependencies configured in the >> solution file. It would save me having to do it every time I download a >> new >> version. > > I'm not familiar with that. Maybe a Windows developer can contribute > what's needed. > I'd happily contribute. Could you point me in the direction of instructions on how I go about this? Brian Paul wrote: > >> Might this release have addressed the heap corruption issue I reported? > > Can you remind me what that was? Did you file a bug report? > That was http://www.nabble.com/Heap-Corruption--to16558747.html this issue . I was hoping someone would attempt to recreate the problem before I took it any further. I'm wondering if it is related to http://www.nabble.com/Using-QGLWidget-with-MESA-to17514038.html this one . -- View this message in context: http://www.nabble.com/Mesa-7.1-release-candidate-1-tp17498578p17515986.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: Brian P. <bri...@tu...> - 2008-05-28 16:02:06
|
sdc395 wrote: > > Brian Paul wrote: >> I'm attaching a new mesa.def file. Could you please try it and see if >> that fixes these errors? >> > That new mesa.def file has done the trick - no more linking problems. OK, it's in git and will be in the next release candidate. > Brian Paul wrote: >>> Also, it would be nice to have the project dependencies configured in the >>> solution file. It would save me having to do it every time I download a >>> new >>> version. >> I'm not familiar with that. Maybe a Windows developer can contribute >> what's needed. >> > I'd happily contribute. Could you point me in the direction of instructions > on how I go about this? I'm not a Windows developer so you probably know more about it than me. Anyone else? > Brian Paul wrote: >>> Might this release have addressed the heap corruption issue I reported? >> Can you remind me what that was? Did you file a bug report? >> > > That was http://www.nabble.com/Heap-Corruption--to16558747.html this issue > . I was hoping someone would attempt to recreate the problem before I took > it any further. I'm wondering if it is related to > http://www.nabble.com/Using-QGLWidget-with-MESA-to17514038.html this one . If this were on Linux, I'd use valgrind to track down the problem. I think Purify would be the Windows equivalent. -Brian |
|
From: Karl S. <k.w...@co...> - 2008-05-28 16:07:22
|
On Wed, May 28, 2008 at 10:01 AM, Brian Paul < bri...@tu...> wrote: > sdc395 wrote: > > Brian Paul wrote: > >>> Also, it would be nice to have the project dependencies configured in > the > >>> solution file. It would save me having to do it every time I download > a > >>> new > >>> version. > >> I'm not familiar with that. Maybe a Windows developer can contribute > >> what's needed. > >> > > I'd happily contribute. Could you point me in the direction of > instructions > > on how I go about this? > > I'm not a Windows developer so you probably know more about it than me. > Anyone else? > > I believe that the project dependencies are already in place. Brian, this was what the mesa.sln update was about that I sent you this week. It was missing ONE dependency. As it stands now, in the RC, mesa.sln has the following deps: osmesa -> gdi mesa -> <nothing> glu-> gdi (this is the one that was missing before Monday) gdi -> mesa There is also a defined project build order: mesa gdi glu osmesa which seems correct to me. Perhaps "sdc395" can explain what is missing? Karl |
|
From: sdc395 <mes...@de...> - 2008-05-28 16:37:44
|
Karl Schultz-2 wrote: > > I believe that the project dependencies are already in place. Brian, this > was what the mesa.sln update was about that I sent you this week. It was > missing ONE dependency. > > Perhaps "sdc395" can explain what is missing? > > Karl > My apologies. I think I assumed some of my linking problems were down to build dependencies/order which was not defined in the 7.0.3 solution file. I should have checked. RC1 is fine. Sorry. However, I did need to add prog_uniform.c and prog_uniform.h to the mesa project file before gdi would build correctly. With regard to making contributions; I meant to ask how I go about submitting contributions rather than how to configure project dependencies. By the way, should I be posting these sorts of questions to mesa3d-dev or is this the right place? Simon -- View this message in context: http://www.nabble.com/Mesa-7.1-release-candidate-1-tp17498578p17516913.html Sent from the mesa3d-users mailing list archive at Nabble.com. |
|
From: Karl S. <k.w...@co...> - 2008-05-28 16:56:52
|
On Wed, May 28, 2008 at 10:37 AM, sdc395 <mes...@de...> wrote: > > > Karl Schultz-2 wrote: > > > > I believe that the project dependencies are already in place. Brian, > this > > was what the mesa.sln update was about that I sent you this week. It was > > missing ONE dependency. > > > > Perhaps "sdc395" can explain what is missing? > > > > Karl > > > My apologies. I think I assumed some of my linking problems were down to > build dependencies/order which was not defined in the 7.0.3 solution file. > I should have checked. RC1 is fine. Sorry. > > However, I did need to add prog_uniform.c and prog_uniform.h to the mesa > project file before gdi would build correctly. > Project files frequently get out of date as files are added. Brian, I'm building the RC later today, and I'll send you the updated project file, unless you've done it already. > With regard to making contributions; I meant to ask how I go about > submitting contributions rather than how to configure project dependencies. > I think start with mesa3d.org. You also need to apply at freedesktop.orgfor an account and I think that full instructions are there. Git is used for the repository and was at one time hard to use from Windows. I used to submit changes myself until the switch to git. Recently I've sent whatever few changes I had to Brian. But I think that the situation with git and Windows has gotten better and I'll look into again if I ever intend to update more than a few files. > > By the way, should I be posting these sorts of questions to mesa3d-dev or > is > this the right place? > I would guess talk about RC's on both, and "how to contribute" more on dev. Karl |
Thanks for helping keep SourceForge clean.
X