mesa3d-dev

Re: [Mesa3d-dev] How do we init half float tables?

[Luca B. <lu...@lu...>]

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.

Re: [Mesa3d-dev] How do we init half float tables?

[Jose F. <jfo...@vm...>]

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

________________________________________
From: luc...@gm... [luc...@gm...] On Behalf Of Luca Barbieri [lu...@lu...]
Sent: Friday, April 02, 2010 16:09
To: Jose Fonseca
Cc: Brian Paul; mes...@li...
Subject: Re: [Mesa3d-dev] How do we init half float tables?

On Fri, Apr 2, 2010 at 9:51 AM, Jose Fonseca <jfo...@vm...> 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.

Once it is written and works, it should just work indefinitely, since
the C++ ABI relies on it.

> I also think that we should code generate most constat lookup tables: it avoids the initialization problem, and it saves memory when the SO is loaded in several processes as pages can be shared.

Yes, I have done exactly this, for the reasons you describe.
The half float tables are now pre-generated by a Python script.

> For S3TC it is not a real problem: any code that exposes S3TC support needs to check if S3TC (de)compresion support is available before advertising (xxx_screen.c). Checking the support and initialization should be done by a single function. That is, if the libtxc_dxtn.so is not available the s3tc functions should *never* be called.

I changed the format code to add a new "util_format_is_supported" that
allows users to query if the util_format code can pack/unpack a given
format.

That function, if called on an s3tc format, will automatically call
the S3TC init function.
This way, users of the format helpers no longer need to know about
S3TC at all, and it will just work.

Even if the util_format_is_supported function is not called before
reading/writing an S3TC format, the fetch/pack function pointers are
initialized to versions that will autoload the S3TC library.

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.

There are two areas where I'm not totally happy with the approach I did though:
1. Currently upon a successful load of S3TC, we hack the format
descriptions to set the is_supported bit to 1. Not sure if it is the
best way to do it.
2. If S3TC is not available, the functions just do nothing: this is
consistent with other unsupported formats. We may however want to read
black pixels, throw an error, or read a special "error" image instead
(I'd suggest having "unsupported" unpack/pack functions and pointing
all unsupported formats to them)

Also, I think we should remove all the Mesa internal format code and
make it use util_format instead, unless there is really a good reason
to duplicate it all.
Same thing for util_half.

Re: [Mesa3d-dev] [PATCH] gallium: fix dri_destroy_option_cache() when optionCache.info is NULL

[Corbin S. <mos...@gm...>]

On Fri, Apr 2, 2010 at 6:44 AM, Yann Droneaud <ya...@dr...> 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 and give an half
> initialized screen structure to dri_destroy_option_cache():
> optionCache.info is NULL, so it's crashing while trying
> to free array content. This patch at least fix the crash in the function.
>
> Here's some logs of the fixed version:
>
> [ 16274.137] LoaderOpen(/opt/mesa/lib/xorg/modules/drivers/intel_drv.so)
> [ 16274.139] (II) Loading /opt/mesa/lib/xorg/modules/drivers/intel_drv.so
> [ 16274.183] (II) Module intel: vendor="X.Org Foundation"
> [ 16274.183]    compiled for 1.8.0, module version = 2.11.0
> [ 16274.183]    Module class: X.Org Video Driver
> [ 16274.183]    ABI class: X.Org Video Driver, version 7.0
> [ 16274.183] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
>        i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
>        E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
>        965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
>        4 Series, G45/G43, Q45/Q43, G41, B43, Clarkdale, Arrandale
> [ 16274.382] (II) intel(0): Integrated Graphics Chipset: Intel(R) 855GME
> [ 16274.382] (--) intel(0): Chipset: "852GM/855GM"
> [ 16276.675] (II) intel(0): [DRI2] Setup complete
> [ 16276.675] (II) intel(0): [DRI2]   DRI driver: i915
> debug_get_option: GALLIUM_TRACE = (null)
> debug_get_bool_option: GALLIUM_RBUG = FALSE
> debug_get_bool_option: INTEL_DUMP_CMD = FALSE
> i915_create_screen: unknown pci id 0x3582, cannot create screen
> dri_init_screen_helper: failed to create pipe_screen
> [ 16276.794] (EE) AIGLX error: Calling driver entry point failed
> [ 16276.794] (EE) AIGLX: reverting to software rendering
> [ 16276.794] (II) AIGLX: Screen 0 is not DRI capable
> [ 16276.796] (II) AIGLX: Loaded and initialized /opt/mesa/lib/dri/swrast_dri.so
> [ 16276.796] (II) GLX: Initialized DRISWRAST GL provider for screen 0
>
> Signed-off-by: Yann Droneaud <ya...@dr...>
>
> ---
>  src/gallium/state_trackers/dri/common/dri_screen.c |   10 ++++++----
>  1 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/state_trackers/dri/common/dri_screen.c b/src/gallium/state_trackers/dri/common/dri_screen.c
> index 6fc7487..6e17614 100644
> --- a/src/gallium/state_trackers/dri/common/dri_screen.c
> +++ b/src/gallium/state_trackers/dri/common/dri_screen.c
> @@ -288,12 +288,14 @@ dri_destroy_option_cache(struct dri_screen * screen)
>  {
>    int i;
>
> -   for (i = 0; i < (1 << screen->optionCache.tableSize); ++i) {
> -      FREE(screen->optionCache.info[i].name);
> -      FREE(screen->optionCache.info[i].ranges);
> +   if (screen->optionCache.info) {
> +      for (i = 0; i < (1 << screen->optionCache.tableSize); ++i) {
> +         FREE(screen->optionCache.info[i].name);
> +         FREE(screen->optionCache.info[i].ranges);
> +      }
> +      FREE(screen->optionCache.info);
>    }
>
> -   FREE(screen->optionCache.info);
>    FREE(screen->optionCache.values);
>  }
>
> --
> 1.6.4.4

Applied and pushed, thanks.

In general, this is the correct behavior; screens should fail to be
created if they can't find proper hardware to talk to. Not sure if
that behavior's documented, but it's correct.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<Mos...@gm...>

Re: [Mesa3d-dev] How do we init half float tables?

[Luca B. <lu...@lu...>]

> 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? (unused
stuff will be ignored by the linker due to .a behavior)

Re: [Mesa3d-dev] How do we init half float tables?

[Luca B. <lu...@lu...>]

> 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 and bptc) have no patent claims listed.

Re: [Mesa3d-dev] How do we init half float tables?

[Roland S. <sr...@vm...>]

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 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...)

Roland

Re: [Mesa3d-dev] gallium-resources branch merge

[Roland S. <sr...@vm...>]

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 drivers having both branches, so that it is done once.
> However, note that I may be misunderstanding the branches, correct me
> if I'm worng.

Yes, I've already merged gallium-buffer-usage-cleanup back into
gallium-resources, so this is already done.

Roland

Re: [Mesa3d-dev] How do we init half float tables?

[Brian P. <br...@vm...>]

Luca Barbieri wrote:
> On Fri, Apr 2, 2010 at 9:51 AM, Jose Fonseca <jfo...@vm...> 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.
> 
> Once it is written and works, it should just work indefinitely, since
> the C++ ABI relies on it.
> 
>> I also think that we should code generate most constat lookup tables: it avoids the initialization problem, and it saves memory when the SO is loaded in several processes as pages can be shared.
> 
> Yes, I have done exactly this, for the reasons you describe.
> The half float tables are now pre-generated by a Python script.
> 
>> For S3TC it is not a real problem: any code that exposes S3TC support needs to check if S3TC (de)compresion support is available before advertising (xxx_screen.c). Checking the support and initialization should be done by a single function. That is, if the libtxc_dxtn.so is not available the s3tc functions should *never* be called.
> 
> I changed the format code to add a new "util_format_is_supported" that
> allows users to query if the util_format code can pack/unpack a given
> format.
> 
> That function, if called on an s3tc format, will automatically call
> the S3TC init function.
> This way, users of the format helpers no longer need to know about
> S3TC at all, and it will just work.
> 
> Even if the util_format_is_supported function is not called before
> reading/writing an S3TC format, the fetch/pack function pointers are
> initialized to versions that will autoload the S3TC library.
> 
> 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.
> 
> There are two areas where I'm not totally happy with the approach I did though:
> 1. Currently upon a successful load of S3TC, we hack the format
> descriptions to set the is_supported bit to 1. Not sure if it is the
> best way to do it.
> 2. If S3TC is not available, the functions just do nothing: this is
> consistent with other unsupported formats. We may however want to read
> black pixels, throw an error, or read a special "error" image instead
> (I'd suggest having "unsupported" unpack/pack functions and pointing
> all unsupported formats to them)
> 
> Also, I think we should remove all the Mesa internal format code and
> make it use util_format instead, unless there is really a good reason
> to duplicate it all.
> Same thing for util_half.

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.

-Brian

Re: [Mesa3d-dev] gallium-resources branch merge

[Luca B. <luc...@gm...>]

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.
However, note that I may be misunderstanding the branches, correct me
if I'm worng.

Re: [Mesa3d-dev] How do we init half float tables?

[Luca B. <lu...@lu...>]

On Fri, Apr 2, 2010 at 9:51 AM, Jose Fonseca <jfo...@vm...> 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.

Once it is written and works, it should just work indefinitely, since
the C++ ABI relies on it.

> I also think that we should code generate most constat lookup tables: it avoids the initialization problem, and it saves memory when the SO is loaded in several processes as pages can be shared.

Yes, I have done exactly this, for the reasons you describe.
The half float tables are now pre-generated by a Python script.

> For S3TC it is not a real problem: any code that exposes S3TC support needs to check if S3TC (de)compresion support is available before advertising (xxx_screen.c). Checking the support and initialization should be done by a single function. That is, if the libtxc_dxtn.so is not available the s3tc functions should *never* be called.

I changed the format code to add a new "util_format_is_supported" that
allows users to query if the util_format code can pack/unpack a given
format.

That function, if called on an s3tc format, will automatically call
the S3TC init function.
This way, users of the format helpers no longer need to know about
S3TC at all, and it will just work.

Even if the util_format_is_supported function is not called before
reading/writing an S3TC format, the fetch/pack function pointers are
initialized to versions that will autoload the S3TC library.

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.

There are two areas where I'm not totally happy with the approach I did though:
1. Currently upon a successful load of S3TC, we hack the format
descriptions to set the is_supported bit to 1. Not sure if it is the
best way to do it.
2. If S3TC is not available, the functions just do nothing: this is
consistent with other unsupported formats. We may however want to read
black pixels, throw an error, or read a special "error" image instead
(I'd suggest having "unsupported" unpack/pack functions and pointing
all unsupported formats to them)

Also, I think we should remove all the Mesa internal format code and
make it use util_format instead, unless there is really a good reason
to duplicate it all.
Same thing for util_half.

[Mesa3d-dev] [PATCH] gallium: fix dri_destroy_option_cache() when optionCache.info is NULL

[Yann D. <ya...@dr...>]

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_option_cache(): 
optionCache.info is NULL, so it's crashing while trying
to free array content. This patch at least fix the crash in the function.

Here's some logs of the fixed version:

[ 16274.137] LoaderOpen(/opt/mesa/lib/xorg/modules/drivers/intel_drv.so)
[ 16274.139] (II) Loading /opt/mesa/lib/xorg/modules/drivers/intel_drv.so
[ 16274.183] (II) Module intel: vendor="X.Org Foundation"
[ 16274.183]    compiled for 1.8.0, module version = 2.11.0
[ 16274.183]    Module class: X.Org Video Driver
[ 16274.183]    ABI class: X.Org Video Driver, version 7.0
[ 16274.183] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
        i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
        E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
        965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
        4 Series, G45/G43, Q45/Q43, G41, B43, Clarkdale, Arrandale
[ 16274.382] (II) intel(0): Integrated Graphics Chipset: Intel(R) 855GME
[ 16274.382] (--) intel(0): Chipset: "852GM/855GM"
[ 16276.675] (II) intel(0): [DRI2] Setup complete
[ 16276.675] (II) intel(0): [DRI2]   DRI driver: i915
debug_get_option: GALLIUM_TRACE = (null)
debug_get_bool_option: GALLIUM_RBUG = FALSE
debug_get_bool_option: INTEL_DUMP_CMD = FALSE
i915_create_screen: unknown pci id 0x3582, cannot create screen
dri_init_screen_helper: failed to create pipe_screen
[ 16276.794] (EE) AIGLX error: Calling driver entry point failed
[ 16276.794] (EE) AIGLX: reverting to software rendering
[ 16276.794] (II) AIGLX: Screen 0 is not DRI capable
[ 16276.796] (II) AIGLX: Loaded and initialized /opt/mesa/lib/dri/swrast_dri.so
[ 16276.796] (II) GLX: Initialized DRISWRAST GL provider for screen 0

Signed-off-by: Yann Droneaud <ya...@dr...>

---
 src/gallium/state_trackers/dri/common/dri_screen.c |   10 ++++++----
 1 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/gallium/state_trackers/dri/common/dri_screen.c b/src/gallium/state_trackers/dri/common/dri_screen.c
index 6fc7487..6e17614 100644
--- a/src/gallium/state_trackers/dri/common/dri_screen.c
+++ b/src/gallium/state_trackers/dri/common/dri_screen.c
@@ -288,12 +288,14 @@ dri_destroy_option_cache(struct dri_screen * screen)
 {
    int i;
 
-   for (i = 0; i < (1 << screen->optionCache.tableSize); ++i) {
-      FREE(screen->optionCache.info[i].name);
-      FREE(screen->optionCache.info[i].ranges);
+   if (screen->optionCache.info) {
+      for (i = 0; i < (1 << screen->optionCache.tableSize); ++i) {
+         FREE(screen->optionCache.info[i].name);
+         FREE(screen->optionCache.info[i].ranges);
+      }
+      FREE(screen->optionCache.info);
    }
 
-   FREE(screen->optionCache.info);
    FREE(screen->optionCache.values);
 }
 
-- 
1.6.4.4

[Mesa3d-dev] gallium-resources branch merge

[Roland S. <sr...@vm...>]

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 about this branch and what this is
about, here it is:

http://www.mail-archive.com/mes...@li.../msg12726.html

I've also removed the video interfaces completely, as they weren't
ported to the interface changes and actually some of the video code
missed some earlier interface changes so didn't build anyway. Video
related work should be done on pipe-video branch which had newer stuff
(for video) already.


Roland

Re: [Mesa3d-dev] [PATCH 1/2] xdemos: Fix a build failure for non-autoconf configs

[Dan N. <dbn...@gm...>]

On Thu, Apr 1, 2010 at 5:15 PM, Jeremy Huddleston
<jer...@fr...> 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
>> minutes after you posted it. I'll try to straighten it out, though.
>
> Sorry.  Should work now.  I reverted my accidental commit.

OK, I cherry-picked the 4 commits back to the 7.8 branch. This was my
fault anyway since I forgot about the policy of committing on the old
branch and waiting for it to get merged forward.

Having a look at the darwin config, I think it will just work since
you guys have the correct Xlib in APP_LIB_DEPS. This is a minor
attempt to split those up some, so you can set X11_LIBS if you want.

--
Dan

Re: [Mesa3d-dev] [PATCH 1/2] xdemos: Fix a build failure for non-autoconf configs

[Jon T. <jon...@dr...>]

On 02/04/2010 01:14, Jeremy Huddleston wrote:
> On Apr 1, 2010, at 15:13, tom fogal wrote:
>> Jeremy Huddleston<jer...@fr...>  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 haven't wanted to address the issue until the
>>> transition to autotools was completed.
>>
>> We're building swrast on Darwin using autoconf, and have been since
>> 7.4.  I know of an issue with glu on OS X 10.4, but other than that
>> things were fine, last I checked (been a while, admittedly).
>>
>> Could you please report bugs / ping this ML with your autoconf build
>> issues on Darwin?
>
> Last time I did, I was just told that I should address it when I get time,
> and I never got time. ;p
>
> I don't even remember what the problems were any more, but when I try next
> time, I'll ping the list.  I believe at the time there was PKG_CONFIG-foo
> for libdrm, dri2proto, etc which were obviously not relevant to darwin.

If I'm guessing correctly about what the problem is here, you might find the 
patch [1] I posted useful as a starting point.

[1] 
http://sourceforge.net/mailarchive/forum.php?thread_name=20100226152354.GA1960%40byron&forum_name=mesa3d-dev

Re: [Mesa3d-dev] How do we init half float tables?

[Jose F. <jfo...@vm...>]

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 lookup tables: it avoids the initialization problem, and it saves memory when the SO is loaded in several processes as pages can be shared.

For S3TC it is not a real problem: any code that exposes S3TC support needs to check if S3TC (de)compresion support is available before advertising (xxx_screen.c). Checking the support and initialization should be done by a single function. That is, if the libtxc_dxtn.so is not available the s3tc functions should *never* be called.

Jose
________________________________________
From: Luca Barbieri [lu...@lu...]
Sent: Friday, April 02, 2010 2:17
To: Brian Paul
Cc: mes...@li...
Subject: Re: [Mesa3d-dev] How do we init half float tables?

Are you sure about this?

I've tried doing it, and it turns out that basically every Gallium
module needs this initialized.

For instance:
st/mesa due to glReadPixels
vg/mesa due to vgReadPixels
st/python due to mesa sampling
several programs in rbug to dump textures to disk
softpipe due to texture sampling
nv50 due to static attrbutes

Also, if translate did not needlessly duplicate the generic format
support, it would also need it, and draw would too.

Basically everything in Gallium will end up having util_format
initialized, and it seems there are at least 10 different places in
the code where such a call would need to be added (including strange
places like rbug with call pipe*tile* which calls util_format_read*).

I added it for nv50 before realizing the extent of the changes needed,
but now think it is not really a feasible solution.

In other words, I think this should be revisited as it results in
cluttering the codebase and creating a somewhat unreliable system.

I believe that we should either use the global constructor-like
technique I introduced, or do the following:
1. Pregenerate half float tables
2. Initialize the S3TC function pointers to stubs that dlopen the
library, initialize the function pointers to the real functions and
then delegate to the real function corresponding to the stub

More specifically, I think this two-step approach is superior to the
global constructor, but that the global constructor technique may be
useful in other cases where it is not possible to either pregenerate
or have a "free initialization check" due to the S3TC dynamic loading.

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mes...@li...
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 27403] GLSL struct causing "Invalid src register file ..." error

[<bug...@fr...>]

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


Brian Hall <bri...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bri...@gm...




--- Comment #2 from Brian Hall <bri...@gm...>  2010-04-01 21:43:20 PST ---
Oops, I'm sorry.  That's a typo as I was cleaning it up for submission.  It
should read:

VolShad volShad0;
volShad0.texture = volShadSampler0;
volShad0.samples = 8;

It seems that having the sampler3D as a member of the struct is causing the
problem.  I was able to workaround it for now by removing the "texture" field
from the struct and carrying it along as a separate argument to my function.


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

[Mesa3d-dev] [Bug 27403] GLSL struct causing "Invalid src register file ..." error

[<bug...@fr...>]

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





--- Comment #1 from Ian Romanick <id...@fr...>  2010-04-01 21:18:05 PST ---
(In reply to comment #0)
> uniform sampler3D volShadSampler0;
> 
> struct VolShad
> {
>     sampler3D texture;
>     int       samples;
>     int       channels;
>     mat4      worldToScreen;
> };

[snip]

>     VolShad volShad0;
>     volShad0.texture = volShadSampler0;
>     volShad0.texture = 8;

This shouldn't compile.  It is invalid to assign 8 to a sampler3D.


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

Re: [Mesa3d-dev] How do we init half float tables?

[Corbin S. <mos...@gm...>]

On Thu, Apr 1, 2010 at 6:17 PM, Luca Barbieri <lu...@lu...> wrote:
> Are you sure about this?
>
> I've tried doing it, and it turns out that basically every Gallium
> module needs this initialized.
>
> For instance:
> st/mesa due to glReadPixels
> vg/mesa due to vgReadPixels
> st/python due to mesa sampling
> several programs in rbug to dump textures to disk
> softpipe due to texture sampling
> nv50 due to static attrbutes
>
> Also, if translate did not needlessly duplicate the generic format
> support, it would also need it, and draw would too.
>
> Basically everything in Gallium will end up having util_format
> initialized, and it seems there are at least 10 different places in
> the code where such a call would need to be added (including strange
> places like rbug with call pipe*tile* which calls util_format_read*).
>
> I added it for nv50 before realizing the extent of the changes needed,
> but now think it is not really a feasible solution.
>
> In other words, I think this should be revisited as it results in
> cluttering the codebase and creating a somewhat unreliable system.
>
> I believe that we should either use the global constructor-like
> technique I introduced, or do the following:
> 1. Pregenerate half float tables
> 2. Initialize the S3TC function pointers to stubs that dlopen the
> library, initialize the function pointers to the real functions and
> then delegate to the real function corresponding to the stub
>
> More specifically, I think this two-step approach is superior to the
> global constructor, but that the global constructor technique may be
> useful in other cases where it is not possible to either pregenerate
> or have a "free initialization check" due to the S3TC dynamic loading.

I still think you might be overthinking this, but whatever. :3

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<Mos...@gm...>

[Mesa3d-dev] [Bug 27418] latest eglut patches break build

[<bug...@fr...>]

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


Chia-I Wu <ol...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|mesa3d-                     |ol...@gm...
                   |de...@li...   |




--- Comment #1 from Chia-I Wu <ol...@gm...>  2010-04-01 19:05:55 PST ---
I've updated the build rule in 1054f22e480875b2d91c3d9ad1b85080e4705a35.  Could
you verify that if it fixes the bug for you?


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

Re: [Mesa3d-dev] [PATCH] glGet: Optimize glGet calls by avoiding redundant state updates

[Robert B. <bo...@o-...>]

Excerpts from Brian Paul's message of Fri Mar 26 16:13:35 +0000 2010:
> Following up on an message from a while ago:
> 
> Brian Paul wrote:
> > Robert Bragg wrote:
> >> Hi,
> >>
> >> Every now and then while working on the Clutter toolkit we end up with
> >> glGet{Integer,Float}v in our profiles. Our typical response is to simply
> >> cache the offending state so as to avoid querying OpenGL, but it feels
> >> like this is papering over the problem.
> >> I've attached a patch that instead tries to address the performance
> >> problem in Mesa and hoping something like this could be accepted
> >> upstream?
> > 
> > Coincidentally, I was looking at this just recently.
> > 
> > It would be a good change to make.  Though I think I'd add a new flag to 
> > the StateVars table entries to indicate whether the state requires 
> > validation (and what state).  Then auto-generate the needed code.
> > 
> > So GL_RED_BITS case would be predicated like this:
> > 
> >    case GL_RED_BITS:
> >       if (ctx->NewState & _NEW_BUFFERS)
> >          _mesa_update_state(ctx);
> >       params[0] = ctx->DrawBuffer->Visual.redBits;
> >       break;
> > 
> > _NEW_BUFFERS would be a new field in the StateVars list.
> > 
> > 
> > Most state queries don't need validation.  The ones that do are the ones 
> > that you patched plus the "current" attribs (_NEW_CURRENT_ATTRIB).  
> > Maybe a few others?
> > 
> > Are you interested in coding this up?
> 
> I've implemented change this and will be committing it soon.
> 
> -Brian

thanks, sorry I didn't get around to looking at this again myself.
regards,
- Robert

-- 
Robert Bragg, Intel Open Source Technology Center

[Mesa3d-dev] [PATCH updated] xdemos: Build object files first

[Jeremy H. <jer...@fr...>]

This helps debugging on darwin.

Signed-off-by: Jeremy Huddleston <jer...@ap...>
---
 progs/xdemos/Makefile |   45 +++++++++++++++------------------------------
 1 files changed, 15 insertions(+), 30 deletions(-)

diff --git a/progs/xdemos/Makefile b/progs/xdemos/Makefile
index f81aafe..038e21c 100644
--- a/progs/xdemos/Makefile
+++ b/progs/xdemos/Makefile
@@ -53,17 +53,18 @@ EXTRA_PROGS = \
 
 ##### RULES #####
 
-.SUFFIXES:
-.SUFFIXES: .c
+.o: $(LIB_DEP)
+	$(APP_CC) $(CFLAGS) $(LDFLAGS) $< $(LIBS) -o $@
 
-.c: $(LIB_DEP)
-	$(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) $(LDFLAGS) $< $(LIBS) -o $@
+.c.o:
+	$(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) $< -c -o $@
 
 
 ##### TARGETS #####
 
 default: $(PROGS)
 
+$(PROGS): $(PROGS:%=%.o)
 
 extra: $(EXTRA_PROGS)
 
@@ -74,45 +75,29 @@ clean:
 
 
 # special cases
+pbutil.o: pbutil.h
+pbinfo.o: pbutil.h
 pbinfo: pbinfo.o pbutil.o
 	$(APP_CC) $(CFLAGS) $(LDFLAGS) pbinfo.o pbutil.o $(LIBS) -o $@
 
+pbdemo.o: pbutil.h
 pbdemo: pbdemo.o pbutil.o
 	$(APP_CC) $(CFLAGS) $(LDFLAGS) pbdemo.o pbutil.o $(LIBS) -o $@
 
-pbinfo.o: pbinfo.c pbutil.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) pbinfo.c
-
-pbdemo.o: pbdemo.c pbutil.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) pbdemo.c
-
-pbutil.o: pbutil.c pbutil.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) pbutil.c
-
+glxgears_fbconfig.o: pbutil.h
 glxgears_fbconfig: glxgears_fbconfig.o pbutil.o
 	$(APP_CC) $(CFLAGS) $(LDFLAGS) glxgears_fbconfig.o pbutil.o $(LIBS) -o $@
 
-glxgears_fbconfig.o: glxgears_fbconfig.c pbutil.h
-	$(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) -c -I. $(CFLAGS) glxgears_fbconfig.c
-
+xuserotfont.o: xuserotfont.h
+xrotfontdemo.o: xuserotfont.h
 xrotfontdemo: xrotfontdemo.o xuserotfont.o
 	$(APP_CC) $(CFLAGS) $(LDFLAGS) xrotfontdemo.o xuserotfont.o $(LIBS) -o $@
 
-xuserotfont.o: xuserotfont.c xuserotfont.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) xuserotfont.c
-
-xrotfontdemo.o: xrotfontdemo.c xuserotfont.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) xrotfontdemo.c
-
+ipc.o: ipc.h
+corender.o: ipc.h
 corender: corender.o ipc.o
 	$(APP_CC) $(CFLAGS) $(LDFLAGS) corender.o ipc.o $(LIBS) -o $@
 
-corender.o: corender.c ipc.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) corender.c
-
-ipc.o: ipc.c ipc.h
-	$(APP_CC) -c -I. -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) ipc.c
-
-yuvrect_client: yuvrect_client.c
-	$(APP_CC) -I$(INCDIR) $(X11_INCLUDES) $(CFLAGS) $< $(LDFLAGS) $(LIBS) -l$(GLU_LIB) -o $@
+yuvrect_client: yuvrect_client.o
+	$(APP_CC) $(CFLAGS) $< $(LDFLAGS) $(LIBS) -l$(GLU_LIB) -o $@
 
-- 
1.7.0.3

Re: [Mesa3d-dev] How do we init half float tables?

[Luca B. <lu...@lu...>]

Are you sure about this?

I've tried doing it, and it turns out that basically every Gallium
module needs this initialized.

For instance:
st/mesa due to glReadPixels
vg/mesa due to vgReadPixels
st/python due to mesa sampling
several programs in rbug to dump textures to disk
softpipe due to texture sampling
nv50 due to static attrbutes

Also, if translate did not needlessly duplicate the generic format
support, it would also need it, and draw would too.

Basically everything in Gallium will end up having util_format
initialized, and it seems there are at least 10 different places in
the code where such a call would need to be added (including strange
places like rbug with call pipe*tile* which calls util_format_read*).

I added it for nv50 before realizing the extent of the changes needed,
but now think it is not really a feasible solution.

In other words, I think this should be revisited as it results in
cluttering the codebase and creating a somewhat unreliable system.

I believe that we should either use the global constructor-like
technique I introduced, or do the following:
1. Pregenerate half float tables
2. Initialize the S3TC function pointers to stubs that dlopen the
library, initialize the function pointers to the real functions and
then delegate to the real function corresponding to the stub

More specifically, I think this two-step approach is superior to the
global constructor, but that the global constructor technique may be
useful in other cases where it is not possible to either pregenerate
or have a "free initialization check" due to the S3TC dynamic loading.

Re: [Mesa3d-dev] [PATCH 2/2] xdemos: Build object files first

[Jeremy H. <jer...@fr...>]

On Apr 1, 2010, at 15:27, Dan Nicholson wrote:

> On Thu, Apr 1, 2010 at 2:40 PM, Jeremy Huddleston
> <jer...@fr...> wrote:
>> 
>> On Apr 1, 2010, at 14:18, Dan Nicholson wrote:
>> 
>>>> +$(PROGS): $(PROGS:%=%.o)
>>> 
>>> Is this necessary? I would think the prereq would be picked up
>>> implicitly like the .c from the .o.
>> 
>> Nope.  Without this, it tries to compile the .c directly to the executable rather than the .o first.
> 
> Even after you remove the .SUFFIXES lines?

Yep.

> Yeah, I guess it would have
> that assumption since the names are the same.

I know it's ugly.  I tried finding another way, but that's what ended up working =/

> automake/libtool certainly passes both CFLAGS and LDFLAGS during the
> linking step. All the other targets in this same Makefile do, too. For
> better or worse, I think we need to pass the CFLAGS during the link.

ok.  I'll send an updated version in a bit for review.

Thanks,
Jeremy

Re: [Mesa3d-dev] [PATCH 1/2] xdemos: Fix a build failure for non-autoconf configs

[Jeremy H. <jer...@fr...>]

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
> minutes after you posted it. I'll try to straighten it out, though.

Sorry.  Should work now.  I reverted my accidental commit.

>> I'm using the "darwin" config.  I can't use autoconf because it is nowhere near capable of handling darwin, and I haven't wanted to address the issue until the transition to autotools was completed.
> 
> I don't know if there is more of a transition to complete.

Oh, I thought that automake was in the plans...

Well, I'll look into supporting autoconf on darwin glx once I finish bringing the two trains back together. 

Re: [Mesa3d-dev] [PATCH 1/2] xdemos: Fix a build failure for non-autoconf configs

[Jeremy H. <jer...@fr...>]

On Apr 1, 2010, at 15:13, tom fogal wrote:

> Jeremy Huddleston <jer...@fr...> 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 haven't wanted to address the issue until the
>> transition to autotools was completed.
> 
> We're building swrast on Darwin using autoconf, and have been since
> 7.4.  I know of an issue with glu on OS X 10.4, but other than that
> things were fine, last I checked (been a while, admittedly).
> 
> Could you please report bugs / ping this ML with your autoconf build
> issues on Darwin?

Last time I did, I was just told that I should address it when I get time, and I never got time. ;p

I don't even remember what the problems were any more, but when I try next time, I'll ping the list.  I believe at the time there was PKG_CONFIG-foo for libdrm, dri2proto, etc which were obviously not relevant to darwin.

--Jeremy