I've tried your patch (+some minor fixes to make it work) but running texdepth
with it results in failing assertion rb-Format == MESA_FORMAT_X8_Z24
(s_readpix.c:123).
I've also tried modifying span functions to convert between Z24_S8 (hw format)
to S8_Z24 (mesa format) but wasn't able to get
Please update your Mesa from git. I fixed the assertion at line 123 yesterday.
-Brian
On Thu, Nov 12, 2009 at 12:23 PM, Maciej Cencora m.cenc...@gmail.com wrote:
I've tried your patch (+some minor fixes to make it work) but running texdepth
with it results in failing assertion rb-Format ==
Hi, I just noticed I get the stipple pattern in gallium in a wrong
byte ordering (as if they were 32 bit buggy endian words).
Is there a good reason why we mess up the bitmap ? If so I'll just
byte swap again in the pipe driver, but, I just thought normally you
wouldn't expect that you'd have to
http://bugs.freedesktop.org/show_bug.cgi?id=24436
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
CC||i...@freedesktop.org
This is a heads up for what is going on on the glsl-pp-rework-2 feature
branch.
The goal was to rewrite the existing preprocessor for GLSL compiler as a
stepping stone for a better GLSL compiler in general. Make it faster,
easy to understand and maintain. But the most important thing was to
Well...it will be a miracle if we can stream it live; but we are going
to try. I apologize for the last minute notice, but this just came
together today. If you or anyone in the community would like to join
the event via WebEx, please send me an e-mail and I will forward an
invite.
We
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've finished up the outputswritten64 branch, and I believe that it's
ready to merge. Software and i965 work.
I have not tested r300. Since r300 does not support GLSL, it doesn't
use any of the VERT_RESULT_VAR0 outputs. It shouldn't need any
