[Mesa-dev] first attempt at shader stencil export
some background: so on r600g, the only way to directly write to the stencil is via the shader, using a transfer would require an extra step to flush the DS buffer out via the pipe again to make it useable by the hw as a DS buffer. So using the current gallium stencil draw would be a major overhead, compared to just doing it properly. So to do it properly I decided to expose the GL_ARB_shader_stencil_export type functionality. http://cgit.freedesktop.org/~airlied/mesa/log/?h=gallium-stencil-export 7 commits in here: two simple one liners, add the cap to gallium headers, and add FRAG_RESULT_STENCIL to mesa. then a "fix" to the mesa texstore so it will store S8 in an 8/24 so we can put the stencil values in a texture. mesa state tracker support to use the new capability to hw accel drawpixels on the stencil (outputs to Y of FRAG_RESULT_STENCIL). r600g support for the capability take the second TGSI_SEMANTIC_POSITION output and use its Y value as stencil (looking at this now, I should probably be taking the X value really). very initial mesa/GLSL support for the extension (completely untested). initial softpipe support for the capability a demonstration. TODO: probably stop using Y (this was just because the hw uses Y), the GLSL extension just defines an integer output for the fragprog. fix the 24/8 texstore variant. write some test code for piglit and test the GL extension/GLSL bits. I'm a lot more interested in the non-GL extension bits as it allows stencil writes to work properly on r600g. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] depth writing and missing something
Sorry, I've should have drunk my morning coffee before replying. You're refferring to writing and not reading... Anyway, my comment for u_format still stands. But back to your example, it works because out[0] has position semantic. When writing to depth textures, their are bound as depth stencil buffer. Not in the color buffer. And whatever gets written to the z channel of the output position register will be used as the depth value. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Jose Fonseca [jfons...@vmware.com] Sent: Thursday, September 30, 2010 7:28 To: Dave Airlie; mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] depth writing and missing something There are two things to consider: u_format.csv description for depth stencils is a bit special for practical reasons, and pipe_sampler_view swizzles. Several functions in u_format_xxx.c need to be able to read/write stencil, and this is why u_format.csv describes depth stencil's swizzles as producing Z S x x. But the stencil channel will never be present when the texture is read as RGBA tuple. Sampling from a depthstencil texture should always produce Z Z Z 1 or Z 0 0 1, even before any sampler swizzles are applied. I think Brian documented this somewhere in gallium/docs/ but I can't find it now. At any rate, provided the first channel has z, then the state tracker will specify how he wants the other channels to be filled in the pipe_sampler_view' swizzles. Effectively, the gallium spec could say that sampling from depth textures should match (Z x x x). This is my understanding of the current state. We could polish this more a little. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Dave Airlie [airl...@gmail.com] Sent: Thursday, September 30, 2010 2:34 To: mesa-dev@lists.freedesktop.org Subject: [Mesa-dev] depth writing and missing something So I've been playing with stencil writing on r600, and it lead me to examine the depth writing. So at the moment in gallium if we are writing to depth via DrawPixels, we construct a fragment program that samples from a texture. TEX OUT[0].z, IN[1], SAMP[0], 2D Now from what I can see the format we pick to sample from is Z24_UNORM_S8_USCALED, which from the u_format.csv file seems to say it will put the results into X and Y components. Now if we sample from the X and Y components and the texture dest writemask is Z, I can't see how any value arrives in the right place. It seems to work but I'm a bit lost where the magic is. I'd have expected there to be swizzles in the sampler but I can't see them being set to anything special either. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] depth writing and missing something
There are two things to consider: u_format.csv description for depth stencils is a bit special for practical reasons, and pipe_sampler_view swizzles. Several functions in u_format_xxx.c need to be able to read/write stencil, and this is why u_format.csv describes depth stencil's swizzles as producing Z S x x. But the stencil channel will never be present when the texture is read as RGBA tuple. Sampling from a depthstencil texture should always produce Z Z Z 1 or Z 0 0 1, even before any sampler swizzles are applied. I think Brian documented this somewhere in gallium/docs/ but I can't find it now. At any rate, provided the first channel has z, then the state tracker will specify how he wants the other channels to be filled in the pipe_sampler_view' swizzles. Effectively, the gallium spec could say that sampling from depth textures should match (Z x x x). This is my understanding of the current state. We could polish this more a little. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Dave Airlie [airl...@gmail.com] Sent: Thursday, September 30, 2010 2:34 To: mesa-dev@lists.freedesktop.org Subject: [Mesa-dev] depth writing and missing something So I've been playing with stencil writing on r600, and it lead me to examine the depth writing. So at the moment in gallium if we are writing to depth via DrawPixels, we construct a fragment program that samples from a texture. TEX OUT[0].z, IN[1], SAMP[0], 2D Now from what I can see the format we pick to sample from is Z24_UNORM_S8_USCALED, which from the u_format.csv file seems to say it will put the results into X and Y components. Now if we sample from the X and Y components and the texture dest writemask is Z, I can't see how any value arrives in the right place. It seems to work but I'm a bit lost where the magic is. I'd have expected there to be swizzles in the sampler but I can't see them being set to anything special either. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Gordon Jin changed: What|Removed |Added Depends on||30192 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30192] Doom3-demo segfaults since glsl2 branch merged.
https://bugs.freedesktop.org/show_bug.cgi?id=30192 Gordon Jin changed: What|Removed |Added Blocks||29044 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Gordon Jin changed: What|Removed |Added Depends on||30238 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30484] New: Mesa 7.9.2-rc2 and git fail to compile
https://bugs.freedesktop.org/show_bug.cgi?id=30484 Summary: Mesa 7.9.2-rc2 and git fail to compile Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: wol...@onsneteindhoven.nl Mesa 7.9.2-rc2 and git fail to compile ---: In file included from xorg_driver.c:42:0: /usr/include/xorg/edid.h:623:4: warning: declaration does not declare anything xorg_driver.c: In function ‘xorg_tracker_have_modesetting’: xorg_driver.c:125:5: warning: ‘Xalloc’ is deprecated (declared at /usr/include/xorg/os.h:221) xorg_driver.c:133:2: warning: ‘Xfree’ is deprecated (declared at /usr/include/xorg/os.h:234) xorg_driver.c:140:5: warning: ‘Xfree’ is deprecated (declared at /usr/include/xorg/os.h:234) xorg_driver.c: In function ‘drv_free_rec’: xorg_driver.c:177:5: warning: ‘Xfree’ is deprecated (declared at /usr/include/xorg/os.h:234) xorg_driver.c: In function ‘drv_init_drm’: xorg_driver.c:277:2: warning: ‘Xalloc’ is deprecated (declared at /usr/include/xorg/os.h:221) xorg_driver.c:286:2: warning: ‘Xfree’ is deprecated (declared at /usr/include/xorg/os.h:234) xorg_driver.c: In function ‘drv_pre_init’: xorg_driver.c:447:5: warning: ‘Xalloc’ is deprecated (declared at /usr/include/xorg/os.h:221) xorg_driver.c: In function ‘drv_bind_front_buffer_kms’: xorg_driver.c:1188:10: error: ‘struct _ScrnInfoRec’ has no member named ‘pixmapPrivate’ make[4]: *** [xorg_driver.o] Error 1 make[4]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src/gallium/state_trackers/xorg' make[3]: *** [subdirs] Error 1 make[3]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src/gallium/state_trackers' make[2]: *** [default] Error 1 make[2]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src/gallium' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src' make: *** [default] Error 1 --- the error ‘struct _ScrnInfoRec’ has no member named ‘pixmapPrivate’ seems to be caused by 'Kill pixmapPrivate with a vengeance (v2)' applied by Chris Wilson in version 5c6a2f93ebc16a78093782b442306de23ae94e78 of xserver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] State of gallium driver for i915/945
Hi,I've been following the development of mesa and gallium for some time now. Each time a developer talks about the gallium i915/945 driver, it's always in an "almost done" state... However, even now, it doesn't support everything the dri driver does (glxinfo shows less extensions and so on for the gallium driver). Is there a plan to complete the work? What's its state? What still needs to be done? Is there enough information around to do it? Is someone actively working on it? I'd be interested to work on it if something can be done.Thanks,Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] depth writing and missing something
So I've been playing with stencil writing on r600, and it lead me to examine the depth writing. So at the moment in gallium if we are writing to depth via DrawPixels, we construct a fragment program that samples from a texture. TEX OUT[0].z, IN[1], SAMP[0], 2D Now from what I can see the format we pick to sample from is Z24_UNORM_S8_USCALED, which from the u_format.csv file seems to say it will put the results into X and Y components. Now if we sample from the X and Y components and the texture dest writemask is Z, I can't see how any value arrives in the right place. It seems to work but I'm a bit lost where the magic is. I'd have expected there to be swizzles in the sampler but I can't see them being set to anything special either. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30481] New: OpenVG demos does not launch
https://bugs.freedesktop.org/show_bug.cgi?id=30481 Summary: OpenVG demos does not launch Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Demos AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: virtuous...@gmail.com programs "lion" and "sp" from mesa-progs (commit: 60eeb7b3062af90ae5ca175f3fe31739f4ca845e) fail to launch with error: symbol lookup error: /usr/lib64/egl/egl_gallium.so: undefined symbol: drmGetMagic while demos for glx, egl and gles works just fine. i use r300g on RV515 with mesa-git (commit: 4378c17c88c6d1fb046f53ef83955fd7fbd992db). kernel is 2.6.35. global CFLAGS set to "-march=k8-sse3 -Os -mfpmath=sse,387 -frename-registers -ftree-vectorize -floop-interchange -floop-strip-mine -floop-block -ftree-loop-distribution -floop-parallelize-all -Wno-error -pipe" LDFLAGS="-Wl,--sort-common -Wl,--enable-new-dtags -Wl,--as-needed -Wl,--hash-style=gnu -Wl,-O1 -Wl,-znow -Wl,-zmuldefs". tried LDFLAGS="" CFLAGS="-march=k8-sse3 -O2 -pipe". didn't helped. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Implement x86_64 atomics for compilers w/o intrinsics.
ping?
-tom
tom fogal writes:
> A friend of mine had trouble building 7.8.2 on an old gcc3.3 system
> (no gcc intrinsics). I put together this patch and he said his build
> worked. Our software doesn't thread so it's not really verified
> otherwise.
>
> I was a bit surprised we didn't need int64_t variants for x86_64.
> Maybe that's needed in general, but just not in swrast / under Mesa
> w/ our particular option set?
>
> Anyway, okay for 7.8 and master?
>
> -tom
>
>
> --- =_aa0
> Content-Type: text/x-diff; charset="us-ascii"
> Content-ID: <7248.128555187...@shigeru.sci.utah.edu>
> Content-Description: 0001-Implement-x86_64-atomics-for-compilers-w-o-intrinsi
> c.patch
> Content-Transfer-Encoding: quoted-printable
>
> =46rom cc32ff741c5d32a66531a586b1f9268b94846c58 Mon Sep 17 00:00:00 2001
> From: Tom Fogal
> Date: Sun, 26 Sep 2010 18:57:59 -0600
> Subject: [PATCH] Implement x86_64 atomics for compilers w/o intrinsics.
>
> Really old gcc's (3.3, at least) don't have support for the
> intrinsics we need. This implements a fallback for that case.
> ---
> src/gallium/auxiliary/util/u_atomic.h | 47 =
> +
> 1 files changed, 47 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/auxiliary/util/u_atomic.h b/src/gallium/auxiliary=
> /util/u_atomic.h
> index a156823..8434491 100644
> --- a/src/gallium/auxiliary/util/u_atomic.h
> +++ b/src/gallium/auxiliary/util/u_atomic.h
> @@ -29,6 +29,8 @@
> #define PIPE_ATOMIC_ASM_MSVC_X86=
>
> #elif (defined(PIPE_CC_GCC) && defined(PIPE_ARCH_X86))
> #define PIPE_ATOMIC_ASM_GCC_X86
> +#elif (defined(PIPE_CC_GCC) && defined(PIPE_ARCH_X86_64))
> +#define PIPE_ATOMIC_ASM_GCC_X86_64
> #elif defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >=3D 401)
> #define PIPE_ATOMIC_GCC_INTRINSIC
> #else
> @@ -36,6 +38,51 @@
> #endif
> =
>
> =
>
> +#if defined(PIPE_ATOMIC_ASM_GCC_X86_64)
> +#define PIPE_ATOMIC "GCC x86_64 assembly"
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#define p_atomic_set(_v, _i) (*(_v) =3D (_i))
> +#define p_atomic_read(_v) (*(_v))
> +
> +static INLINE boolean
> +p_atomic_dec_zero(int32_t *v)
> +{
> + unsigned char c;
> +
> + __asm__ __volatile__("lock; decl %0; sete %1":"+m"(*v), "=3Dqm"(c)
> + ::"memory");
> +
> + return c !=3D 0;
> +}
> +
> +static INLINE void
> +p_atomic_inc(int32_t *v)
> +{
> + __asm__ __volatile__("lock; incl %0":"+m"(*v));
> +}
> +
> +static INLINE void
> +p_atomic_dec(int32_t *v)
> +{
> + __asm__ __volatile__("lock; decl %0":"+m"(*v));
> +}
> +
> +static INLINE int32_t
> +p_atomic_cmpxchg(int32_t *v, int32_t old, int32_t _new)
> +{
> + return __sync_val_compare_and_swap(v, old, _new);
> +}
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* PIPE_ATOMIC_ASM_GCC_X86_64 */
> +
> =
>
> #if defined(PIPE_ATOMIC_ASM_GCC_X86)
> =
>
> -- =
>
> 1.7.0.2
>
>
> --- =_aa0
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> --- =_aa0--
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Makefile: ensure Gallium's Makefile.xorg and SConscript.dri are in the tarball
On 09/29/2010 05:02 AM, Marek Olšák wrote: --- Makefile |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index eb90650..42f1c0a 100644 --- a/Makefile +++ b/Makefile @@ -329,6 +329,8 @@ GALLIUM_FILES = \ $(DIRECTORY)/src/gallium/Makefile.template \ $(DIRECTORY)/src/gallium/SConscript \ $(DIRECTORY)/src/gallium/targets/Makefile.dri \ + $(DIRECTORY)/src/gallium/targets/Makefile.xorg \ + $(DIRECTORY)/src/gallium/targets/SConscript.dri \ $(DIRECTORY)/src/gallium/*/Makefile \ $(DIRECTORY)/src/gallium/*/SConscript \ $(DIRECTORY)/src/gallium/*/*/Makefile \ Committed. Thanks. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: add initial support to double opcodes in llvmpipe.
Yep,
See bellow. Basically the output is not smooth because the OUT[0].x is
the msb from double enad the OUT[0].y is the lsb.
Igor
diff --git a/src/gallium/tests/python/samples/tri.py
b/src/gallium/tests/python/samples/tri.py
index 6d17c88..5b74c16 100644
--- a/src/gallium/tests/python/samples/tri.py
+++ b/src/gallium/tests/python/samples/tri.py
@@ -154,8 +154,8 @@ def test(dev):
rgba = FloatArray(4);
rgba[0] = 0.0
rgba[1] = 0.0
-rgba[2] = 0.0
-rgba[3] = 0.0
+rgba[2] = 1.0
+rgba[3] = 1.0
ctx.clear(PIPE_CLEAR_COLOR | PIPE_CLEAR_DEPTHSTENCIL, rgba, 1.0, 0xff)
# vertex shader
@@ -176,8 +176,10 @@ def test(dev):
FRAG
DCL IN[0], COLOR, LINEAR
DCL OUT[0], COLOR, CONSTANT
-0:MOV OUT[0], IN[0]
-1:END
+DCL TEMP[0]
+0:DMUL TEMP[0].xy, IN[0], IN[0]
+1:MOV OUT[0], TEMP[0]
+2:END
''')
ctx.set_fragment_shader(fs)
@@ -189,25 +191,30 @@ def test(dev):
verts[ 1] = 0.8 # y1
verts[ 2] = 0.2 # z1
verts[ 3] = 1.0 # w1
+
verts[ 4] = 1.0 # r1
-verts[ 5] = 0.0 # g1
-verts[ 6] = 0.0 # b1
-verts[ 7] = 1.0 # a1
+verts[ 5] = 1.0 # g1
+verts[ 6] = 0.6 # b1
+verts[ 7] = 0.6 # a1
+
verts[ 8] = -0.8 # x2
verts[ 9] = -0.8 # y2
verts[10] = 0.5 # z2
verts[11] = 1.0 # w2
-verts[12] = 0.0 # r2
-verts[13] = 1.0 # g2
-verts[14] = 0.0 # b2
-verts[15] = 1.0 # a2
+
+verts[12] = 0.6 # r2
+verts[13] = 0.6 # g2
+verts[14] = 0.6 # b2
+verts[15] = 0.6 # a2
+
verts[16] = 0.8 # x3
verts[17] = -0.8 # y3
verts[18] = 0.8 # z3
verts[19] = 1.0 # w3
-verts[20] = 0.0 # r3
-verts[21] = 0.0 # g3
-verts[22] = 1.0 # b3
+
+verts[20] = 1.0 # r3
+verts[21] = 1.0 # g3
+verts[22] = 0.6 # b3
verts[23] = 1.0 # a3
ctx.draw_vertices(PIPE_PRIM_TRIANGLES,
On Wed, Sep 29, 2010 at 10:57 AM, José Fonseca wrote:
> Could you please send me the modified tri.py as well. Thanks
>
> Jose
>
> On Wed, 2010-09-29 at 07:41 -0700, Igor Oliveira wrote:
>> Hi Jose,
>>
>> I updated the patch(see below), I am using python samples, modifying
>> the tri.py to use it because the regress tests are outdated.
>> Now we have we can get the msb and the lsb values from double operations.
>>
>> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
>> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
>> index 441aeba..70330dc 100644
>> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
>> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
>> @@ -963,6 +963,68 @@ emit_kil(
>> lp_build_mask_update(bld->mask, mask);
>> }
>>
>> +static LLVMValueRef
>> +lp_cast_to_double(struct lp_build_context *bld,
>> + LLVMValueRef a,
>> + LLVMValueRef b)
>> +{
>> + struct lp_type type;
>> + LLVMValueRef res;
>> + LLVMTypeRef vec_type;
>> + LLVMTypeRef vec_double_type;
>> +
>> + type = lp_type_uint_vec(64);
>> + vec_type = lp_build_vec_type(type);
>> +
>> + a = LLVMBuildBitCast(bld->builder, a, vec_type, "");
>> + b = LLVMBuildBitCast(bld->builder, b, vec_type, "");
>> +
>> + res = LLVMBuildShl(bld->builder, a, lp_build_const_int_vec(type, 32),"");
>> + res = LLVMBuildOr(bld->builder, res, b, "");
>> +
>> + a = LLVMBuildBitCast(bld->builder, a, bld->vec_type, "");
>> + b = LLVMBuildBitCast(bld->builder, b, bld->vec_type, "");
>> +
>> + type = lp_type_float_vec(64);
>> + bld->type = type;
>> + vec_double_type = lp_build_vec_type(type);
>> + res = LLVMBuildBitCast(bld->builder, res, vec_double_type, "");
>> +
>> + return res;
>> +}
>> +
>> +static LLVMValueRef
>> +lp_cast_from_double_msb(struct lp_build_context *bld,
>> + LLVMValueRef double_value)
>> +{
>> + LLVMTypeRef double_type;
>> + LLVMValueRef res;
>> + struct lp_type type = lp_type_uint_vec(64);
>> +
>> + double_type = lp_build_vec_type(type);
>> + res = LLVMBuildBitCast(bld->builder, double_value, double_type, "");
>> + res = LLVMBuildLShr(bld->builder, res,
>> lp_build_const_int_vec(type, 32), "");
>> + res = LLVMBuildBitCast(bld->builder, res, bld->vec_type, "");
>> +
>> + return res;
>> +}
>> +
>> +
>> +static LLVMValueRef
>> +lp_cast_from_double_lsb(struct lp_build_context *bld,
>> + LLVMValueRef double_value)
>> +{
>> + LLVMTypeRef double_type;
>> + LLVMValueRef res;
>> + struct lp_type type = lp_type_uint_vec(64);
>> +
>> + double_type = lp_build_vec_type(type);
>> + res = LLVMBuildBitCast(bld->builder, double_value, double_type, "");
>> + res = LLVMBuildAnd(bld->builder, res, lp_build_const_int_vec(type,
>> 0x), "");
>> + res = LLVMBuildBitCast(bld->builder, res, bld->vec_type, "");
>> +
>> + return res;
>> +}
>>
>> /**
>> * Predicated fragment kill.
>> @@ -1982,6 +2044,37 @@ emit_instruction(
>> case TGSI_OPCODE_NOP:
>> b
Re: [Mesa-dev] [PATCH] llvmpipe: add initial support to double opcodes in llvmpipe.
Could you please send me the modified tri.py as well. Thanks
Jose
On Wed, 2010-09-29 at 07:41 -0700, Igor Oliveira wrote:
> Hi Jose,
>
> I updated the patch(see below), I am using python samples, modifying
> the tri.py to use it because the regress tests are outdated.
> Now we have we can get the msb and the lsb values from double operations.
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> index 441aeba..70330dc 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> @@ -963,6 +963,68 @@ emit_kil(
>lp_build_mask_update(bld->mask, mask);
> }
>
> +static LLVMValueRef
> +lp_cast_to_double(struct lp_build_context *bld,
> + LLVMValueRef a,
> + LLVMValueRef b)
> +{
> + struct lp_type type;
> + LLVMValueRef res;
> + LLVMTypeRef vec_type;
> + LLVMTypeRef vec_double_type;
> +
> + type = lp_type_uint_vec(64);
> + vec_type = lp_build_vec_type(type);
> +
> + a = LLVMBuildBitCast(bld->builder, a, vec_type, "");
> + b = LLVMBuildBitCast(bld->builder, b, vec_type, "");
> +
> + res = LLVMBuildShl(bld->builder, a, lp_build_const_int_vec(type, 32),"");
> + res = LLVMBuildOr(bld->builder, res, b, "");
> +
> + a = LLVMBuildBitCast(bld->builder, a, bld->vec_type, "");
> + b = LLVMBuildBitCast(bld->builder, b, bld->vec_type, "");
> +
> + type = lp_type_float_vec(64);
> + bld->type = type;
> + vec_double_type = lp_build_vec_type(type);
> + res = LLVMBuildBitCast(bld->builder, res, vec_double_type, "");
> +
> + return res;
> +}
> +
> +static LLVMValueRef
> +lp_cast_from_double_msb(struct lp_build_context *bld,
> +LLVMValueRef double_value)
> +{
> + LLVMTypeRef double_type;
> + LLVMValueRef res;
> + struct lp_type type = lp_type_uint_vec(64);
> +
> + double_type = lp_build_vec_type(type);
> + res = LLVMBuildBitCast(bld->builder, double_value, double_type, "");
> + res = LLVMBuildLShr(bld->builder, res,
> lp_build_const_int_vec(type, 32), "");
> + res = LLVMBuildBitCast(bld->builder, res, bld->vec_type, "");
> +
> + return res;
> +}
> +
> +
> +static LLVMValueRef
> +lp_cast_from_double_lsb(struct lp_build_context *bld,
> +LLVMValueRef double_value)
> +{
> + LLVMTypeRef double_type;
> + LLVMValueRef res;
> + struct lp_type type = lp_type_uint_vec(64);
> +
> + double_type = lp_build_vec_type(type);
> + res = LLVMBuildBitCast(bld->builder, double_value, double_type, "");
> + res = LLVMBuildAnd(bld->builder, res, lp_build_const_int_vec(type,
> 0x), "");
> + res = LLVMBuildBitCast(bld->builder, res, bld->vec_type, "");
> +
> + return res;
> +}
>
> /**
> * Predicated fragment kill.
> @@ -1982,6 +2044,37 @@ emit_instruction(
> case TGSI_OPCODE_NOP:
>break;
>
> + case TGSI_OPCODE_DMUL:
> + if (IS_DST0_CHANNEL_ENABLED(inst, CHAN_X) &&
> IS_DST0_CHANNEL_ENABLED(inst, CHAN_Y)) {
> + tmp0 = emit_fetch( bld, inst, 0, CHAN_X );
> + tmp1 = emit_fetch( bld, inst, 0, CHAN_Y );
> +
> + tmp2 = emit_fetch( bld, inst, 1, CHAN_X );
> + tmp3 = emit_fetch( bld, inst, 1, CHAN_Y );
> +
> + src0 = lp_cast_to_double(&bld->base, tmp0, tmp1);
> + src1 = lp_cast_to_double(&bld->base, tmp2, tmp3);
> + tmp4 = lp_build_mul(&bld->base, src0, src1);
> + dst0[CHAN_X] = lp_cast_from_double_msb(&bld->base, tmp4);
> + dst0[CHAN_Y] = lp_cast_from_double_lsb(&bld->base, tmp4);
> + }
> +
> + if (IS_DST0_CHANNEL_ENABLED(inst, CHAN_Z) &&
> IS_DST0_CHANNEL_ENABLED(inst, CHAN_W)) {
> + tmp0 = emit_fetch( bld, inst, 0, CHAN_Z );
> + tmp1 = emit_fetch( bld, inst, 0, CHAN_W );
> +
> + tmp2 = emit_fetch( bld, inst, 1, CHAN_Z );
> + tmp3 = emit_fetch( bld, inst, 1, CHAN_W );
> +
> + src0 = lp_cast_to_double(&bld->base, tmp0, tmp1);
> + src1 = lp_cast_to_double(&bld->base, tmp2, tmp3);
> + tmp4 = lp_build_mul(&bld->base, src0, src1);
> + dst0[CHAN_Z] = lp_cast_from_double_msb(&bld->base, tmp4);
> + dst0[CHAN_W] = lp_cast_from_double_lsb(&bld->base, tmp4);
> +
> + }
> + break;
> +
> default:
>return FALSE;
> }
> --
> 1.7.0.4
>
>
>
> On Tue, Sep 28, 2010 at 5:32 PM, Jose Fonseca wrote:
> > Sorry Igor. I dropped the ball on your previous submission.
> >
> > I still don't understand what the code does, nor how the generated code
> > will look like. Granted, your implementation is better than no
> > implementation, but I'd like to go a bit further and get this nailed, and
> > not have to redo this code.
> >
> > Is there a simple test case I can use to exercise and test this?
> >
> > Jose
> >
> >
> > From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org
> > [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On
Re: [Mesa-dev] [PATCH] llvmpipe: add initial support to double opcodes in llvmpipe.
Hi Jose,
I updated the patch(see below), I am using python samples, modifying
the tri.py to use it because the regress tests are outdated.
Now we have we can get the msb and the lsb values from double operations.
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 441aeba..70330dc 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -963,6 +963,68 @@ emit_kil(
lp_build_mask_update(bld->mask, mask);
}
+static LLVMValueRef
+lp_cast_to_double(struct lp_build_context *bld,
+ LLVMValueRef a,
+ LLVMValueRef b)
+{
+ struct lp_type type;
+ LLVMValueRef res;
+ LLVMTypeRef vec_type;
+ LLVMTypeRef vec_double_type;
+
+ type = lp_type_uint_vec(64);
+ vec_type = lp_build_vec_type(type);
+
+ a = LLVMBuildBitCast(bld->builder, a, vec_type, "");
+ b = LLVMBuildBitCast(bld->builder, b, vec_type, "");
+
+ res = LLVMBuildShl(bld->builder, a, lp_build_const_int_vec(type, 32),"");
+ res = LLVMBuildOr(bld->builder, res, b, "");
+
+ a = LLVMBuildBitCast(bld->builder, a, bld->vec_type, "");
+ b = LLVMBuildBitCast(bld->builder, b, bld->vec_type, "");
+
+ type = lp_type_float_vec(64);
+ bld->type = type;
+ vec_double_type = lp_build_vec_type(type);
+ res = LLVMBuildBitCast(bld->builder, res, vec_double_type, "");
+
+ return res;
+}
+
+static LLVMValueRef
+lp_cast_from_double_msb(struct lp_build_context *bld,
+LLVMValueRef double_value)
+{
+ LLVMTypeRef double_type;
+ LLVMValueRef res;
+ struct lp_type type = lp_type_uint_vec(64);
+
+ double_type = lp_build_vec_type(type);
+ res = LLVMBuildBitCast(bld->builder, double_value, double_type, "");
+ res = LLVMBuildLShr(bld->builder, res,
lp_build_const_int_vec(type, 32), "");
+ res = LLVMBuildBitCast(bld->builder, res, bld->vec_type, "");
+
+ return res;
+}
+
+
+static LLVMValueRef
+lp_cast_from_double_lsb(struct lp_build_context *bld,
+LLVMValueRef double_value)
+{
+ LLVMTypeRef double_type;
+ LLVMValueRef res;
+ struct lp_type type = lp_type_uint_vec(64);
+
+ double_type = lp_build_vec_type(type);
+ res = LLVMBuildBitCast(bld->builder, double_value, double_type, "");
+ res = LLVMBuildAnd(bld->builder, res, lp_build_const_int_vec(type,
0x), "");
+ res = LLVMBuildBitCast(bld->builder, res, bld->vec_type, "");
+
+ return res;
+}
/**
* Predicated fragment kill.
@@ -1982,6 +2044,37 @@ emit_instruction(
case TGSI_OPCODE_NOP:
break;
+ case TGSI_OPCODE_DMUL:
+ if (IS_DST0_CHANNEL_ENABLED(inst, CHAN_X) &&
IS_DST0_CHANNEL_ENABLED(inst, CHAN_Y)) {
+ tmp0 = emit_fetch( bld, inst, 0, CHAN_X );
+ tmp1 = emit_fetch( bld, inst, 0, CHAN_Y );
+
+ tmp2 = emit_fetch( bld, inst, 1, CHAN_X );
+ tmp3 = emit_fetch( bld, inst, 1, CHAN_Y );
+
+ src0 = lp_cast_to_double(&bld->base, tmp0, tmp1);
+ src1 = lp_cast_to_double(&bld->base, tmp2, tmp3);
+ tmp4 = lp_build_mul(&bld->base, src0, src1);
+ dst0[CHAN_X] = lp_cast_from_double_msb(&bld->base, tmp4);
+ dst0[CHAN_Y] = lp_cast_from_double_lsb(&bld->base, tmp4);
+ }
+
+ if (IS_DST0_CHANNEL_ENABLED(inst, CHAN_Z) &&
IS_DST0_CHANNEL_ENABLED(inst, CHAN_W)) {
+ tmp0 = emit_fetch( bld, inst, 0, CHAN_Z );
+ tmp1 = emit_fetch( bld, inst, 0, CHAN_W );
+
+ tmp2 = emit_fetch( bld, inst, 1, CHAN_Z );
+ tmp3 = emit_fetch( bld, inst, 1, CHAN_W );
+
+ src0 = lp_cast_to_double(&bld->base, tmp0, tmp1);
+ src1 = lp_cast_to_double(&bld->base, tmp2, tmp3);
+ tmp4 = lp_build_mul(&bld->base, src0, src1);
+ dst0[CHAN_Z] = lp_cast_from_double_msb(&bld->base, tmp4);
+ dst0[CHAN_W] = lp_cast_from_double_lsb(&bld->base, tmp4);
+
+ }
+ break;
+
default:
return FALSE;
}
--
1.7.0.4
On Tue, Sep 28, 2010 at 5:32 PM, Jose Fonseca wrote:
> Sorry Igor. I dropped the ball on your previous submission.
>
> I still don't understand what the code does, nor how the generated code will
> look like. Granted, your implementation is better than no implementation, but
> I'd like to go a bit further and get this nailed, and not have to redo this
> code.
>
> Is there a simple test case I can use to exercise and test this?
>
> Jose
>
>
> From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org
> [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of
> Igor Oliveira [igor.olive...@openbossa.org]
> Sent: Tuesday, September 28, 2010 20:34
> To: mesa-dev@lists.freedesktop.org
> Subject: [Mesa-dev] [PATCH] llvmpipe: add initial support to double opcodes
> in llvmpipe.
>
> - create helper function
> - implement DMUL opcode
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 78
> +++
> 1 files changed, 78 inse
Re: [Mesa-dev] r600g old design -> new design
2010/9/29 Michel Dänzer : > On Mit, 2010-09-29 at 11:49 +0100, Keith Whitwell wrote: >> On Wed, 2010-09-29 at 03:35 -0700, Michel Dänzer wrote: >> > On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote: >> > > >> > > - use score for placing bo, bo placement will be recorded in bo >> > > structure and >> > > each time a state is bind bo score will be updated (bo bound as >> > > framebuffer >> > > will get their score for placing into vram increase while bo bound as >> > > small >> > > vertex buffer will endup in GTT, also anytime a bo is mapped for >> > > transfer for >> > > CPU read its score for GTT placement increase thus bo that are often >> > > updated >> > > by CPU will more likely place into GTT) >> > >> > Beware that the EXA 'classic' scheme originally (with the 'greedy' and >> > 'smart' heuristics) used a score like that to determine whether a pixmap >> > should reside in VRAM or system memory, and it could result in quite >> > erratic / inconsistent / unreproducible behaviour when the score hovered >> > around the threshold. It could make fixing or even reproducing problems >> > harder than it is already. >> >> Did trying some sort of hysteresis - eg. having different thresholds for >> upload vs. download help? > > There actually already is a hysteresis — I forgot about that, thanks for > reminding me. I never tried playing with the threshold values, don't > know if anyone did. > > Yeah i do remember the issue with the ddx, i hope to be able to come up with somethings that won't change its mind every cs (ie once a bo is assigned to GTT or VRAM it will stay there for a bit before being re-evaluated to move to other domain). Anyway if it's catastrophic it will be self contained enough that it should be easy to test other way to be smart about bo placement (if we could ever be smart about it :)) Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30457] [7.9] DRI drawables prematurely destroyed on context switch
https://bugs.freedesktop.org/show_bug.cgi?id=30457 Kristian Høgsberg changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Kristian Høgsberg 2010-09-29 06:12:56 PDT --- 4b70fe8421f5132c585ff1dfb8d90229be26e71f should fix the clutter issue, but the piglit test you sent tests something different. If you look at the actual X errors, the clutter problem comes from glXMakeCurrent getting a BadDrawable, the test case fails in glXSwapBuffers. To test the clutter problem you'll have to create two GLXDrawables (A and B) and then make a context current with A, then B, then switch back to A. If you have time to write up a test case for this, that would be much appreciated. The swapbuffer problem is still present, and I've committed the test case to piglit, but it's a much rarer case to hit. Few applications do glXSwapBuffer for a drawable that's not also current, but it has to work, of course. The clutter problem is fixed (reproduced using test-multistage) and cherry-picked back to 7.9 (b24238c49abf9b6c56ffbf45a3c203c7ddd2) so I'll close this bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30457] [7.9] DRI drawables prematurely destroyed on context switch
https://bugs.freedesktop.org/show_bug.cgi?id=30457 Robert Hooker (Sarvatt) changed: What|Removed |Added CC||sarv...@gmail.com -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30457] New: [7.9] DRI drawables prematurely destroyed on context switch
https://bugs.freedesktop.org/show_bug.cgi?id=30457 Summary: [7.9] DRI drawables prematurely destroyed on context switch Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: chalserog...@gmail.com Created an attachment (id=39044) View: https://bugs.freedesktop.org/attachment.cgi?id=39044 Review: https://bugs.freedesktop.org/review?bug=30457&attachment=39044 Simpleminded patch which fixes Clutter apps. It seems that with the new GLX drawable garbage collection that mesa incorrectly destroys drawables when switching a single context between drawables. This manifests in some clutter applications crashing with a BadDrawable error: (quadrapassel:4883): ClutterGLX-CRITICAL **: Unable to make the stage window 0x485 the current GLX drawable (quadrapassel:4883): ClutterGLX-CRITICAL **: Unable to make the stage window 0x486 the current GLX drawable (quadrapassel:4883): ClutterGLX-CRITICAL **: Unable to make the stage window 0x486 the current GLX drawable The program 'quadrapassel' received an X Window System error. This probably reflects a bug in the program. The error was 'BadDrawable (invalid Pixmap or Window parameter)'. (Details: serial 70 error_code 9 request_code 137 minor_code 12) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) The cause is that when dri2_unbind_context is called with new context == old context it calls driReleaseDrawable. Clutter will switch a single context between different drawables with glXMakeCurrent, so it hits this codepath. When it switches back to the original drawable, mesa only has the GLXDrawable id which doesn't match the X drawable ID, and hence calls using it result in BadDrawable in clutter. I've sent a piglit testcase to the piglit list exhibiting this bug. The attached patch fixes this, but probably leaks drawables. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.9-rc2
> > Am 29.09.2010 04:47, schrieb Ian Romanick: > > Mesa 7.9-rc2 has been released. Assuming there are no issues, > Mesa 7.9 > > final will be released next Monday (October 4th). > > > > I've tried it again with > > export LC_ALL=C > export PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig/ > ./configure \ >--enable-gallium-radeon \ >--enable-gallium-swrast \ >--prefix=/opt/mesa > make > > > And now it stops with > > make[3]: Entering directory > `/home/sebastian/source/Mesa-7.9-rc2/src/gallium/targets/xorg-radeon' > Makefile:24: ../Makefile.xorg: No such file or directory > make[3]: *** No rule to make target `../Makefile.xorg'. Stop. > make[3]: Leaving directory > `/home/sebastian/source/Mesa-7.9-rc2/src/gallium/targets/xorg-radeon' > > > No idea if this is a configuration problem my side though. > > > I don't have that file either and I have no problem. Try to re-run > autogen.sh. > > > Oh I see, Makefile.xorg is not in the tarball. I'll make a fix. But you > don't have to use --enable-gallium-radeon to build gallium/r300_dri.so. Great, without --enable-gallium-radeon it compiles and installs fine. Nexuiz also seems to run nicely (with the non gallium radeon driver though) Thanks, Sebastian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g old design -> new design
On Mit, 2010-09-29 at 11:49 +0100, Keith Whitwell wrote: > On Wed, 2010-09-29 at 03:35 -0700, Michel Dänzer wrote: > > On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote: > > > > > > - use score for placing bo, bo placement will be recorded in bo structure > > > and > > > each time a state is bind bo score will be updated (bo bound as > > > framebuffer > > > will get their score for placing into vram increase while bo bound as > > > small > > > vertex buffer will endup in GTT, also anytime a bo is mapped for transfer > > > for > > > CPU read its score for GTT placement increase thus bo that are often > > > updated > > > by CPU will more likely place into GTT) > > > > Beware that the EXA 'classic' scheme originally (with the 'greedy' and > > 'smart' heuristics) used a score like that to determine whether a pixmap > > should reside in VRAM or system memory, and it could result in quite > > erratic / inconsistent / unreproducible behaviour when the score hovered > > around the threshold. It could make fixing or even reproducing problems > > harder than it is already. > > Did trying some sort of hysteresis - eg. having different thresholds for > upload vs. download help? There actually already is a hysteresis — I forgot about that, thanks for reminding me. I never tried playing with the threshold values, don't know if anyone did. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Makefile: ensure Gallium's Makefile.xorg and SConscript.dri are in the tarball
--- Makefile |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index eb90650..42f1c0a 100644 --- a/Makefile +++ b/Makefile @@ -329,6 +329,8 @@ GALLIUM_FILES = \ $(DIRECTORY)/src/gallium/Makefile.template \ $(DIRECTORY)/src/gallium/SConscript \ $(DIRECTORY)/src/gallium/targets/Makefile.dri \ + $(DIRECTORY)/src/gallium/targets/Makefile.xorg \ + $(DIRECTORY)/src/gallium/targets/SConscript.dri \ $(DIRECTORY)/src/gallium/*/Makefile \ $(DIRECTORY)/src/gallium/*/SConscript \ $(DIRECTORY)/src/gallium/*/*/Makefile \ -- 1.7.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.9-rc2
Am 29.09.2010 12:22, schrieb Marek Olšák: > export LC_ALL=C > export PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig/ > ./configure \ >--enable-gallium-radeon \ >--enable-gallium-swrast \ >--prefix=/opt/mesa > make > > make[3]: Entering directory > `/home/sebastian/source/Mesa-7.9-rc2/src/gallium/targets/xorg-radeon' > Makefile:24: ../Makefile.xorg: No such file or directory > make[3]: *** No rule to make target `../Makefile.xorg'. Stop. > make[3]: Leaving directory > `/home/sebastian/source/Mesa-7.9-rc2/src/gallium/targets/xorg-radeon' > > I don't have that file either and I have no problem. Try to re-run > autogen.sh. At least in the tarball there's no autogen.sh. Sebastian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.9-rc2
On Wed, Sep 29, 2010 at 12:22 PM, Marek Olšák wrote: > On Wed, Sep 29, 2010 at 11:43 AM, Sebastian H. wrote: > >> Am 29.09.2010 04:47, schrieb Ian Romanick: >> > Mesa 7.9-rc2 has been released. Assuming there are no issues, Mesa 7.9 >> > final will be released next Monday (October 4th). >> > >> >> I've tried it again with >> >> export LC_ALL=C >> export PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig/ >> ./configure \ >>--enable-gallium-radeon \ >>--enable-gallium-swrast \ >>--prefix=/opt/mesa >> make >> >> >> And now it stops with >> >> make[3]: Entering directory >> `/home/sebastian/source/Mesa-7.9-rc2/src/gallium/targets/xorg-radeon' >> Makefile:24: ../Makefile.xorg: No such file or directory >> make[3]: *** No rule to make target `../Makefile.xorg'. Stop. >> make[3]: Leaving directory >> `/home/sebastian/source/Mesa-7.9-rc2/src/gallium/targets/xorg-radeon' >> >> >> No idea if this is a configuration problem my side though. >> > > I don't have that file either and I have no problem. Try to re-run > autogen.sh. > Oh I see, Makefile.xorg is not in the tarball. I'll make a fix. But you don't have to use --enable-gallium-radeon to build gallium/r300_dri.so. Cheers. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g old design -> new design
On Wed, 2010-09-29 at 03:35 -0700, Michel Dänzer wrote: > On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote: > > > > - use score for placing bo, bo placement will be recorded in bo structure > > and > > each time a state is bind bo score will be updated (bo bound as framebuffer > > will get their score for placing into vram increase while bo bound as small > > vertex buffer will endup in GTT, also anytime a bo is mapped for transfer > > for > > CPU read its score for GTT placement increase thus bo that are often updated > > by CPU will more likely place into GTT) > > Beware that the EXA 'classic' scheme originally (with the 'greedy' and > 'smart' heuristics) used a score like that to determine whether a pixmap > should reside in VRAM or system memory, and it could result in quite > erratic / inconsistent / unreproducible behaviour when the score hovered > around the threshold. It could make fixing or even reproducing problems > harder than it is already. Did trying some sort of hysteresis - eg. having different thresholds for upload vs. download help? Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g old design -> new design
On Die, 2010-09-28 at 11:40 -0400, Jerome Glisse wrote: > > - use score for placing bo, bo placement will be recorded in bo structure and > each time a state is bind bo score will be updated (bo bound as framebuffer > will get their score for placing into vram increase while bo bound as small > vertex buffer will endup in GTT, also anytime a bo is mapped for transfer for > CPU read its score for GTT placement increase thus bo that are often updated > by CPU will more likely place into GTT) Beware that the EXA 'classic' scheme originally (with the 'greedy' and 'smart' heuristics) used a score like that to determine whether a pixmap should reside in VRAM or system memory, and it could result in quite erratic / inconsistent / unreproducible behaviour when the score hovered around the threshold. It could make fixing or even reproducing problems harder than it is already. > In case of dual API use (ie if cs ioctl is also use) kernel will assume GPU > has loose context and will reprogram, reflush everythings. This might be an opportunity for getting st/xorg working well with r600g, so the corresponding changes to xf86-video-ati could at least be delayed until the new scheme has matured in the Gallium tree. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.9-rc2
On Wed, Sep 29, 2010 at 11:43 AM, Sebastian H. wrote: > Am 29.09.2010 04:47, schrieb Ian Romanick: > > Mesa 7.9-rc2 has been released. Assuming there are no issues, Mesa 7.9 > > final will be released next Monday (October 4th). > > > > I've tried it again with > > export LC_ALL=C > export PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig/ > ./configure \ >--enable-gallium-radeon \ >--enable-gallium-swrast \ >--prefix=/opt/mesa > make > > > And now it stops with > > make[3]: Entering directory > `/home/sebastian/source/Mesa-7.9-rc2/src/gallium/targets/xorg-radeon' > Makefile:24: ../Makefile.xorg: No such file or directory > make[3]: *** No rule to make target `../Makefile.xorg'. Stop. > make[3]: Leaving directory > `/home/sebastian/source/Mesa-7.9-rc2/src/gallium/targets/xorg-radeon' > > > No idea if this is a configuration problem my side though. > I don't have that file either and I have no problem. Try to re-run autogen.sh. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.9-rc2
Am 29.09.2010 04:47, schrieb Ian Romanick: > Mesa 7.9-rc2 has been released. Assuming there are no issues, Mesa 7.9 > final will be released next Monday (October 4th). > I've tried it again with export LC_ALL=C export PKG_CONFIG_PATH=/opt/mesa/lib/pkgconfig/ ./configure \ --enable-gallium-radeon \ --enable-gallium-swrast \ --prefix=/opt/mesa make And now it stops with make[3]: Entering directory `/home/sebastian/source/Mesa-7.9-rc2/src/gallium/targets/xorg-radeon' Makefile:24: ../Makefile.xorg: No such file or directory make[3]: *** No rule to make target `../Makefile.xorg'. Stop. make[3]: Leaving directory `/home/sebastian/source/Mesa-7.9-rc2/src/gallium/targets/xorg-radeon' No idea if this is a configuration problem my side though. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
