There's something fishy in u_upload_mgr, could you please review the first
two patches here?
http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources
With this, r300g works again.
-Marek
On Fri, Apr 2, 2010 at 4:17 PM, Roland Scheidegger wrote:
> I'm planning on merging the gallium-res
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 tes
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
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
Subject
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 [l...@luca-barbier
> 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 s
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; mesa3d-dev@lists.sourc
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 your
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_ha
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® Parallel Studio Eval
Try the new software tools for yourself.
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
On Fri, Apr 2, 2010 at 6:44 AM, Yann Droneaud 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 the screen an
> 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 Me
> 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 (
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 dri_destroy_opt
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 paten
On 02.04.2010 17:18, Luca Barbieri wrote:
> 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
Luca Barbieri wrote:
> On Fri, Apr 2, 2010 at 9:51 AM, Jose Fonseca 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 compiler/linker
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 once
On Fri, Apr 2, 2010 at 9:51 AM, Jose Fonseca 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 compiler/linker magic necessary to
> work
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 discussion
On Thu, Apr 1, 2010 at 5:15 PM, Jeremy Huddleston
wrote:
>
> On Apr 1, 2010, at 15:12, Dan Nicholson wrote:
>
>>> This is against 7.8 ... perhaps you should cherry-pick the appropriate
>>> change into the 7.8 branch then.
>>
>> Well, now I'm getting conflicts because you pushed this patch 25
>> m
On 02/04/2010 01:14, Jeremy Huddleston wrote:
> On Apr 1, 2010, at 15:13, tom fogal wrote:
>> Jeremy Huddleston 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, and I
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 lo
24 matches
Mail list logo
