Re: [Bug 14314] glxgears: brw_misc_state.c:214: upload_depthbuffer: Assertion `0' failed.

Hi, Kristian
   This assertion failure is caused by this
46eb02b60920a920b782bacb15f01b44e18f888d. The cpp of depth region is
gotten directly from I830DRIPtr before, however in this commit, it is
computed from Visual.rgbBits. I don't understand why you do so, could
you take a look?

Thanks
Haihao

On Thu, 2008-01-31 at 17:19 -0800, bugzilla-daemon <at> freedesktop.org wrote:
> http://bugs.freedesktop.org/show_bug.cgi?id=14314
> 
> 
> Gordon Jin <gordon.jin <at> intel.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>          AssignedTo|gordon.jin <at> intel.com        |haihao.xiang <at> intel.com
> 
> 
> 
> 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Bug 13571] blender crash in triangle_twoside_flat on mga

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

--- Comment #1 from Brice Goglin <brice.goglin <at> ens-lyon.org>  2008-02-01 05:22:51 PST ---
The downstream author says that the problem does not occur anymore with
7.0.3-rc1 (Debian's 7.0.2-4). Do you guy have any reason to believe that a
recent commit on the 7.0 branch fixed this?

--

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Alternative build system for Gallium -- SCons

José Fonseca wrote:
| I tried and tried to produce a proof of concept with CMake, but
| couldn't find a satisfactory solution for using it with mesa/gallium.
| Getting convenience libraries to work with CMake would be so difficult
| and hackish, that would defeat the whole point of the exercise.
|
| So I researched for another build system with the desired
| characteristics again, and rediscovered scons, http://www.scons.org/ .
| I tried using it a few times in the past, and I recall Brian tried
| too, but this time it was a pleasant surprise. In a few hours I
| managed to get softpipe to build. Supporting convenience libraries was
| also easy.

Does it support parallel builds?  The moral equivalent of "make -j4".
On a quad-core system with sufficient RAM that cuts build times by
roughly a two thirds.  It would be a shame to lose that.

Re: Alternative build system for Gallium -- SCons

On Feb 1, 2008 10:59 AM, Ian Romanick <idr <at> us.ibm.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> José Fonseca wrote:
> | I tried and tried to produce a proof of concept with CMake, but
> | couldn't find a satisfactory solution for using it with mesa/gallium.
> | Getting convenience libraries to work with CMake would be so difficult
> | and hackish, that would defeat the whole point of the exercise.
> |
> | So I researched for another build system with the desired
> | characteristics again, and rediscovered scons, http://www.scons.org/ .
> | I tried using it a few times in the past, and I recall Brian tried
> | too, but this time it was a pleasant surprise. In a few hours I
> | managed to get softpipe to build. Supporting convenience libraries was
> | also easy.
>
> Does it support parallel builds?  The moral equivalent of "make -j4".
> On a quad-core system with sufficient RAM that cuts build times by
> roughly a two thirds.  It would be a shame to lose that.

According to the FAQ, yes, with the same -j switch.

http://www.scons.org/faq.php#SS_5_3

--
Dan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft

64-bit memory access on Cell SPEs?

I've noticed some odd bugs when accessing data packets sent via batch
buffers from the PPE to SPE.  Every now and then one of the pointers
sent would be NULL or similar, low value.  I tracked this down to
unaligned accesses.  If 64-bit values aren't aligned, reads return garbage.

I managed to work around this by making the opcode field 64-bits and
ensuring that each batch is 64-bit aligned.  This seems to also
eliminate the need for the dummy fields in cell_command_render.

Patch attached.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: 64-bit memory access on Cell SPEs?

Ian Romanick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I've noticed some odd bugs when accessing data packets sent via batch
> buffers from the PPE to SPE.  Every now and then one of the pointers
> sent would be NULL or similar, low value.  I tracked this down to
> unaligned accesses.  If 64-bit values aren't aligned, reads return garbage.
> 
> I managed to work around this by making the opcode field 64-bits and
> ensuring that each batch is 64-bit aligned.  This seems to also
> eliminate the need for the dummy fields in cell_command_render.
> 
> Patch attached.

The patch breaks some things for me.  Let me sort through that.

I'm seeing some alignment-related problems in some new code too so I 
think you've got the right idea.

I'll probably send you a new patch in a bit...

-Brian

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: 64-bit memory access on Cell SPEs?

Brian Paul wrote:
> Ian Romanick wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I've noticed some odd bugs when accessing data packets sent via batch
>> buffers from the PPE to SPE.  Every now and then one of the pointers
>> sent would be NULL or similar, low value.  I tracked this down to
>> unaligned accesses.  If 64-bit values aren't aligned, reads return 
>> garbage.
>>
>> I managed to work around this by making the opcode field 64-bits and
>> ensuring that each batch is 64-bit aligned.  This seems to also
>> eliminate the need for the dummy fields in cell_command_render.
>>
>> Patch attached.
> 
> The patch breaks some things for me.  Let me sort through that.
> 
> I'm seeing some alignment-related problems in some new code too so I 
> think you've got the right idea.
> 
> I'll probably send you a new patch in a bit...

OK, things are running again.  I'll just commit and push what I've got, 
including your patches.

-Brian

-------------------------------------------------------------------------

Re: 64-bit memory access on Cell SPEs?

Brian Paul wrote:
> Brian Paul wrote:
>> Ian Romanick wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> I've noticed some odd bugs when accessing data packets sent via batch
>>> buffers from the PPE to SPE.  Every now and then one of the pointers
>>> sent would be NULL or similar, low value.  I tracked this down to
>>> unaligned accesses.  If 64-bit values aren't aligned, reads return 
>>> garbage.
>>>
>>> I managed to work around this by making the opcode field 64-bits and
>>> ensuring that each batch is 64-bit aligned.  This seems to also
>>> eliminate the need for the dummy fields in cell_command_render.
>>>
>>> Patch attached.
>>
>> The patch breaks some things for me.  Let me sort through that.
>>
>> I'm seeing some alignment-related problems in some new code too so I 
>> think you've got the right idea.
>>
>> I'll probably send you a new patch in a bit...
> 
> OK, things are running again.  I'll just commit and push what I've got, 
> including your patches.

Done.

Re: 64-bit memory access on Cell SPEs?

Brian Paul wrote:

| But I omitted your changes to configs/linux-cell, Ian:
|    'ccache' doesn't exist
|    -DSPU_MAIN_PARAM_LONG_LONG doesn't work for SDK 2.1
|    /opt/powerpc/usr/include doesn't exist

Oops.  I hadn't meant to include my local changes to configs/linux-cell
with the rest of the patch set.  Since I have a few other things
specific to my crosscompile setup, I'm fine with leaving linux-cell as is.

| How about we make a new linux-cell-sdk3 (or rename linux-cell to
| linux-cell-sdk2.1) to avoid conflicts?
|
| I'll probably upgrade to SDK 3.0 eventually, but not for a little while.

Re: Mesa 7.0.3 release candidate 1

Hi,

Is there any chance for the glClipPlane fix to make it into Mesa 7.0.3? 
The bug report is here:
http://bugs.freedesktop.org/show_bug.cgi?id=9871

I suppose the fix consists of these 2 commits:
http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=35d28ce12e59526cb66e82d7d5469e50196a8ccd
http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=cd59600c7b6cba42baba208e74d783fbade93356

Regards,
Erkin

On Mon, 21 Jan 2008 15:37:42 -0800, Brian Paul wrote:
> 
> Available at http://www.mesa3d.org/beta/
> 
> md5sums:
> 
> 1d2f641f21aebb7a1e3f8604352519d8  MesaLib-7.0.3-rc1.tar.gz
> 0b502adbc27b7ce014ea1681be0e4b46  MesaLib-7.0.3-rc1.zip
> fcef887930b54d0051567767aa08d6b7  MesaDemos-7.0.3-rc1.tar.gz
> 6647fd690913ec488f51e619b4c49b6c  MesaDemos-7.0.3-rc1.zip
> 515c2ceed8d38b8f1d92b0bb47ed9b5e  MesaGLUT-7.0.3-rc1.tar.gz
> d1a437881d332fc7153969a96d22d78b  MesaGLUT-7.0.3-rc1.zip
> 
> This will be a bug-fix only release.
> 
> Fixes include:
>   Added missing glw.pc.in file to release tarball