Re: [Mesa3d-dev] C++ in Mesa?
On Monday 05 January 2009 17:23:40 Ian Romanick wrote: > 2. Linking with C++ libraries causes problems with applications. > > So far, a fair portion of my GLSL compiler work has been re-creating a > C++-like object heirarchy and management system. Frankly, the code > would be much better (for all definitions of better) if I could just > use C++. > > Has issue #2 been resolved? I recall that, for example, if ID's > Quake3 binary dynamically linked with a library that dynamically > linked with a different version of libstdc++, it would explode. Is > that still the case? If this is still a problem, will it affect LLVM > usage in Mesa? LLVM is a bunch of static libs so we can easily impose stdc++ version on them that Mesa would be fine with. So LLVM will be ok. If different versions of stdc++ are a worry, I'd suggest writing a super simple GL app that links to libstdc++5 and then link GL to libstdc++6 and seeing what happens (even if it burns I honestly think that a disclaimer saying that 10 year old apps that link to libstdc++5 won't work with newest Mesa without recompiling is not a huge issue) Oh, and from what you wrote it sounds like, at least right now, you don't need stdc++. z -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] C++ in Mesa?
Corbin Simpson wrote: > Ian Romanick wrote: >> Other than keithp (I know your opinion), does anyone have any strong >> opinions for or against using C++ in the GLSL compiler? > > > I have a strong opinion against strong opinions against using C++. :3 > > Seriously, C++ is a very powerful language when it comes to offering > certain kinds of object manipulation while still having most of the > low-level constructs we need in C to do what we're doing. Additionally, > LLVM is much simpler to interface with in C++ due to more powerful bindings. > > The big problem, in my mind, is that people start to use things like > RTTI and exceptions instead of properly figuring out what their code > should actually look like and reading the STL docs, and then somebody > suggests linking to Boost, and then we're all off to hell in a bloody > handbasket woven with good intentions and auto_ptrs. > > So, if we can keep it simple, clean, and direct, I have no problem with > C++. (FWIW) My sentiment exactly. Let's restrict C++ use to where it's really needed and keep it simple. -Brian -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] C++ in Mesa?
Ian Romanick wrote: > On Mon, Jan 05, 2009 at 04:21:11PM -0700, Brian Paul wrote: >> Ian Romanick wrote: >>> Once upon a time, there was talk of converting some parts of Mesa to >>> C++. This was killed for a number of reasons, and these fell into >>> basically two categories: >>> >>> 1. C++ would make the drivers worse. >>> >>> 2. Linking with C++ libraries causes problems with applications. >>> >>> So far, a fair portion of my GLSL compiler work has been re-creating a >>> C++-like object heirarchy and management system. Frankly, the code >>> would be much better (for all definitions of better) if I could just >>> use C++. >>> >>> Has issue #2 been resolved? I recall that, for example, if ID's >>> Quake3 binary dynamically linked with a library that dynamically >>> linked with a different version of libstdc++, it would explode. Is >>> that still the case? If this is still a problem, will it affect LLVM >>> usage in Mesa? >> 2 is not an issue. libGLU uses C++ code. You just have to pass the >> -cplusplus flag to the mklib script. > > Right...but most apps don't use libGLU. :) I can't find it in the > mailing list archives, but my recollection is that when someone tried > linking libGL or a *_dri.so with libstdc++, it caused problems. > Specificially, the libstdc++ version used was different from the > version Quake3 used. This caused Quake3 to explode. > > That said, fglrx links with libstdc++, and it doesn't seem to pose any > problems there. Maybe try putting some simple/meaningless C++ code in the i965 driver, link the driver with libstdc++ and see if anyone complains. I'd be OK with that in Mesa 7.3 (for which a release candidate is overdue). > Other than keithp (I know your opinion), does anyone have any strong > opinions for or against using C++ in the GLSL compiler? OK by me. -Brian -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] C++ in Mesa?
Ian Romanick wrote: > Other than keithp (I know your opinion), does anyone have any strong > opinions for or against using C++ in the GLSL compiler? I have a strong opinion against strong opinions against using C++. :3 Seriously, C++ is a very powerful language when it comes to offering certain kinds of object manipulation while still having most of the low-level constructs we need in C to do what we're doing. Additionally, LLVM is much simpler to interface with in C++ due to more powerful bindings. The big problem, in my mind, is that people start to use things like RTTI and exceptions instead of properly figuring out what their code should actually look like and reading the STL docs, and then somebody suggests linking to Boost, and then we're all off to hell in a bloody handbasket woven with good intentions and auto_ptrs. So, if we can keep it simple, clean, and direct, I have no problem with C++. (FWIW) ~ C. -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] C++ in Mesa?
On Mon, Jan 05, 2009 at 04:21:11PM -0700, Brian Paul wrote: > Ian Romanick wrote: > > Once upon a time, there was talk of converting some parts of Mesa to > > C++. This was killed for a number of reasons, and these fell into > > basically two categories: > > > > 1. C++ would make the drivers worse. > > > > 2. Linking with C++ libraries causes problems with applications. > > > > So far, a fair portion of my GLSL compiler work has been re-creating a > > C++-like object heirarchy and management system. Frankly, the code > > would be much better (for all definitions of better) if I could just > > use C++. > > > > Has issue #2 been resolved? I recall that, for example, if ID's > > Quake3 binary dynamically linked with a library that dynamically > > linked with a different version of libstdc++, it would explode. Is > > that still the case? If this is still a problem, will it affect LLVM > > usage in Mesa? > > 2 is not an issue. libGLU uses C++ code. You just have to pass the > -cplusplus flag to the mklib script. Right...but most apps don't use libGLU. :) I can't find it in the mailing list archives, but my recollection is that when someone tried linking libGL or a *_dri.so with libstdc++, it caused problems. Specificially, the libstdc++ version used was different from the version Quake3 used. This caused Quake3 to explode. That said, fglrx links with libstdc++, and it doesn't seem to pose any problems there. Other than keithp (I know your opinion), does anyone have any strong opinions for or against using C++ in the GLSL compiler? pgpP3NEyEhgH6.pgp Description: PGP signature -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] C++ in Mesa?
Ian Romanick wrote: > Once upon a time, there was talk of converting some parts of Mesa to > C++. This was killed for a number of reasons, and these fell into > basically two categories: > > 1. C++ would make the drivers worse. > > 2. Linking with C++ libraries causes problems with applications. > > So far, a fair portion of my GLSL compiler work has been re-creating a > C++-like object heirarchy and management system. Frankly, the code > would be much better (for all definitions of better) if I could just > use C++. > > Has issue #2 been resolved? I recall that, for example, if ID's > Quake3 binary dynamically linked with a library that dynamically > linked with a different version of libstdc++, it would explode. Is > that still the case? If this is still a problem, will it affect LLVM > usage in Mesa? 2 is not an issue. libGLU uses C++ code. You just have to pass the -cplusplus flag to the mklib script. -Brian -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] SIMDize sorting in setup_sort_vertices()
Brian Paul wrote:
> Jonathan Adamczewski wrote:
>> Put setup.v{min,mid,max,provoke} into a union with qword vertex_headers.
>>
>> Rewrite vertex sorting to more efficiently handle the packed data items.
>>
>> Reduces spu_tri.o by ~128 bytes.
>
> That's pretty clever!
Thanks :)
>
> I've committed your latest patches.
>
> I wonder if you could attach future patches to your email as .zip files
> or something. As-is, I had to manually edit the patches to remove some
> weird character encodings.
I'll look into what might be causing it - I've noticed some odd encoding
problems between my PS3 and desktop machine.
j.
--
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] C++ in Mesa?
Once upon a time, there was talk of converting some parts of Mesa to C++. This was killed for a number of reasons, and these fell into basically two categories: 1. C++ would make the drivers worse. 2. Linking with C++ libraries causes problems with applications. So far, a fair portion of my GLSL compiler work has been re-creating a C++-like object heirarchy and management system. Frankly, the code would be much better (for all definitions of better) if I could just use C++. Has issue #2 been resolved? I recall that, for example, if ID's Quake3 binary dynamically linked with a library that dynamically linked with a different version of libstdc++, it would explode. Is that still the case? If this is still a problem, will it affect LLVM usage in Mesa? pgpaY7twrS3Bc.pgp Description: PGP signature -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Status of "non-SOA" path in Gallium3D driver
On Tue, Dec 30, 2008 at 02:08:37PM -0500, Zack Rusin wrote: > Dependingly on which way the instruction set of modern gpus is going to head, > aos will either become completely irrelevant soon (more likely) or aos will > get more important. Either way as it stands we should concentrate on soa for > now. AoS is likely to remain important for vertex shading. In the vertex shader and geometry shader you don't have an derivatives. By using AoS you avoid taking a hit when some elements take different branch paths. pgpB2J15cqOy4.pgp Description: PGP signature -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11404] Nexuiz GLSL shader compilation fails
http://bugs.freedesktop.org/show_bug.cgi?id=11404 --- Comment #15 from Roland Scheidegger 2009-01-05 07:17:42 PST --- (In reply to comment #11) > Radeons also have the 8-texture-unit limit, at least up to the X1950. (Haven't > figured out yet whether the limit's higher on HD series cards.) Might be worth > seeing if it's possible to use less textures, or at least have a fallback > shader for older cards... Not true. All radeons from r300 and up have 16 texture samplers (image units). Texture coord units are indeed limited to 8 but that shouldn't be a problem. (I don't know what the limits are for r600, apparently sampler id must be from 0-17 so that would be 18 samplers, not sure what the limit is on "coord units" for the r600 if there even is one (might just be limited by available registers or something) but I'd guess it could handle more than 8). -- 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 mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] SIMDize sorting in setup_sort_vertices()
Jonathan Adamczewski wrote:
> Put setup.v{min,mid,max,provoke} into a union with qword vertex_headers.
>
> Rewrite vertex sorting to more efficiently handle the packed data items.
>
> Reduces spu_tri.o by ~128 bytes.
That's pretty clever!
I've committed your latest patches.
I wonder if you could attach future patches to your email as .zip files
or something. As-is, I had to manually edit the patches to remove some
weird character encodings.
-Brian
--
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] SIMDize sorting in setup_sort_vertices()
Just wanted to say I love this set of patches... I always hoped that
someone would be able to find a CPU-friendly path through triangle
setup, it looks like you're definitely on the right track...
Keith
On Sun, 2009-01-04 at 19:52 -0800, Jonathan Adamczewski wrote:
> Put setup.v{min,mid,max,provoke} into a union with qword vertex_headers.
>
> Rewrite vertex sorting to more efficiently handle the packed data items.
>
> Reduces spu_tri.o by ~128 bytes.
> ---
> src/gallium/drivers/cell/spu/spu_tri.c | 97
> ++--
> 1 files changed, 42 insertions(+), 55 deletions(-)
>
> diff --git a/src/gallium/drivers/cell/spu/spu_tri.c
> b/src/gallium/drivers/cell/spu/spu_tri.c
> index 30531d3..c7ff75c 100644
> --- a/src/gallium/drivers/cell/spu/spu_tri.c
> +++ b/src/gallium/drivers/cell/spu/spu_tri.c
> @@ -103,10 +103,15 @@ struct setup_stage {
> * turn. Currently fixed at 4 floats, but should change in time.
> * Codegen will help cope with this.
> */
> - const struct vertex_header *vmax;
> - const struct vertex_header *vmid;
> - const struct vertex_header *vmin;
> - const struct vertex_header *vprovoke;
> + union {
> + struct {
> + const struct vertex_header *vmin;
> + const struct vertex_header *vmid;
> + const struct vertex_header *vmax;
> + const struct vertex_header *vprovoke;
> + };
> + qword vertex_headers;
> + };
>
> struct edge ebot;
> struct edge etop;
> @@ -452,55 +457,39 @@ setup_sort_vertices(const struct vertex_header *v0,
>
> /* determine bottom to top order of vertices */
> {
> - float y0 = spu_extract(v0->data[0], 1);
> - float y1 = spu_extract(v1->data[0], 1);
> - float y2 = spu_extract(v2->data[0], 1);
> - if (y0 <= y1) {
> - if (y1 <= y2) {
> - /* y0<=y1<=y2 */
> - setup.vmin = v0;
> - setup.vmid = v1;
> - setup.vmax = v2;
> -sign = -1.0f;
> - }
> - else if (y2 <= y0) {
> - /* y2<=y0<=y1 */
> - setup.vmin = v2;
> - setup.vmid = v0;
> - setup.vmax = v1;
> -sign = -1.0f;
> - }
> - else {
> - /* y0<=y2<=y1 */
> - setup.vmin = v0;
> - setup.vmid = v2;
> - setup.vmax = v1;
> -sign = 1.0f;
> - }
> - }
> - else {
> - if (y0 <= y2) {
> - /* y1<=y0<=y2 */
> - setup.vmin = v1;
> - setup.vmid = v0;
> - setup.vmax = v2;
> -sign = 1.0f;
> - }
> - else if (y2 <= y1) {
> - /* y2<=y1<=y0 */
> - setup.vmin = v2;
> - setup.vmid = v1;
> - setup.vmax = v0;
> -sign = 1.0f;
> - }
> - else {
> - /* y1<=y2<=y0 */
> - setup.vmin = v1;
> - setup.vmid = v2;
> - setup.vmax = v0;
> -sign = -1.0f;
> - }
> - }
> + /* A table of shuffle patterns for putting vertex_header pointers into
> + correct order. Quite magical. */
> + const vec_uchar16 sort_order_patterns[] = {
> + SHUFFLE4(A,B,C,C),
> + SHUFFLE4(C,A,B,C),
> + SHUFFLE4(A,C,B,C),
> + SHUFFLE4(B,C,A,C),
> + SHUFFLE4(B,A,C,C),
> + SHUFFLE4(C,B,A,C) };
> +
> + /* The vertex_header pointers, packed for easy shuffling later */
> + const vec_uint4 vs = {(unsigned)v0, (unsigned)v1, (unsigned)v2};
> +
> + /* Collate y values into two vectors for comparison.
> + Using only one shuffle constant! ;) */
> + const vec_float4 y_02_ = spu_shuffle(v0->data[0], v2->data[0],
> SHUFFLE4(0,B,b,C));
> + const vec_float4 y_10_ = spu_shuffle(v1->data[0], v0->data[0],
> SHUFFLE4(0,B,b,C));
> + const vec_float4 y_012 = spu_shuffle(y_02_, v1->data[0],
> SHUFFLE4(0,B,b,C));
> + const vec_float4 y_120 = spu_shuffle(y_10_, v2->data[0],
> SHUFFLE4(0,B,b,C));
> +
> + /* Perform comparison: {y0,y1,y2} > {y1,y2,y0} */
> + const vec_uint4 compare = spu_cmpgt(y_012, y_120);
> + /* Compress the result of the comparison into 4 bits */
> + const vec_uint4 gather = spu_gather(compare);
> + /* Subtract one to attain the index into the LUT. Magical. */
> + const unsigned int index = spu_extract(gather, 0) - 1;
> +
> + /* Load the appropriate pattern and construct the desired vector. */
> + setup.vertex_headers = (qword)spu_shuffle(vs, vs,
> sort_order_patterns[index]);
> +
> + /* Using the result of the comparison, set sign.
> + Very magical. */
> + sign = ((si_to_uint(si_cntb((qword)gather)) == 2) ? 1.0f : -1.0f);
> }
>
> /* Check if triangle is completely outside the tile bounds */
> @@ -543,8 +532,6 @@ setup_sort_vertices(const struct vertex_header *v0,
> setup.facing = (area * sign > 0.0f)
>^ (spu.rasterizer.front_winding == PIPE_WINDING_CW);
>
> - setup.vprovoke = v2;
> -
> return TRUE;
>
