mesa3d-dev

Re: [Mesa3d-dev] Commit messages broken??

[Zack R. <za...@vm...>]

On Wednesday 10 March 2010 14:59:42 Zack Rusin wrote:
> Maybe /usr/bin/mail is broken, I'll double check it.

Yea, that's it. Someone installed a new mail daemon on the server. We're using 
"-a" to specify the Content-Type header in mails, but the heirloom mailx that 
has been installed uses the "-a" option to specify attachments and since 
filename "Content-Type: text/plain;" is not a valid filename it exits with an 
error. I'll try to fix it right now.
BTW, replacing a mail client on the server with something that's not 
compatible is not very social.

z

Re: [Mesa3d-dev] Commit messages broken??

[Dan N. <dbn...@gm...>]

On Wed, Mar 10, 2010 at 11:59 AM, Zack Rusin <za...@vm...> wrote:
> On Wednesday 10 March 2010 13:59:40 Brian Paul wrote:
>> Brian Paul wrote:
>> > Keith Whitwell wrote:
>> >> I haven't seen any of these for a while now...  Anyone have any ideas?
>> >
>> > I haven't seen them either.  I don't know what's going on, but Tollef
>> > Fog Heen (an FD.org admin) created new mesa lists on fd.o yesterday
>> > (though Michel and I haven't move the subscriber lists yet).  Perhaps
>> > something broke from that?
>> >
>> > Tollef?
>>
>> It looks like the list itself is OK but the git trigger to send out
>> the commit messages isn't working.
>>
>> Do any git experts know what might be wrong?
>
> I wrote that script and looked at it yesterday and I don't see what's wrong.
> The script uses /usr/bin/mail to send those mails. Has something changed on
> the server? Maybe /usr/bin/mail is broken, I'll double check it.

Maybe the mesa-commit subscriber/whitelist configuration got
overwritten in the list conversion and the user sending the commit
messages is not allowed to post anymore. You could look in the
moderation queue.

--
Dan

Re: [Mesa3d-dev] Commit messages broken??

[Mark M. <mar...@gm...>]

On Wed, Mar 10, 2010 at 12:59 PM, Zack Rusin <za...@vm...> wrote:

> On Wednesday 10 March 2010 13:59:40 Brian Paul wrote:
> > Brian Paul wrote:
> > > Keith Whitwell wrote:
> > >> I haven't seen any of these for a while now...  Anyone have any ideas?
> > >
> > > I haven't seen them either.  I don't know what's going on, but Tollef
> > > Fog Heen (an FD.org admin) created new mesa lists on fd.o yesterday
> > > (though Michel and I haven't move the subscriber lists yet).  Perhaps
> > > something broke from that?
> > >
> > > Tollef?
> >
> > It looks like the list itself is OK but the git trigger to send out
> > the commit messages isn't working.
> >
> > Do any git experts know what might be wrong?
>
> I wrote that script and looked at it yesterday and I don't see what's
> wrong.
> The script uses /usr/bin/mail to send those mails. Has something changed on
> the server? Maybe /usr/bin/mail is broken, I'll double check it.
>
>
I can see the headline now:

Mesa3d-dev Mail Mauled by Mangey Monster

and it's no surprise Zack jumps to the rescue, given his background with
monsters.

Re: [Mesa3d-dev] Commit messages broken??

[Zack R. <za...@vm...>]

On Wednesday 10 March 2010 13:59:40 Brian Paul wrote:
> Brian Paul wrote:
> > Keith Whitwell wrote:
> >> I haven't seen any of these for a while now...  Anyone have any ideas?
> >
> > I haven't seen them either.  I don't know what's going on, but Tollef
> > Fog Heen (an FD.org admin) created new mesa lists on fd.o yesterday
> > (though Michel and I haven't move the subscriber lists yet).  Perhaps
> > something broke from that?
> >
> > Tollef?
> 
> It looks like the list itself is OK but the git trigger to send out
> the commit messages isn't working.
> 
> Do any git experts know what might be wrong?

I wrote that script and looked at it yesterday and I don't see what's wrong. 
The script uses /usr/bin/mail to send those mails. Has something changed on 
the server? Maybe /usr/bin/mail is broken, I'll double check it.

Re: [Mesa3d-dev] Piglit fbo tests

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

Maciej Cencora wrote:
> Dnia środa, 10 marca 2010 o 19:35:48 Brian Paul napisał(a):
>> Maciej Cencora wrote:
>>> Dnia środa, 10 marca 2010 o 19:17:25 Maciej Cencora napisał(a):
>>>> Dnia środa, 10 marca 2010 o 16:36:01 Brian Paul napisał(a):
>>>>> Brian Paul wrote:
>>>>>> Maciej Cencora wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> following 3 piglit tests are failing on r300 because they're trying
>>>>>>> to use GL_ARB_texture_non_power_of_two without checking if this
>>>>>>> extension is available:
>>>>>>>
>>>>>>> fbo-blit
>>>>>>> fbo-nodepth-test
>>>>>>> fbo-nostencil-test
>>>>>>>
>>>>>>> I'm not sure what solution is preferable, 1) change the teximage
>>>>>>> sizes to be POT, 2) require ARB_texture_npot.
>>>>>>> I've tried first solution for fbo-blit but it segfaults, trying to
>>>>>>> execute function at null address, so it would require some more
>>>>>>> investigation.
>>>>>> We should use POT texture sizes so that the test always does
>>>>>> _something_.
>>>>> I've fixed the fbo-blit test to use a POT texture.  Maybe you can fix
>>>>> the other tests similarly.
>>>>>
>>>>> BTW, I'm adding additional sub-tests to fbo-blit.c to investigate some
>>>>> other bugs I've recently found...
>>>>>
>>>>> -Brian
>>>> Sure, I'll look into it.
>>>>
>>>> Regards,
>>>> Maciej
>>> It looks like you've forgotten to remove  the ARB_npot check for
>>> fbo-blit.
>> Fixed.
>>
>>> After removing it the tests segfaults.
>>> #0  0x0000000000000000 in ?? ()
>>> #1  0x000000000042cfac in run_test ()
>>> #2  0x000000000042d1f3 in piglit_display ()
>>> #3  0x000000000042e639 in display ()
>>> #4  0x00007ffff7682ddf in processWindowWorkList (window=0x673a90) at
>>> glut_event.c:1306
>>> #5  0x00007ffff7682ef9 in __glutProcessWindowWorkLists () at
>>> glut_event.c:1356 #6  0x00007ffff7682f6f in glutMainLoop () at
>>> glut_event.c:1377
>>> #7  0x000000000042e7b1 in main ()
>>> Unfortunately I don't know how to build the piglit tests with debugging
>>> symbols to investigate it further.
>> Run "ccmake ." and change CMAKE_BUILD_TYPE to "Debug".
>>
>> -Brian
>>
> 
> I'm sending fixes for fbo-blit and fbo-no-depth/stencil-test tests.

Committed.  Thanks.

-Brian

Re: [Mesa3d-dev] Piglit fbo tests

[Maciej C. <m.c...@gm...>]

Dnia środa, 10 marca 2010 o 19:35:48 Brian Paul napisał(a):
> Maciej Cencora wrote:
> > Dnia środa, 10 marca 2010 o 19:17:25 Maciej Cencora napisał(a):
> >> Dnia środa, 10 marca 2010 o 16:36:01 Brian Paul napisał(a):
> >>> Brian Paul wrote:
> >>>> Maciej Cencora wrote:
> >>>>> Hi,
> >>>>>
> >>>>> following 3 piglit tests are failing on r300 because they're trying
> >>>>> to use GL_ARB_texture_non_power_of_two without checking if this
> >>>>> extension is available:
> >>>>>
> >>>>> fbo-blit
> >>>>> fbo-nodepth-test
> >>>>> fbo-nostencil-test
> >>>>>
> >>>>> I'm not sure what solution is preferable, 1) change the teximage
> >>>>> sizes to be POT, 2) require ARB_texture_npot.
> >>>>> I've tried first solution for fbo-blit but it segfaults, trying to
> >>>>> execute function at null address, so it would require some more
> >>>>> investigation.
> >>>>
> >>>> We should use POT texture sizes so that the test always does
> >>>> _something_.
> >>>
> >>> I've fixed the fbo-blit test to use a POT texture.  Maybe you can fix
> >>> the other tests similarly.
> >>>
> >>> BTW, I'm adding additional sub-tests to fbo-blit.c to investigate some
> >>> other bugs I've recently found...
> >>>
> >>> -Brian
> >>
> >> Sure, I'll look into it.
> >>
> >> Regards,
> >> Maciej
> >
> > It looks like you've forgotten to remove  the ARB_npot check for
> > fbo-blit.
> 
> Fixed.
> 
> > After removing it the tests segfaults.
> > #0  0x0000000000000000 in ?? ()
> > #1  0x000000000042cfac in run_test ()
> > #2  0x000000000042d1f3 in piglit_display ()
> > #3  0x000000000042e639 in display ()
> > #4  0x00007ffff7682ddf in processWindowWorkList (window=0x673a90) at
> > glut_event.c:1306
> > #5  0x00007ffff7682ef9 in __glutProcessWindowWorkLists () at
> > glut_event.c:1356 #6  0x00007ffff7682f6f in glutMainLoop () at
> > glut_event.c:1377
> > #7  0x000000000042e7b1 in main ()
> > Unfortunately I don't know how to build the piglit tests with debugging
> > symbols to investigate it further.
> 
> Run "ccmake ." and change CMAKE_BUILD_TYPE to "Debug".
> 
> -Brian
> 

I'm sending fixes for fbo-blit and fbo-no-depth/stencil-test tests.

Regards,
Maciej

Re: [Mesa3d-dev] Commit messages broken??

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

Brian Paul wrote:
> Keith Whitwell wrote:
>> I haven't seen any of these for a while now...  Anyone have any ideas?
> 
> I haven't seen them either.  I don't know what's going on, but Tollef 
> Fog Heen (an FD.org admin) created new mesa lists on fd.o yesterday 
> (though Michel and I haven't move the subscriber lists yet).  Perhaps 
> something broke from that?
> 
> Tollef?


It looks like the list itself is OK but the git trigger to send out 
the commit messages isn't working.

Do any git experts know what might be wrong?

-Brian

Re: [Mesa3d-dev] Piglit fbo tests

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

Maciej Cencora wrote:
> Dnia środa, 10 marca 2010 o 19:17:25 Maciej Cencora napisał(a):
>> Dnia środa, 10 marca 2010 o 16:36:01 Brian Paul napisał(a):
>>> Brian Paul wrote:
>>>> Maciej Cencora wrote:
>>>>> Hi,
>>>>>
>>>>> following 3 piglit tests are failing on r300 because they're trying to
>>>>> use GL_ARB_texture_non_power_of_two without checking if this extension
>>>>> is available:
>>>>>
>>>>> fbo-blit
>>>>> fbo-nodepth-test
>>>>> fbo-nostencil-test
>>>>>
>>>>> I'm not sure what solution is preferable, 1) change the teximage sizes
>>>>> to be POT, 2) require ARB_texture_npot.
>>>>> I've tried first solution for fbo-blit but it segfaults, trying to
>>>>> execute function at null address, so it would require some more
>>>>> investigation.
>>>> We should use POT texture sizes so that the test always does
>>>> _something_.
>>> I've fixed the fbo-blit test to use a POT texture.  Maybe you can fix
>>> the other tests similarly.
>>>
>>> BTW, I'm adding additional sub-tests to fbo-blit.c to investigate some
>>> other bugs I've recently found...
>>>
>>> -Brian
>> Sure, I'll look into it.
>>
>> Regards,
>> Maciej
>>
> 
> It looks like you've forgotten to remove  the ARB_npot check for fbo-blit. 

Fixed.


> After removing it the tests segfaults.
> #0  0x0000000000000000 in ?? ()
> #1  0x000000000042cfac in run_test ()
> #2  0x000000000042d1f3 in piglit_display ()
> #3  0x000000000042e639 in display ()
> #4  0x00007ffff7682ddf in processWindowWorkList (window=0x673a90) at 
> glut_event.c:1306
> #5  0x00007ffff7682ef9 in __glutProcessWindowWorkLists () at glut_event.c:1356
> #6  0x00007ffff7682f6f in glutMainLoop () at glut_event.c:1377
> #7  0x000000000042e7b1 in main ()
> Unfortunately I don't know how to build the piglit tests with debugging 
> symbols to investigate it further.

Run "ccmake ." and change CMAKE_BUILD_TYPE to "Debug".

-Brian

Re: [Mesa3d-dev] Piglit fbo tests

[Maciej C. <m.c...@gm...>]

Dnia środa, 10 marca 2010 o 19:17:25 Maciej Cencora napisał(a):
> Dnia środa, 10 marca 2010 o 16:36:01 Brian Paul napisał(a):
> > Brian Paul wrote:
> > > Maciej Cencora wrote:
> > >> Hi,
> > >>
> > >> following 3 piglit tests are failing on r300 because they're trying to
> > >> use GL_ARB_texture_non_power_of_two without checking if this extension
> > >> is available:
> > >>
> > >> fbo-blit
> > >> fbo-nodepth-test
> > >> fbo-nostencil-test
> > >>
> > >> I'm not sure what solution is preferable, 1) change the teximage sizes
> > >> to be POT, 2) require ARB_texture_npot.
> > >> I've tried first solution for fbo-blit but it segfaults, trying to
> > >> execute function at null address, so it would require some more
> > >> investigation.
> > >
> > > We should use POT texture sizes so that the test always does
> > > _something_.
> >
> > I've fixed the fbo-blit test to use a POT texture.  Maybe you can fix
> > the other tests similarly.
> >
> > BTW, I'm adding additional sub-tests to fbo-blit.c to investigate some
> > other bugs I've recently found...
> >
> > -Brian
> 
> Sure, I'll look into it.
> 
> Regards,
> Maciej
> 

It looks like you've forgotten to remove  the ARB_npot check for fbo-blit. 
After removing it the tests segfaults.
#0  0x0000000000000000 in ?? ()
#1  0x000000000042cfac in run_test ()
#2  0x000000000042d1f3 in piglit_display ()
#3  0x000000000042e639 in display ()
#4  0x00007ffff7682ddf in processWindowWorkList (window=0x673a90) at 
glut_event.c:1306
#5  0x00007ffff7682ef9 in __glutProcessWindowWorkLists () at glut_event.c:1356
#6  0x00007ffff7682f6f in glutMainLoop () at glut_event.c:1377
#7  0x000000000042e7b1 in main ()
Unfortunately I don't know how to build the piglit tests with debugging 
symbols to investigate it further.

Regards,
Maciej

Re: [Mesa3d-dev] Piglit fbo tests

[Maciej C. <m.c...@gm...>]

Dnia środa, 10 marca 2010 o 16:36:01 Brian Paul napisał(a):
> Brian Paul wrote:
> > Maciej Cencora wrote:
> >> Hi,
> >>
> >> following 3 piglit tests are failing on r300 because they're trying to
> >> use GL_ARB_texture_non_power_of_two without checking if this extension
> >> is available:
> >>
> >> fbo-blit
> >> fbo-nodepth-test
> >> fbo-nostencil-test
> >>
> >> I'm not sure what solution is preferable, 1) change the teximage sizes
> >> to be POT, 2) require ARB_texture_npot.
> >> I've tried first solution for fbo-blit but it segfaults, trying to
> >> execute function at null address, so it would require some more
> >> investigation.
> >
> > We should use POT texture sizes so that the test always does _something_.
> 
> I've fixed the fbo-blit test to use a POT texture.  Maybe you can fix
> the other tests similarly.
> 
> BTW, I'm adding additional sub-tests to fbo-blit.c to investigate some
> other bugs I've recently found...
> 
> -Brian
> 

Sure, I'll look into it.

Regards,
Maciej

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[James S. <jsi...@in...>]

> Would anyone have objections if these lists moved to freedesktop.org?
> The recent thread with Linus about the drm pull request highlights the
> post lag and non-subscriber aspect of the current lists, and that
> leaves aside sf.net's horrible mail archive interface and poor
> performance.
> 
> If spam is an issue, another option would be vger.kernel.org.  That
> team runs lkml and several other very high traffic, high profile lists
> and manages quite well; performance is always high and spam is nearly
> non-existent given the amount of traffic.

Just wanted to bring up the experince of moving linux-fbdev from sf.net to 
vger. The reason we did the move was because of the amount of spam we had 
to deal with. Now we have no spam. Of course the draw back is that the old 
list still exist which means the spam still comes in thus it has to be 
dealt with. Not too big of a deal. The real issue is people still join the 
old mailing list and try to post there. Perhaps their is a way to forward 
subscriptions or send a message to the subscriber to tell them where to 
really join? Then you have to send real mail to the new list.  

Re: [Mesa3d-dev] Piglit fbo tests

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

Brian Paul wrote:
> Maciej Cencora wrote:
>> Hi,
>>
>> following 3 piglit tests are failing on r300 because they're trying to use 
>> GL_ARB_texture_non_power_of_two without checking if this extension is 
>> available:
>>
>> fbo-blit
>> fbo-nodepth-test
>> fbo-nostencil-test
>>
>> I'm not sure what solution is preferable, 1) change the teximage sizes to be 
>> POT, 2) require ARB_texture_npot.
>> I've tried first solution for fbo-blit but it segfaults, trying to execute 
>> function at null address, so it would require some more investigation.
> 
> We should use POT texture sizes so that the test always does _something_.

I've fixed the fbo-blit test to use a POT texture.  Maybe you can fix 
the other tests similarly.

BTW, I'm adding additional sub-tests to fbo-blit.c to investigate some 
other bugs I've recently found...

-Brian

Re: [Mesa3d-dev] mesa vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]

[Keith W. <ke...@vm...>]

On Wed, 2010-03-10 at 07:18 -0800, Corbin Simpson wrote:
> On Wed, Mar 10, 2010 at 6:59 AM, Keith Whitwell <ke...@vm...> wrote:
> > It's great you found a bug, but why all the excitement?  Just track it
> > down and propose a fix.  Mesa's pretty well debugged, but there are
> > always going to be new issues.  I'm not sure why it warrants this type
> > of implicit criticism when you come across something new.
> 
> I wasn't aware of any implicit criticism in my post. If I said
> something wrong, I'm sorry; I'm a little bit fried from studying for a
> final, and what started as a relaxing diversion from math review has
> kind of turned into a multi-package bug and increased my frustration
> more than just a bit.
> 
> I'll check the specs later and see if there's validation code missing,
> and also see if Wine needs similar patches.
> 
> Again, sorry and thanks.

No problem Corbin.

I suspect this is because DX9 allows negative offset values in some
surprising places.  Basically I think you've hit two bugs - one wine is
trying to send Mesa an illegal negative value instead of translating it
away somehow, and secondly we are accepting it...

Ketih

Re: [Mesa3d-dev] mesa vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]

[Corbin S. <mos...@gm...>]

On Wed, Mar 10, 2010 at 6:59 AM, Keith Whitwell <ke...@vm...> wrote:
> It's great you found a bug, but why all the excitement?  Just track it
> down and propose a fix.  Mesa's pretty well debugged, but there are
> always going to be new issues.  I'm not sure why it warrants this type
> of implicit criticism when you come across something new.

I wasn't aware of any implicit criticism in my post. If I said
something wrong, I'm sorry; I'm a little bit fried from studying for a
final, and what started as a relaxing diversion from math review has
kind of turned into a multi-package bug and increased my frustration
more than just a bit.

I'll check the specs later and see if there's validation code missing,
and also see if Wine needs similar patches.

Again, sorry and thanks.

~ C.

--
Corbin Simpson
<Mos...@gm...>

Re: [Mesa3d-dev] mesa vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]

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

Keith Whitwell wrote:
> On Wed, 2010-03-10 at 06:47 -0800, Corbin Simpson wrote:
>> I don't know the VBO code that well, so I'm asking you guys if this
>> has ever come up before.
>>
>> http://bugs.winehq.org/show_bug.cgi?id=22000
>>
>> Gallium and indexed rendering are not very happy with each other. I get some
>> fairly solidly reliable segfaults with both a d3d9 DLL test (device.ok) and
>> Civ4 (Steam version). Hardware is a Radeon R580 (X1900), driver is r300g from
>> Mesa git.
>>
>> My current guess, based on the Mesa debug info I dumped, is that the indexed
>> rendering code is slightly baked and maybe trusting the underlying GL driver a
>> bit too much.
>>
>> get_arrays_bounds: Handling 2 attrs
>> attr 0: stride 16 size 12 start (nil) end 0xfffffffc
>> attr 1: stride 16 size 4 start 0xc end (nil)
>> buffer range: (nil) 0xfffffffc range -4 max index 4294967295

Can you post the patch you used to print this info, Corbin?


>> So right here (from device.ok) we have interleaved userspace VBO, that is being
>> prepped inside core Mesa. Two delightful things here; the first attr seems way
>> off-base, it shouldn't dare be giving us bad pointers, and the second attr's
>> pointers don't even line up! 
> 
> In VBO rendering, the pointers are really just offsets into the VBO, so
> should be interpreted as numbers.
> 
> The first attribute has what looks like a small negative number.  I
> don't know if that's legal or not in GL - I suspect it is probably not
> legal and should be rejected in the mesa validation code.

This would have come in via the 'ptr' argument to one of the 
glVertex/Color/etcPointer() functions.  We never check for negative 
pointer values.


> I suspect what is happening is wine is passing in some negative values
> and we aren't properly rejecting them in mesa.
> 
>> Compare to a sane program (Mesa's drawarrays):
>>
>> get_arrays_bounds: Handling 2 attrs
>> attr 0: stride 16 size 12 start 0x8087020 end 0x808705c
>> attr 1: stride 16 size 4 start 0x808702c end 0x8087060
>> buffer range: 0x8087020 0x8087060 range 64 max index 3
> 
> This doesn't look like VBO rendering though.  These are regular vertex
> arrays, meaning these values are proper pointers.
> 
>> r300g doesn't really care.
> 
> It shouldn't have to - the expectation in gallium is that inputs have
> been validated.
> 
> 
>>  The kernel drops the rendering on the floor for a
>> variety of reasons, not least being the ridiculous max_index.
>>
>> But then it segfaults, and I have zero idea why. I'd guess it's something to do
>> with tossing around NULL pointers like candy, but I'm honestly not sure and I
>> haven't really dug into the DLL code yet.
> 
> It's great you found a bug, but why all the excitement?  Just track it
> down and propose a fix.  Mesa's pretty well debugged, but there are
> always going to be new issues.  I'm not sure why it warrants this type
> of implicit criticism when you come across something new.

-Brian

[Mesa3d-dev] mesa vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]

[Keith W. <ke...@vm...>]

On Wed, 2010-03-10 at 06:47 -0800, Corbin Simpson wrote:
> I don't know the VBO code that well, so I'm asking you guys if this
> has ever come up before.
> 
> http://bugs.winehq.org/show_bug.cgi?id=22000
> 
> Gallium and indexed rendering are not very happy with each other. I get some
> fairly solidly reliable segfaults with both a d3d9 DLL test (device.ok) and
> Civ4 (Steam version). Hardware is a Radeon R580 (X1900), driver is r300g from
> Mesa git.
> 
> My current guess, based on the Mesa debug info I dumped, is that the indexed
> rendering code is slightly baked and maybe trusting the underlying GL driver a
> bit too much.
> 
> get_arrays_bounds: Handling 2 attrs
> attr 0: stride 16 size 12 start (nil) end 0xfffffffc
> attr 1: stride 16 size 4 start 0xc end (nil)
> buffer range: (nil) 0xfffffffc range -4 max index 4294967295
> 
> So right here (from device.ok) we have interleaved userspace VBO, that is being
> prepped inside core Mesa. Two delightful things here; the first attr seems way
> off-base, it shouldn't dare be giving us bad pointers, and the second attr's
> pointers don't even line up! 

In VBO rendering, the pointers are really just offsets into the VBO, so
should be interpreted as numbers.

The first attribute has what looks like a small negative number.  I
don't know if that's legal or not in GL - I suspect it is probably not
legal and should be rejected in the mesa validation code.

I suspect what is happening is wine is passing in some negative values
and we aren't properly rejecting them in mesa.

> Compare to a sane program (Mesa's drawarrays):
> 
> get_arrays_bounds: Handling 2 attrs
> attr 0: stride 16 size 12 start 0x8087020 end 0x808705c
> attr 1: stride 16 size 4 start 0x808702c end 0x8087060
> buffer range: 0x8087020 0x8087060 range 64 max index 3

This doesn't look like VBO rendering though.  These are regular vertex
arrays, meaning these values are proper pointers.

> r300g doesn't really care.

It shouldn't have to - the expectation in gallium is that inputs have
been validated.


>  The kernel drops the rendering on the floor for a
> variety of reasons, not least being the ridiculous max_index.
> 
> But then it segfaults, and I have zero idea why. I'd guess it's something to do
> with tossing around NULL pointers like candy, but I'm honestly not sure and I
> haven't really dug into the DLL code yet.

It's great you found a bug, but why all the excitement?  Just track it
down and propose a fix.  Mesa's pretty well debugged, but there are
always going to be new issues.  I'm not sure why it warrants this type
of implicit criticism when you come across something new.

Keith

[Mesa3d-dev] Wine/Gallium indexed strided VBO fail

[Corbin S. <mos...@gm...>]

I don't know the VBO code that well, so I'm asking you guys if this
has ever come up before.

http://bugs.winehq.org/show_bug.cgi?id=22000

Gallium and indexed rendering are not very happy with each other. I get some
fairly solidly reliable segfaults with both a d3d9 DLL test (device.ok) and
Civ4 (Steam version). Hardware is a Radeon R580 (X1900), driver is r300g from
Mesa git.

My current guess, based on the Mesa debug info I dumped, is that the indexed
rendering code is slightly baked and maybe trusting the underlying GL driver a
bit too much.

get_arrays_bounds: Handling 2 attrs
attr 0: stride 16 size 12 start (nil) end 0xfffffffc
attr 1: stride 16 size 4 start 0xc end (nil)
buffer range: (nil) 0xfffffffc range -4 max index 4294967295

So right here (from device.ok) we have interleaved userspace VBO, that is being
prepped inside core Mesa. Two delightful things here; the first attr seems way
off-base, it shouldn't dare be giving us bad pointers, and the second attr's
pointers don't even line up! Compare to a sane program (Mesa's drawarrays):

get_arrays_bounds: Handling 2 attrs
attr 0: stride 16 size 12 start 0x8087020 end 0x808705c
attr 1: stride 16 size 4 start 0x808702c end 0x8087060
buffer range: 0x8087020 0x8087060 range 64 max index 3

r300g doesn't really care. The kernel drops the rendering on the floor for a
variety of reasons, not least being the ridiculous max_index.

But then it segfaults, and I have zero idea why. I'd guess it's something to do
with tossing around NULL pointers like candy, but I'm honestly not sure and I
haven't really dug into the DLL code yet.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<Mos...@gm...>

Re: [Mesa3d-dev] sw-api-2 branch

[STEVE555 <ste...@ho...>]

Hi Keith,
            I use these configure options:
./configure --prefix=/usr --enable-32-bit --enable-xcb
--enable-gallium-nouveau --with-state-trackers=dri,egl,xorg,glx,vega,es
--enable-motif --enable-gl-osmesa --disable-gallium-intel
--disable-gallium-radeon --with-expat=/usr/lib
--with-demos=xdemos,demos,trivial,tests --with-dri-drivers=swrast
--enable-gallium-swrast --enable-gallium-svga --with-max-width=4096
--with-max-height=4096 --ernable-debug

I sometimes use --with-max-width= and --with-max-height= but the rest of
them generally stay the same.

Regards,
             STEVE555


Keith Whitwell-3 wrote:
> 
> Steve,
> 
> What configure options are those?
> 
> Keith
> 
> On Wed, 2010-03-10 at 04:41 -0800, STEVE555 wrote:
>> Dear Keith,
>>                 I checked out your branch using git checkout -b.and used
>> git
>> pull to get the differences between your branch and master.I did a gmake
>> -B
>> realclean and used my ./configure options I use for master.
>> Unfortunately,it has stopped compiling with this error:
>> 
>> /usr/bin/install -c vmwgfx_dri.so ../../../../../../lib/gallium
>> gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/dri'
>> gmake[5]: Entering directory
>> `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
>> gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
>> -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32
>> -DUSE_X86_ASM
>> -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS
>> -DDEBUG
>> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
>> -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
>> -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 -D_GNU_SOURCE
>> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB
>> -DUSE_EXTERNAL_DXTN_LIB=1
>> -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING
>> -DHAVE_ALIAS
>> -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dummy.c -o dummy.o
>> gmake[5]: *** No rule to make target
>> `../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
>> `egl_x11_vmwgfx.so'.  Stop.
>> gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
>> gmake[4]: *** [default] Error 1
>> gmake[4]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware'
>> gmake[3]: *** [default] Error 1
>> gmake[3]: Leaving directory `/opt/mesa/src/gallium/winsys/drm'
>> gmake[2]: *** [default] Error 1
>> gmake[2]: Leaving directory `/opt/mesa/src/gallium/winsys'
>> gmake[1]: *** [subdirs] Error 1
>> gmake[1]: Leaving directory `/opt/mesa/src'
>> gmake: *** [default] Error 1
>> 
>> Regards,
>>              STEVE555
>> 
>> 
>> Keith Whitwell-3 wrote:
>> > 
>> > This has reached a point where I could think about merging it.  There
>> is
>> > plenty more cleanup to do, but the branch makes some big strides and
>> > introduces a couple of concepts that I've wanted for a long time. 
>> > 
>> > In particular the idea of a designated "targets" subtree which has code
>> > for explicitly constructing driver stacks. 
>> > 
>> > Secondly the ability to inject layers into (at least) the software
>> > stacks has been greatly improved, and I'd like to see us build on that
>> > for hardware drivers as well.
>> > 
>> > There is probably still some bugfix to come, but if you're interested
>> in
>> > the software rasterizers, please check out this branch and let me know
>> > how much I've broken things...
>> > 
>> > Keith
>> > 
>> > 
>> >
>> ------------------------------------------------------------------------------
>> > Download Intel® Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Mesa3d-dev mailing list
>> > Mes...@li...
>> > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>> > 
>> > 
>> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/sw-api-2-branch-tp27841684p27849678.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] sw-api-2 branch

[Keith W. <ke...@vm...>]

Steve,

What configure options are those?

Keith

On Wed, 2010-03-10 at 04:41 -0800, STEVE555 wrote:
> Dear Keith,
>                 I checked out your branch using git checkout -b.and used git
> pull to get the differences between your branch and master.I did a gmake -B
> realclean and used my ./configure options I use for master.
> Unfortunately,it has stopped compiling with this error:
> 
> /usr/bin/install -c vmwgfx_dri.so ../../../../../../lib/gallium
> gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/dri'
> gmake[5]: Entering directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
> gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
> -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM
> -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
> -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
> -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
> -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 -D_GNU_SOURCE
> -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
> -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
> -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dummy.c -o dummy.o
> gmake[5]: *** No rule to make target
> `../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
> `egl_x11_vmwgfx.so'.  Stop.
> gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
> gmake[4]: *** [default] Error 1
> gmake[4]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware'
> gmake[3]: *** [default] Error 1
> gmake[3]: Leaving directory `/opt/mesa/src/gallium/winsys/drm'
> gmake[2]: *** [default] Error 1
> gmake[2]: Leaving directory `/opt/mesa/src/gallium/winsys'
> gmake[1]: *** [subdirs] Error 1
> gmake[1]: Leaving directory `/opt/mesa/src'
> gmake: *** [default] Error 1
> 
> Regards,
>              STEVE555
> 
> 
> Keith Whitwell-3 wrote:
> > 
> > This has reached a point where I could think about merging it.  There is
> > plenty more cleanup to do, but the branch makes some big strides and
> > introduces a couple of concepts that I've wanted for a long time. 
> > 
> > In particular the idea of a designated "targets" subtree which has code
> > for explicitly constructing driver stacks. 
> > 
> > Secondly the ability to inject layers into (at least) the software
> > stacks has been greatly improved, and I'd like to see us build on that
> > for hardware drivers as well.
> > 
> > There is probably still some bugfix to come, but if you're interested in
> > the software rasterizers, please check out this branch and let me know
> > how much I've broken things...
> > 
> > Keith
> > 
> > 
> > ------------------------------------------------------------------------------
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Mesa3d-dev mailing list
> > Mes...@li...
> > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> > 
> > 
> 

Re: [Mesa3d-dev] sw-api-2 branch

[STEVE555 <ste...@ho...>]

Dear Keith,
                I checked out your branch using git checkout -b.and used git
pull to get the differences between your branch and master.I did a gmake -B
realclean and used my ./configure options I use for master.
Unfortunately,it has stopped compiling with this error:

/usr/bin/install -c vmwgfx_dri.so ../../../../../../lib/gallium
gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/dri'
gmake[5]: Entering directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM
-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dummy.c -o dummy.o
gmake[5]: *** No rule to make target
`../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
`egl_x11_vmwgfx.so'.  Stop.
gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
gmake[4]: *** [default] Error 1
gmake[4]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/opt/mesa/src/gallium/winsys/drm'
gmake[2]: *** [default] Error 1
gmake[2]: Leaving directory `/opt/mesa/src/gallium/winsys'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/opt/mesa/src'
gmake: *** [default] Error 1

Regards,
             STEVE555


Keith Whitwell-3 wrote:
> 
> This has reached a point where I could think about merging it.  There is
> plenty more cleanup to do, but the branch makes some big strides and
> introduces a couple of concepts that I've wanted for a long time. 
> 
> In particular the idea of a designated "targets" subtree which has code
> for explicitly constructing driver stacks. 
> 
> Secondly the ability to inject layers into (at least) the software
> stacks has been greatly improved, and I'd like to see us build on that
> for hardware drivers as well.
> 
> There is probably still some bugfix to come, but if you're interested in
> the software rasterizers, please check out this branch and let me know
> how much I've broken things...
> 
> Keith
> 
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/sw-api-2-branch-tp27841684p27849102.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

[Mesa3d-dev] vmware gallium without X, on EGL

[Peter H. <han...@gm...>]

Hello.

I managed to compile Mesa without X for Gallium on vmware SVGA card with 
EGL.
After lot of link problems I managed to get libGL.so compiled and linked.

What was not resolved:
gl_dispatch_stub_361()
gl_dispatch_stub_356()
gl_dispatch_stub_366()
gl_dispatch_stub_362()
gll_dispatch_stub_357()
gl_dispatch_stub_363()
gl_dispatch_stub_358()
gl_dispatch_stub_364()
gl_dispatch_stub_365()
gl_dispatch_stub_359()
glDeleteTexturesEXT()
glGetColorTableParameterfvEXT()
glGetColorTableParameterivEXT()
glGenTexturesEXT()
glIsTextureEXT()
glAreTexturesResidentEXT()
glGetColorTableEXT()

I added stubs.c with empty function bodies and it worked.
eglgears.c is working.

I had to change this:
src/gallium/state_trackers/egl/kms/native_kms.c
in kms_surface_swap_buffers:

   if (ksurf->is_shown && kcrtc->crtc) {
      //err = drmModeSetCrtc(kdpy->fd, kcrtc->crtc->crtc_id,
      //      ksurf->back_fb.buffer_id, kcrtc->crtc->x, kcrtc->crtc->y,
      //      kcrtc->connectors, kcrtc->num_connectors, &kcrtc->crtc->mode);
      //if (err)
      //   return FALSE;
 drmModeDirtyFB(kdpy->fd, ksurf->back_fb.buffer_id, NULL, 0);
   }

Because with drmModeSetCrtc i've got an kernel error:
vmw_ldu_crtc_set_config: DRM_ERROR("Multiple framebuffers not supported\n");

Now I don't know if the backbuffer is correctly displayed. But it works, 
nevertheless.

So my question is what to use to display backbuffer?
Because vmwgfx doesn't support multiple framebuffers on one Crtc, neither 
drmModePageFlip.

I have also questuion to gallium.
What is soft_pipe, llvm_pipe?

Thanks.

Re: [Mesa3d-dev] [Intel-gfx] i965 OpenGL is heavily broken again

[Florian M. <fl...@mi...>]

On Sun, 07 Mar 2010 12:39:15 +0200
Maxim Levitsky <max...@gm...> wrote:

> On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote:
> > On Sun, 07 Mar 2010 00:24:24 +0200
> > Maxim Levitsky <max...@gm...> wrote:
> > 
> > > On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote:
> > > > On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote:
> > > > > On Sat, 06 Mar 2010 18:02:51 +0100
> > > > > Stephan Raue <mai...@op...> wrote:
> > > > > 
> > > > > > looks this like my problems that i have reported some days ago with 
> > > > > > Subject "Problem using an Mesa based App with recent 
> > > > > > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> > > > > > 
> > > > > > i have still this issue, but i dont know what you need for informations 
> > > > > > to fix the issues?
> > > > > > 
> > > > > > with ati driver i dont have problems, only here with intel driver on my 
> > > > > > Thinkpad X200t with intel HDA Graphics card
> > > > > > 
> > > > 
> > > > I now see that compiz hangs in same way.
> > > > 
> > > > Attached are backtrace of the compiz, and backtrace of etracer which did
> > > > start full screen but became hung on resolution change.
> > > > 
> > > > Best regards,
> > > > 	Maxim Levitsky
> > > 
> > > Other info that might help:
> > > 
> > > I took a look at X and found that it was in normal waiting state
> > > sleeping waiting for input.
> > > 
> > > Also, I found when 'unstable' mesa would appear to work when I start the
> > > X while 'stable' one is used. It was compiz. When compiz is running
> > > using stable mesa, an game does change the resolution 'usualy' without
> > > hang even if uses unstable mesa.
> > > 
> > > Best regards,
> > > 	Maxim Levitsky
> > 
> > i found that the kernel updates for 2.6.34-rc1 did make the hang time
> > out... this has to be some vblank issue, i assume...
> 
> 
> Note that I did try git master of linus tree, and that didn't help with
> the hang at all (now pulled it again, but don't see any  changes in drm
> code)
> 
> Best regards,
> 	Maxim Levisky

yeah. i'm sorry. My issues vanished with current git versions of
libdrm,mesa,xserver,xf86-video-intel ... while trying to find out(in
vain) which part of the stack did fix the issue, i noticed that the 
xserver-patches in jesse's tree was which changed "hung" into
"timeout"... 

hth,
Flo

Re: [Mesa3d-dev] sw-api-2 branch

[Keith W. <ke...@vm...>]

On Tue, 2010-03-09 at 16:49 -0800, STEVE555 wrote:
> Dear Keith,
>                 I've downloaded your sw-api-2 branch using the .tar.gz
> method again(git just won't let me).I used the same ./configure options but
> with the exception of doing --prefix=/usr/local instaed od /usr just in
> case.
> It was compiling fine until it hit this error:

Ugh, should be fixed by the merge from master.

Keith

Re: [Mesa3d-dev] sw-api-2 branch

[STEVE555 <ste...@ho...>]

Dear Keith,
                I've downloaded your sw-api-2 branch using the .tar.gz
method again(git just won't let me).I used the same ./configure options but
with the exception of doing --prefix=/usr/local instaed od /usr just in
case.
It was compiling fine until it hit this error:

gmake[4]: Entering directory
`/opt/mesa-gallium-sw-api-2/src/gallium/drivers/nv30'
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -g
-O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  nv30_clear.c -o
nv30_clear.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -g
-O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  nv30_context.c -o
nv30_context.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -g
-O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  nv30_draw.c -o
nv30_draw.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -g
-O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  nv30_fragprog.c -o
nv30_fragprog.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -g
-O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  nv30_fragtex.c -o
nv30_fragtex.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -g
-O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden
-fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM -DUSE_MMX_ASM
-DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  nv30_miptree.c -o
nv30_miptree.o
nv30_miptree.c: In function ‘nv30_screen_init_miptree_functions’:
nv30_miptree.c:239: error: ‘nv50_miptree_blanket’ undeclared (first use in
this function)
nv30_miptree.c:239: error: (Each undeclared identifier is reported only once
nv30_miptree.c:239: error: for each function it appears in.)
gmake[4]: *** [nv30_miptree.o] Error 1
gmake[4]: Leaving directory
`/opt/mesa-gallium-sw-api-2/src/gallium/drivers/nv30'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/opt/mesa-gallium-sw-api-2/src/gallium/drivers'
gmake[2]: *** [default] Error 1
gmake[2]: Leaving directory `/opt/mesa-gallium-sw-api-2/src/gallium'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/opt/mesa-gallium-sw-api-2/src'
gmake: *** [default] Error 1

Regards,
            STEVE555

Keith Whitwell-3 wrote:
> 
> This has reached a point where I could think about merging it.  There is
> plenty more cleanup to do, but the branch makes some big strides and
> introduces a couple of concepts that I've wanted for a long time. 
> 
> In particular the idea of a designated "targets" subtree which has code
> for explicitly constructing driver stacks. 
> 
> Secondly the ability to inject layers into (at least) the software
> stacks has been greatly improved, and I'd like to see us build on that
> for hardware drivers as well.
> 
> There is probably still some bugfix to come, but if you're interested in
> the software rasterizers, please check out this branch and let me know
> how much I've broken things...
> 
> Keith
> 
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/sw-api-2-branch-tp27841684p27844205.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] code generation for dynamic extensions broken ?

[George S. <gsa...@gm...>]

>
> Some comments:
>
>  e38a234.. shouldn't get merged as-is, right?  I mean, there must be
>  some sort of mesa_debug macro or similar, so that debug messages are
>  configurable.
>
>  ditto for d0b35e9.
>

right. from getproc-cleaunp..getproc-debug only the two fixes will be merged

>  d6c973c is a strange patch; the additions to GLAPI_SOURCES seem
>  unrelated to the patch itself.

mesa_exec_malloc is defined in the added sources from main/

>
>  977d5d: it seems like there should be some other way to disable this.
>  I've been trying to make time to have these XMLs be exhaustive in
>  their coverage of GL and GLX extensions, for example, which is good
>  for other reasons.

that was in order to test adding fbo extensions on-the-fly, not
intended for merging.

>
>  Most importantly: have you tested with mangled symbols (compile w/
>  USE_MGL_NAMESPACE defined)?  It looks like the functions added in
>  682971c need #ifdef MANGLE cases.
>
the commit just moves code. I guess get_extension_proc() needs ifdef's
for mangle similar to get_static_proc(), but that can be fixed
separately

thanks,
George.