[Bug 7790] Polygons incorrectly clipped by mach64 driver (ATI Rage Pro LT card)

2006-10-20 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=7790  
 




--- Additional Comments From [EMAIL PROTECTED]  2006-10-20 15:44 ---
Created an attachment (id=7478)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=7478&action=view)
un-break strict-aliasing rules

Does this help?  
 
 
--   
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email 
 
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 7790] Polygons incorrectly clipped by mach64 driver (ATI Rage Pro LT card)

2006-10-20 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=7790  
 

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|General |Drivers/DRI/Mach64
Product|DRI |Mesa
Version|unspecified |CVS


  
 
 
--   
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email 
 
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)

2006-10-20 Thread Ryan Richter
On Fri, Oct 20, 2006 at 06:51:01PM +0100, Keith Whitwell wrote:
> Ryan Richter wrote:
> >On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote:
> >>Ryan Richter wrote:
> >>>On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote:
> >>All of your other wierd problems, like the assert failures, etc, make me 
> >>wonder if there just hasn't been some sort of build problem that can 
> >>only be resolved by clearing it out and restarting.
> >>
> >>It wouldn't hurt to just nuke your current Mesa and libdrm builds and 
> >>start from scratch - you'll probably have to do that to get debug 
> >>symbols for gdb anyway.
> >
> >I had heard something previously about i965_dri.so maybe getting
> >miscompiled, but I hadn't followed up on it until now.  I rebuilt it
> >with an older gcc, and now it's all working great!  Sorry for the wild
> >goose chase.
> 
> Out of interest, can you try again with the original GCC and see if the 
> problem comes back?  Which versions of GCC are you using?

The two gcc versions are the 4.1 (miscompiles) and 3.4 (OK) from Debian
unstable.  I had originally compiled it myself with gcc-4.1 because the
Debian libgl1-mesa-dri package didn't build i965_dri.so until I
submitted a build patch to them to have it built.  They released a new
package a few days ago with i965_dri.so included, presumably built with
the same gcc-4.1, the default cc on Debian unstable.

I had exactly the same problems with my own version and theirs.  I
rebuilt it again today with CC=gcc-3.4 and now everything works great.
I saved a copy of the old i965_dri.so, so I can verify in the next few
days that replacing it breaks things again.  Let me know if you want
copies of these files to examine.

-ryan

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)

2006-10-20 Thread Keith Whitwell
Ryan Richter wrote:
> On Fri, Oct 20, 2006 at 06:51:01PM +0100, Keith Whitwell wrote:
>> Ryan Richter wrote:
>>> On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote:
 Ryan Richter wrote:
> On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote:
 All of your other wierd problems, like the assert failures, etc, make me 
 wonder if there just hasn't been some sort of build problem that can 
 only be resolved by clearing it out and restarting.

 It wouldn't hurt to just nuke your current Mesa and libdrm builds and 
 start from scratch - you'll probably have to do that to get debug 
 symbols for gdb anyway.
>>> I had heard something previously about i965_dri.so maybe getting
>>> miscompiled, but I hadn't followed up on it until now.  I rebuilt it
>>> with an older gcc, and now it's all working great!  Sorry for the wild
>>> goose chase.
>> Out of interest, can you try again with the original GCC and see if the 
>> problem comes back?  Which versions of GCC are you using?
> 
> The two gcc versions are the 4.1 (miscompiles) and 3.4 (OK) from Debian
> unstable.  I had originally compiled it myself with gcc-4.1 because the
> Debian libgl1-mesa-dri package didn't build i965_dri.so until I
> submitted a build patch to them to have it built.  They released a new
> package a few days ago with i965_dri.so included, presumably built with
> the same gcc-4.1, the default cc on Debian unstable.
> 
> I had exactly the same problems with my own version and theirs.  I
> rebuilt it again today with CC=gcc-3.4 and now everything works great.
> I saved a copy of the old i965_dri.so, so I can verify in the next few
> days that replacing it breaks things again.  Let me know if you want
> copies of these files to examine.

Sure, email me the 4.1 version offline.  I'll also see about installing 
4.1 here.

Keith

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)

2006-10-20 Thread Keith Whitwell
Ryan Richter wrote:
> On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote:
>> Ryan Richter wrote:
>>> On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote:
 This is all a little confusing as the driver doesn't really use that 
 path in normal operation except for a single command - MI_FLUSH, which 
 is shared between the architectures.  In normal operation the hardware 
 does the validation for us for the bulk of the command stream.  If there 
 were missing functionality in that ioctl, it would be failing 
 everywhere, not just in this one case.

 I guess the questions I'd have are
- did the driver work before the kernel upgrade?
- what path in userspace is seeing you end up in this ioctl?
- and like Keith, what commands are you seeing?

 The final question is interesting not because we want to extend the 
 ioctl to cover those, but because it will give a clue how you ended up 
 there in the first place.
>>> Here's a list of all the failing commands I've seen so far:
>>>
>>> 3a440003
>>> d70003
>>> 2d010003
>>> e5b90003
>>> 2e730003
>>> 8d8c0003
>>> c10003
>>> d90003
>>> be0003
>>> 1e3f0003
>> Ryan,
>>
>> Those don't look like any commands I can recognize.  I'm still confused 
>> how you got onto this ioctl in the first place - it seems like something 
>> pretty fundamental is going wrong somewhere.  What would be useful to me 
>> is if you can use GDB on your application and get a stacktrace for how 
>> you end up in this ioctl in the cases where it is failing?
>>
>> Additionally, if you're comfortable doing this, it would be helpful to 
>> see all the arguments that userspace thinks its sending to the ioctl, 
>> compared to what the kernel ends up thinking it has to validate.  There 
>> shouldn't ever be more than two dwords being validated at a time, and 
>> they should look more or less exactly like {0x0203, 0}, and be 
>> emitted from bmSetFence().
>>
>> All of your other wierd problems, like the assert failures, etc, make me 
>> wonder if there just hasn't been some sort of build problem that can 
>> only be resolved by clearing it out and restarting.
>>
>> It wouldn't hurt to just nuke your current Mesa and libdrm builds and 
>> start from scratch - you'll probably have to do that to get debug 
>> symbols for gdb anyway.
> 
> I had heard something previously about i965_dri.so maybe getting
> miscompiled, but I hadn't followed up on it until now.  I rebuilt it
> with an older gcc, and now it's all working great!  Sorry for the wild
> goose chase.

Out of interest, can you try again with the original GCC and see if the 
problem comes back?  Which versions of GCC are you using?

Keith

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)

2006-10-20 Thread Ryan Richter
On Fri, Oct 20, 2006 at 12:43:44PM +0100, Keith Whitwell wrote:
> Ryan Richter wrote:
> >On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote:
> >>This is all a little confusing as the driver doesn't really use that 
> >>path in normal operation except for a single command - MI_FLUSH, which 
> >>is shared between the architectures.  In normal operation the hardware 
> >>does the validation for us for the bulk of the command stream.  If there 
> >> were missing functionality in that ioctl, it would be failing 
> >>everywhere, not just in this one case.
> >>
> >>I guess the questions I'd have are
> >>- did the driver work before the kernel upgrade?
> >>- what path in userspace is seeing you end up in this ioctl?
> >>- and like Keith, what commands are you seeing?
> >>
> >>The final question is interesting not because we want to extend the 
> >>ioctl to cover those, but because it will give a clue how you ended up 
> >>there in the first place.
> >
> >Here's a list of all the failing commands I've seen so far:
> >
> >3a440003
> >d70003
> >2d010003
> >e5b90003
> >2e730003
> >8d8c0003
> >c10003
> >d90003
> >be0003
> >1e3f0003
> 
> Ryan,
> 
> Those don't look like any commands I can recognize.  I'm still confused 
> how you got onto this ioctl in the first place - it seems like something 
> pretty fundamental is going wrong somewhere.  What would be useful to me 
> is if you can use GDB on your application and get a stacktrace for how 
> you end up in this ioctl in the cases where it is failing?
> 
> Additionally, if you're comfortable doing this, it would be helpful to 
> see all the arguments that userspace thinks its sending to the ioctl, 
> compared to what the kernel ends up thinking it has to validate.  There 
> shouldn't ever be more than two dwords being validated at a time, and 
> they should look more or less exactly like {0x0203, 0}, and be 
> emitted from bmSetFence().
> 
> All of your other wierd problems, like the assert failures, etc, make me 
> wonder if there just hasn't been some sort of build problem that can 
> only be resolved by clearing it out and restarting.
> 
> It wouldn't hurt to just nuke your current Mesa and libdrm builds and 
> start from scratch - you'll probably have to do that to get debug 
> symbols for gdb anyway.

I had heard something previously about i965_dri.so maybe getting
miscompiled, but I hadn't followed up on it until now.  I rebuilt it
with an older gcc, and now it's all working great!  Sorry for the wild
goose chase.

Thanks,
-ryan

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Where to start?

2006-10-20 Thread Anna Lissa Cruz
Hi all,I just signed onto the list.  I'm working with Rudi Cilibrasi and wondering where's the best place to start contributing.  We're both C programmers, with some OpenGL experience, and have NV35 and NV36 cards to play with.  We have checked out the feature matrix, and see there are a couple of TODOs and a few WIPs. Should we just pick a TODO? Or perhaps there's a WIP we can cut our teeth on?Cheers,Anna Lissa-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 7111] racer: [drm:drm_lock_take] *ERROR* 3 holds heavyweight lock

2006-10-20 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=7111  
 

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|mesa3d- |dri-
   |[EMAIL PROTECTED]   |[EMAIL PROTECTED]
 Status|NEEDINFO|NEW
  Component|Mesa core   |Drivers/DRI/r300




--- Additional Comments From [EMAIL PROTECTED]  2006-10-20 05:45 ---
(In reply to comment #11)
> Getting this was not that easy, because gdb didn't show its prompt after using
> attach or when starting it with "gdb racer.bin $(pidof racer.bin)". 

Probably because it was still running at that point, in which case Ctrl-C should
have given you a prompt.

Thanks for the backtrace, it looks like the r300 driver attempts to grab the
hardware lock recursively.

Does setting the environment variable R300_SPAN_DISABLE_LOCKING for running
racer work around this?  
 
 
--   
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email 
 
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


question on nv35 versus nv30 protocol

2006-10-20 Thread Rudi Cilibrasi
Hi everybody,

I have just started trying to contribute to this project and got as
far as identifying chip family for the two cards I have access to
here: NV35 and NV36.  I added a column for NV35 assuming that the
protocol would be different than NV30 in the TODO matrix, but now am
wondering if this is correct.  Does anybody know yet or will I just
have to find out myself through experimentation?

Thanks for starting up such a great project.

Best regards,

Rudi Cilibrasi

-- 
Experiment with Artificial Intelligence  at http://complearn.org/

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Intel 965G: i915_dispatch_cmdbuffer failed (2.6.19-rc2)

2006-10-20 Thread Keith Whitwell
Ryan Richter wrote:
> On Wed, Oct 18, 2006 at 07:54:41AM +0100, Keith Whitwell wrote:
>> This is all a little confusing as the driver doesn't really use that 
>> path in normal operation except for a single command - MI_FLUSH, which 
>> is shared between the architectures.  In normal operation the hardware 
>> does the validation for us for the bulk of the command stream.  If there 
>>  were missing functionality in that ioctl, it would be failing 
>> everywhere, not just in this one case.
>>
>> I guess the questions I'd have are
>>  - did the driver work before the kernel upgrade?
>>  - what path in userspace is seeing you end up in this ioctl?
>>  - and like Keith, what commands are you seeing?
>>
>> The final question is interesting not because we want to extend the 
>> ioctl to cover those, but because it will give a clue how you ended up 
>> there in the first place.
> 
> Here's a list of all the failing commands I've seen so far:
> 
> 3a440003
> d70003
> 2d010003
> e5b90003
> 2e730003
> 8d8c0003
> c10003
> d90003
> be0003
> 1e3f0003

Ryan,

Those don't look like any commands I can recognize.  I'm still confused 
how you got onto this ioctl in the first place - it seems like something 
pretty fundamental is going wrong somewhere.  What would be useful to me 
is if you can use GDB on your application and get a stacktrace for how 
you end up in this ioctl in the cases where it is failing?

Additionally, if you're comfortable doing this, it would be helpful to 
see all the arguments that userspace thinks its sending to the ioctl, 
compared to what the kernel ends up thinking it has to validate.  There 
shouldn't ever be more than two dwords being validated at a time, and 
they should look more or less exactly like {0x0203, 0}, and be 
emitted from bmSetFence().

All of your other wierd problems, like the assert failures, etc, make me 
wonder if there just hasn't been some sort of build problem that can 
only be resolved by clearing it out and restarting.

It wouldn't hurt to just nuke your current Mesa and libdrm builds and 
start from scratch - you'll probably have to do that to get debug 
symbols for gdb anyway.

Keith

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 8707] [drm git] drm_drv.c:475: error: void value not ignored as it ought to be

2006-10-20 Thread bugzilla-daemon
Please do not reply to this email: if you want to comment on the bug, go to
   
the URL shown below and enter yourcomments there. 
   
https://bugs.freedesktop.org/show_bug.cgi?id=8707  
 

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|dri-|[EMAIL PROTECTED]
   |[EMAIL PROTECTED] |
 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2006-10-20 02:54 ---
The 2.6.19 kernel series are still not stabilized AFAICT. However, the change
causing this bug looks like it's going to stay.

I'll check in a fix later today, but there are a number of pci-related
compilation warnings with this kernel series so don't expect everything to just
work :)

/Thomas
  
 
 
--   
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email 
 
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel