Reliability goes both ways: using a global constructor simplifies the problem
substantially, but it is only as reliable as the global constructor mechanism
itself -- which it's not much given the compiler/linker magic necessary to
work.
I also think that we should code generate most constat
On 02/04/2010 01:14, Jeremy Huddleston wrote:
On Apr 1, 2010, at 15:13, tom fogal wrote:
Jeremy Huddlestonjerem...@freedesktop.org writes:
BTW, what config are you using, and what prevents you from using
autoconf?
I can't use autoconf because it is nowhere near capable of handling
darwin,
I'm planning on merging the gallium-resources branch shortly (after
easter). Due to the amount of code changed, it wouldn't be unexpected if
some drivers break here and there. So it would be nice if the respective
driver authors could take a look at that branch now.
If you've missed the
How about merging gallium-buffer-usage-cleanup as well, which is based
on gallium-resources?
Unless, it changed recently, the gallium-resources branch left a mix
of old PIPE_BUFFER_USAGE_* and new PIPE_TRANSFER_* flags.
It would nice to convert drivers having both branches, so that it is done
Luca Barbieri wrote:
On Fri, Apr 2, 2010 at 9:51 AM, Jose Fonseca jfons...@vmware.com wrote:
Reliability goes both ways: using a global constructor simplifies the
problem substantially, but it is only as reliable as the global constructor
mechanism itself -- which it's not much given the
On 02.04.2010 17:09, Luca Barbieri wrote:
Additionally, the S3TC library may now support only a subset of the
formats. This may be even more useful as further compressed formats
are added.
FWIW, I don't see any new s3tc formats. rgtc will not be handled by s3tc
library since it isn't patent
With an Intel 855GM handled by intel_drv, there's a crash with Gallium3D
enabled DRI driver for Intel i915 (--enable-gallium-intel).
The Gallium3D driver doesn't support the 855GM as expected by
intel_drv, it failed to open the screen and give an half
initialized screen structure to
FWIW, I don't see any new s3tc formats. rgtc will not be handled by s3tc
library since it isn't patent encumbered. util_format_is_s3tc will not
include rgtc formats.
(Though I guess that external decoding per-pixel is really rather lame,
should do it per-block...)
Yes the other formats (rgtc
So far, there are no dependencies on Gallium in core Mesa.
We've talked about refactoring some of the Gallium code into a separate
module that'd be sharable between Gallium and Mesa. The format code would
probably fit into that.
Can't we just unconditionally pull gallium/auxiliary in Mesa?
On Fri, Apr 2, 2010 at 6:44 AM, Yann Droneaud y...@droneaud.fr wrote:
With an Intel 855GM handled by intel_drv, there's a crash with Gallium3D
enabled DRI driver for Intel i915 (--enable-gallium-intel).
The Gallium3D driver doesn't support the 855GM as expected by
intel_drv, it failed to open
S3TC was working on my machine and now it is not! How that goes for reliability?
I was unsure but now you sure convinced me. I'm removing this constructor magic
madness. Please leave the much more reliable system of explicitly calling
initializers.
Jose
What are you seeing a regression on?
texcompress and texcompsub seemed to work for me: I'll try to test
something else and recheck the code.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for
Sorry for the regression.
This whole thing was done to fix the u_gctors.cpp issue, originally
done by me, sent out without full testing since I saw duplicate work
being done, and then merged by Roland if I recall correctly.
I probably should not have fixed s3tc/util_format like it was done for
u_format_test started failing and it was not one day ago. Vinson reported some
texture compression tests that just got working with my recent changes started
to failing again.
I'm not sure if it's the constructor mechanism, my platform (64bit), or some
bug in the code. I just reverted all
Both ways are useful: single pixel decompression for texture sampling, whole
block for whole image conversions.
Jose
From: Roland Scheidegger [srol...@vmware.com]
Sent: Friday, April 02, 2010 17:27
To: Luca Barbieri
Cc: Jose Fonseca;
One more thing: I'm maintaining the u_format* modules. I'm not speaking the
just in the long term, but in the sense I'm actually working on this as we
speak. Please do not make this kind of deep reaching changes to the u_format
stuff in master without clearing them first with me.
Yes
Probably the problems are just as you describe. But I'll be offline soon so
I'll only review this and all your other changes carefully another day.
Jose
From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca
Barbieri
OK, I can relate with your reasoning. It's no biggie.
Jose
From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca
Barbieri [l...@luca-barbieri.com]
Sent: Saturday, April 03, 2010 1:23
To: Jose Fonseca
Cc: mesa3d-...@lists.sf.net
The s3tc-teximage test seems fixed by the two line change I put in
gallium-util-format-is-supported.
s3tc-texsubimage prints:
Mesa: User error: GL_INVALID_VALUE in glTexSubImage2D(xoffset+width)
Probe at (285,12)
Expected: 1.00 0.00 0.00
Observed: 0.00 0.00 0.00
which
Just going down the r300g piglit failures and noticed fbo-drawbuffers
failed, I've no idea
if this passes on Intel hw, but it appears the texenvprogram really
needs to understand the
draw buffers. The attached patch fixes it here for me on r300g anyone
want to test this on Intel
with the piglit
20 matches
Mail list logo
