No more Bug mails on the list?
I was wondering what happened to the bug-mails assigned to this list, there haven't been any for the last two weeks. Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300][PATCH] Add/fix COS & SIN + FP fixes
Roland Scheidegger wrote:
> Roland Scheidegger wrote:
>> Rune Petersen wrote:
>> Also, the comments for SCS seem a bit off. That's a pity, because
>> without comments I can't really see what the code does at first sight
>> :-). Looks like quite a few extra instructions though, are you sure
>> not more could be shared for calculating both sin and cos?
> I've looked a bit closer (this is an interesting optimization
> problem...) and I think it should be doable with fewer instructions,
> though ultimately I needed 2 temps instead of 1 (I don't think it's much
> of a problem, 32 is plenty, PS2.0 only exposes 12).
>
> Ok the equation was:
> Q (4/pi x - 4/pi^2 x^2) + P (4/pi x - 4/pi^2 x^2)^2
>
> Simplified to:
> y = B * x + C * x * abs(x)
> y = P * (y * abs(y) - y) + y
>
> const0: B,C,pi,P
> const1: 0.5pi, 0.75, 1/(2pi), 2.0pi
>
> That's what I came up with with pseudo-code:
> //should be 5 slots (I guess it might generate 6 due to force same-slot,
> //but that needs fixing elewhere)
>
> //cos is even: cos(x) = cos(-x). So using simple trigo-fu
> //we get sin(neg(abs(x)) + pi/2)) = cos(x), no comparison needed and all
> //values for sine stay inside [-pi,pi] ([-pi/2, pi/2], actually)
> //hope it's ok to use neg+abs simultaneously?
> temp.z = add(neg(abs(src)), const1.x)
> temp.w = mul(src, C)
>
> //temp.xy = B*x, C*x (cos), temp.w = C * x, temp2.w = B * x (sin)
> temp.xy = mul(temp.z, BC)
> temp2.w = mul(src, B)
>
> //do cos in alpha slot not sin due to restricted swizzling
> //sin y = B * x + C * x * abs(x)
> temp2.z = mad(temp.w, abs(src), temp2.w)
> //cos
> temp2.w = mad(temp.y, abs(temp.z), temp.x)
>
> temp.xy = mad(temp2.wzy, abs(temp2.wzy), neg(temp2.wzy))
> // now temp.x holds y * abs(y) - y for cos, temp.y same for sin
>
> dest.xy = mad(temp.xy, P, temp2.wzy)
>
> range reduction for cos:
> x = (x/(2*PI))+0.75
> x = frac(x)
> x = (x*2*PI)-PI
>
> sin:
> x = (x/(2*PI))+HALF
> x = frac(x)
> x = (x*2*PI)-PI
>
> Isn't that an elegant solution :-) There may be any number of bugs, of
> course...
>
I have attached a patch that implements your solution. looks fine, and
it uses 6 slots until I teach emit_arith() how to pack instructions.
Rune Petersen
diff --git a/src/mesa/drivers/dri/r300/r300_fragprog.c b/src/mesa/drivers/dri/r300/r300_fragprog.c
index 8e45bd5..a1c634a 100644
--- a/src/mesa/drivers/dri/r300/r300_fragprog.c
+++ b/src/mesa/drivers/dri/r300/r300_fragprog.c
@@ -1214,8 +1214,8 @@ static void make_sin_const(struct r300_fragment_program *rp)
cnstv[3] = 0.2225; // weight
rp->const_sin[0] = emit_const4fv(rp, cnstv);
- cnstv[0] = 0.5;
- cnstv[1] = -1.5;
+ cnstv[0] = 0.75;
+ cnstv[1] = 0.0;
cnstv[2] = 0.159154943; // 1/(2*PI)
cnstv[3] = 6.283185307; // 2*PI
rp->const_sin[1] = emit_const4fv(rp, cnstv);
@@ -1227,7 +1227,7 @@ static GLboolean parse_program(struct r300_fragment_program *rp)
struct gl_fragment_program *mp = &rp->mesa_program;
const struct prog_instruction *inst = mp->Base.Instructions;
struct prog_instruction *fpi;
- GLuint src[3], dest, temp;
+ GLuint src[3], dest, temp[2];
GLuint cnst;
int flags, mask = 0;
GLfloat cnstv[4] = {0.0, 0.0, 0.0, 0.0};
@@ -1277,70 +1277,63 @@ static GLboolean parse_program(struct r300_fragment_program *rp)
/*
* cos using a parabola (see SIN):
* cos(x):
- * x += PI/2
- * x = (x/(2*PI))+0.5
+ * x = (x/(2*PI))+0.75
* x = frac(x)
* x = (x*2*PI)-PI
* result = sin(x)
*/
- temp = get_temp_reg(rp);
+ temp[0] = get_temp_reg(rp);
make_sin_const(rp);
src[0] = t_scalar_src(rp, fpi->SrcReg[0]);
/* add 0.5*PI and do range reduction */
- emit_arith(rp, PFS_OP_MAD, temp, WRITEMASK_X,
- swizzle(rp->const_sin[0], Z, Z, Z, Z), //PI
- pfs_half,
- swizzle(keep(src[0]), X, X, X, X),
- 0);
-
- emit_arith(rp, PFS_OP_MAD, temp, WRITEMASK_X,
- swizzle(temp, X, X, X, X),
+ emit_arith(rp, PFS_OP_MAD, temp[0], WRITEMASK_X,
+ swizzle(src[0], X, X, X, X),
swizzle(rp->const_sin[1], Z, Z, Z, Z),
- pfs_half,
+ swizzle(rp->const_sin[1], X, X, X, X),
0);
- emit_arith(rp, PFS_OP_FRC, temp, WRITEMASK_X,
- swizzle(temp, X, X, X, X),
+ emit_arith(rp, PFS_OP_FRC, temp[0], WRITEMASK_X,
+ swizzle(temp[0], X, X, X, X),
undef,
undef,
0);
- emit_arith(rp, PFS_OP_MAD, temp, WRITEMASK_Z,
- swizzle(temp, X, X, X, X),
+ emit_arith(rp, PFS_OP_MAD, temp[0], WRITEMASK_Z,
+ swizzle(temp[0], X, X, X, X),
swizzle(rp->const_sin[1], W, W, W, W), //2*PI
negate(swizzle(rp->const_sin[0], Z, Z, Z, Z)), //-PI
0);
/* SIN */
- emit_arith(rp, PFS
Re: [R300][PATCH] Add/fix COS & SIN + FP fixes
Roland Scheidegger wrote: > Roland Scheidegger wrote: >> Rune Petersen wrote: >>> This patch: - Fixes COS. - Does range reductions for SIN & COS. - >>> Adds SCS. - removes the optimized version of SIN & COS. - tweaked >>> weight (should help on precision). - fixed a copy paste typo in >>> emit_arith(). >>> >>> Roland would you mind testing if the tweaked weight helped? >> Well I didn't test it first time (just quoting the numbers from the >> link you provided), but I guess that's fine too. I was actually >> wondering myself if it's better to optimize for absolute or relative >> error, so choosing a weight in-between should work too (the >> difference is not that big after all). >> >> A couple comments though: Since ((x + PI/2)/(2*PI))+0.5 is (x/(2*PI) >> + (1/4 + 0.5) you could optimize away the first mad for the COS case. >> > Ah I see you're a bit short on consts, if you want to only use 2 (btw > I'd say there should be 32 not only 16 but I have no idea why the driver > restricts it to 16). > >> Also, the comments for SCS seem a bit off. That's a pity, because >> without comments I can't really see what the code does at first sight >> :-). Looks like quite a few extra instructions though, are you sure >> not more could be shared for calculating both sin and cos? > I've looked a bit closer (this is an interesting optimization > problem...) and I think it should be doable with fewer instructions, > though ultimately I needed 2 temps instead of 1 (I don't think it's much > of a problem, 32 is plenty, PS2.0 only exposes 12). > > Ok the equation was: > Q (4/pi x - 4/pi^2 x^2) + P (4/pi x - 4/pi^2 x^2)^2 > > Simplified to: > y = B * x + C * x * abs(x) > y = P * (y * abs(y) - y) + y > > const0: B,C,pi,P > const1: 0.5pi, 0.75, 1/(2pi), 2.0pi > > That's what I came up with with pseudo-code: > //should be 5 slots (I guess it might generate 6 due to force same-slot, > //but that needs fixing elewhere) > > //cos is even: cos(x) = cos(-x). So using simple trigo-fu > //we get sin(neg(abs(x)) + pi/2)) = cos(x), no comparison needed and all > //values for sine stay inside [-pi,pi] ([-pi/2, pi/2], actually) > //hope it's ok to use neg+abs simultaneously? > temp.z = add(neg(abs(src)), const1.x) > temp.w = mul(src, C) > > //temp.xy = B*x, C*x (cos), temp.w = C * x, temp2.w = B * x (sin) > temp.xy = mul(temp.z, BC) > temp2.w = mul(src, B) > > //do cos in alpha slot not sin due to restricted swizzling > //sin y = B * x + C * x * abs(x) > temp2.z = mad(temp.w, abs(src), temp2.w) > //cos > temp2.w = mad(temp.y, abs(temp.z), temp.x) > > temp.xy = mad(temp2.wzy, abs(temp2.wzy), neg(temp2.wzy)) > // now temp.x holds y * abs(y) - y for cos, temp.y same for sin > > dest.xy = mad(temp.xy, P, temp2.wzy) > > range reduction for cos: > x = (x/(2*PI))+0.75 > x = frac(x) > x = (x*2*PI)-PI > > sin: > x = (x/(2*PI))+HALF > x = frac(x) > x = (x*2*PI)-PI > > Isn't that an elegant solution :-) There may be any number of bugs, of > course... Very elegant I must say. Thank you I'll see about implementing this. Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300][PATCH] Add/fix COS & SIN + FP fixes
Roland Scheidegger wrote: > Rune Petersen wrote: >> This patch: - Fixes COS. - Does range reductions for SIN & COS. - >> Adds SCS. - removes the optimized version of SIN & COS. - tweaked >> weight (should help on precision). - fixed a copy paste typo in >> emit_arith(). >> >> Roland would you mind testing if the tweaked weight helped? > Well I didn't test it first time (just quoting the numbers from the link > you provided), but I guess that's fine too. I was actually wondering > myself if it's better to optimize for absolute or relative error, so > choosing a weight in-between should work too (the difference is not that > big after all). > > A couple comments though: > Since ((x + PI/2)/(2*PI))+0.5 is (x/(2*PI) + (1/4 + 0.5) > you could optimize away the first mad for the COS case. I knew you were going to catch that. I ran out of scalers in the 2 consts I use. Decided to trade one instruction for one const. If you think its better to sacrifice a const, I wont mind changing it. > > Also, the comments for SCS seem a bit off. That's a pity, because > without comments I can't really see what the code does at first sight > :-). Looks like quite a few extra instructions though, are you sure not > more could be shared for calculating both sin and cos? sorry about the comment. I see SCS as a work in progress. I felt I was fighting how emit_arith() syncs the vector & scalar instructions. I intend to improve amit_arith() before taking a shot at improving SCS any further. I was thinking of storing when each scalar in a temp was written to and use it to pack th instruction tighter. > Otherwise, looks good to me. Keep up the good work! Thank you for you comments. Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300][PATCH] Add/fix COS & SIN + FP fixes
Jerome Glisse wrote: > On 2/14/07, Rune Petersen <[EMAIL PROTECTED]> wrote: >> Roland Scheidegger wrote: >>> Roland Scheidegger wrote: >>>>>> Rune Petersen >>>>>> >>>>> Ok commited. >>>> I didn't look too closely at this but I've a couple of comments. >>>> - COS looks too complicated & broken. If you'd want to get 2 with a >>>> LOG2, you'd need 0.25 as source. But even using RCP instead, that's 5 >>>> instructions before performing the sine, for something you can easily do >>>> in two, using another constant (just 1 add + 1 cmp needed, if you use >>>> the right constants for the add). Maybe it's not that bad though, I >>>> don't know how many rgb and a slots it will actually consume, but still, >>>> are constant slots that rare? >>>> Second, you'd really need to do range reduction of the input, otherwise >>>> results will be very wrong for inputs outside [-pi, pi]. This would be >>>> true for taylor approximation too, of course, unless you do an infinite >>>> series :-). You wouldn't need to do that for SCS. >>> Oh, and forgot to mention, you probably really want to use the higher >>> precision variant by default. 12% max relative error (and even absolute >>> it's still 6%) will likely be visible in some cases depending what the >>> shader is doing. Even the enhanced version seems to miss opengl >>> conformance (accurate to "about 1 part in 10^5") by roughly a factor of >>> 10, which stretches the meaning of "about" a bit probably already. >>> You could also rely on the precision hint for fragment programs to >>> switch to the faster version instead of a dri conf option (note though >>> the spec explicitly states implementations are discouraged even in this >>> case to perform optimizations which could have significant impact on the >>> output). >>> >> This patch: >> - Fixes COS. >> - Does range reductions for SIN & COS. >> - Adds SCS. >> - removes the optimized version of SIN & COS. >> - tweaked weight (should help on precision). >> - fixed a copy paste typo in emit_arith(). >> >> Roland would you mind testing if the tweaked weight helped? >> >> And Jerome would you mind committing this? >> >> >> Rune Petersen >> > > Pushed, git isn't so frightening trust me :) > I'll make you a promise: after March 1. I'll commit my own patches.. until than I can't really get a handle on it (too much on my mind). Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300][PATCH] Add/fix COS & SIN + FP fixes
Roland Scheidegger wrote:
> Roland Scheidegger wrote:
>>>> Rune Petersen
>>>>
>>> Ok commited.
>> I didn't look too closely at this but I've a couple of comments.
>> - COS looks too complicated & broken. If you'd want to get 2 with a
>> LOG2, you'd need 0.25 as source. But even using RCP instead, that's 5
>> instructions before performing the sine, for something you can easily do
>> in two, using another constant (just 1 add + 1 cmp needed, if you use
>> the right constants for the add). Maybe it's not that bad though, I
>> don't know how many rgb and a slots it will actually consume, but still,
>> are constant slots that rare?
>> Second, you'd really need to do range reduction of the input, otherwise
>> results will be very wrong for inputs outside [-pi, pi]. This would be
>> true for taylor approximation too, of course, unless you do an infinite
>> series :-). You wouldn't need to do that for SCS.
>
> Oh, and forgot to mention, you probably really want to use the higher
> precision variant by default. 12% max relative error (and even absolute
> it's still 6%) will likely be visible in some cases depending what the
> shader is doing. Even the enhanced version seems to miss opengl
> conformance (accurate to "about 1 part in 10^5") by roughly a factor of
> 10, which stretches the meaning of "about" a bit probably already.
> You could also rely on the precision hint for fragment programs to
> switch to the faster version instead of a dri conf option (note though
> the spec explicitly states implementations are discouraged even in this
> case to perform optimizations which could have significant impact on the
> output).
>
This patch:
- Fixes COS.
- Does range reductions for SIN & COS.
- Adds SCS.
- removes the optimized version of SIN & COS.
- tweaked weight (should help on precision).
- fixed a copy paste typo in emit_arith().
Roland would you mind testing if the tweaked weight helped?
And Jerome would you mind committing this?
Rune Petersen
diff --git a/src/mesa/drivers/dri/r300/r300_context.h b/src/mesa/drivers/dri/r300/r300_context.h
index b140235..48b50bc 100644
--- a/src/mesa/drivers/dri/r300/r300_context.h
+++ b/src/mesa/drivers/dri/r300/r300_context.h
@@ -731,7 +731,7 @@ struct r300_fragment_program {
int max_temp_idx;
/* the index of the sin constant is stored here */
- GLint const_sin;
+ GLint const_sin[2];
GLuint optimization;
};
diff --git a/src/mesa/drivers/dri/r300/r300_fragprog.c b/src/mesa/drivers/dri/r300/r300_fragprog.c
index b00cf9e..8e45bd5 100644
--- a/src/mesa/drivers/dri/r300/r300_fragprog.c
+++ b/src/mesa/drivers/dri/r300/r300_fragprog.c
@@ -33,7 +33,6 @@
/*TODO'S
*
- * - SCS instructions
* - Depth write, WPOS/FOGC inputs
* - FogOption
* - Verify results of opcodes for accuracy, I've only checked them
@@ -1081,7 +1080,7 @@ static void emit_arith(struct r300_fragment_program *rp,
break;
}
if (emit_sop &&
- (s_swiz[REG_GET_VSWZ(src[i])].flags & SLOT_VECTOR)) {
+ (s_swiz[REG_GET_SSWZ(src[i])].flags & SLOT_VECTOR)) {
vpos = spos = MAX2(vpos, spos);
break;
}
@@ -1204,6 +1203,25 @@ static GLuint get_attrib(struct r300_fragment_program *rp, GLuint attr)
}
#endif
+static void make_sin_const(struct r300_fragment_program *rp)
+{
+ if(rp->const_sin[0] == -1){
+ GLfloat cnstv[4];
+
+ cnstv[0] = 1.273239545; // 4/PI
+ cnstv[1] =-0.405284735; // -4/(PI*PI)
+ cnstv[2] = 3.141592654; // PI
+ cnstv[3] = 0.2225; // weight
+ rp->const_sin[0] = emit_const4fv(rp, cnstv);
+
+ cnstv[0] = 0.5;
+ cnstv[1] = -1.5;
+ cnstv[2] = 0.159154943; // 1/(2*PI)
+ cnstv[3] = 6.283185307; // 2*PI
+ rp->const_sin[1] = emit_const4fv(rp, cnstv);
+ }
+}
+
static GLboolean parse_program(struct r300_fragment_program *rp)
{
struct gl_fragment_program *mp = &rp->mesa_program;
@@ -1260,84 +1278,68 @@ static GLboolean parse_program(struct r300_fragment_program *rp)
* cos using a parabola (see SIN):
* cos(x):
* x += PI/2
- * x = (x < PI)?x : x-2*PI
+ * x = (x/(2*PI))+0.5
+ * x = frac(x)
+ * x = (x*2*PI)-PI
* result = sin(x)
*/
temp = get_temp_reg(rp);
- if(rp->const_sin == -1){
- cnstv[0] = 1.273239545;
- cnstv[1] =-0.405284735;
- cnstv[2] = 3.141592654;
- cnstv[3] = 0.225;
- rp->const_sin = emit_const4fv(rp, cnstv);
- }
- cnst = rp->const_sin;
+ make_sin_const(rp);
src[0] = t_scalar_src(rp, fpi->SrcReg[0]);
- emit_arith(rp, PFS_OP_LG2, temp, WRITEMASK_W,
- pfs_half,
- undef,
- undef,
- 0);
+ /* add 0.5*PI and do range reduction */
emit_arith(rp, PFS_OP_MAD, temp, WRITEMASK_X,
- swi
Re: [R300][PATCH] Add/fix COS & SIN + FP fixes
Roland Scheidegger wrote: > Roland Scheidegger wrote: >>>> Rune Petersen >>>> >>> Ok commited. >> I didn't look too closely at this but I've a couple of comments. >> - COS looks too complicated & broken. If you'd want to get 2 with a >> LOG2, you'd need 0.25 as source. But even using RCP instead, that's 5 >> instructions before performing the sine, for something you can easily do >> in two, using another constant (just 1 add + 1 cmp needed, if you use >> the right constants for the add). Maybe it's not that bad though, I >> don't know how many rgb and a slots it will actually consume, but still, >> are constant slots that rare? >> Second, you'd really need to do range reduction of the input, otherwise >> results will be very wrong for inputs outside [-pi, pi]. This would be >> true for taylor approximation too, of course, unless you do an infinite >> series :-). You wouldn't need to do that for SCS. The mess of trying to get 2 from RCP was a brain fart on my part. And since I forgot the range reduction, I'll add PI*0.5 and then do the range reduction. And this time I will need a constant more (r300 has 16). > > Oh, and forgot to mention, you probably really want to use the higher > precision variant by default. 12% max relative error (and even absolute > it's still 6%) will likely be visible in some cases depending what the > shader is doing. Even the enhanced version seems to miss opengl > conformance (accurate to "about 1 part in 10^5") by roughly a factor of > 10, which stretches the meaning of "about" a bit probably already. > You could also rely on the precision hint for fragment programs to > switch to the faster version instead of a dri conf option (note though > the spec explicitly states implementations are discouraged even in this > case to perform optimizations which could have significant impact on the > output). it helps to have the numbers. when making these decisions. Thank you for your feedback. Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300][PATCH] Add/fix COS & SIN + FP fixes
Rune Petersen wrote:
> .
>
> Rune Petersen wrote:
>> Jerome Glisse wrote:
>>> On 2/11/07, Jerome Glisse <[EMAIL PROTECTED]> wrote:
>>>> On 2/10/07, Rune Petersen <[EMAIL PROTECTED]> wrote:
>>>>> Hi,
>>>>>
>>>>> Getting proper SIN and COS wasn't as easy as it appeared. I had to make
>>>>> make some changes to the fragment program code.
>>>>>
>>>>> general FP changes:
>>>>> - support HHH swizzle for vector instructions.
>>>>> - don't copy a source to a temp when it is not XYZW swizzled, but
>>>>> combine the two and have the swizzle resolve any issues.
>>>>> (saves temps/instructions with more elaborate shader code)
>>>>> - Disable refcounting of temps.
>>>>> The temp R0 in progs/fp/tri-cos.c is freed prematurely.
>>>>> This should be resolved properly.
>>>>> - fix overflow in cnstv[].
>>>>>
>>>>>
>>>>> SIN & COS:
>>>>> they are based on:
>>>>> http://www.devmaster.net/forums/showthread.php?t=5784
>>>>>
>>>>> There is an fast and a slow(high precision) version of SIN & COS.
>>>>>
>>>>> For SIN:
>>>>> fast = 2 vector instructions
>>>>> slow = 5 vector instructions
>>>>>
>>>>> For COS:
>>>>> fast = 5 vector instructions + 2 scaler instructions
>>>>> slow = 8 vector instructions + 2 scaler instructions
>>>>>
>>>>> The fast version appears to do a fine enough job, at least with the
>>>>> simple test I have made.
>>>>>
>>>>>
>>>>> Rune Petersen
>>>> Nice to tackle this :) few comment, maybe we could make an driconf
>>>> option to switch btw fast and slow version (or a more general conf
>>>> option to enable or disable fragprog optimization in case we come
>>>> with more optimization like that in the future).
>>>>
>>>> For the refcounting i am wondering if i didn't bump into that in
>>>> the past, i did use gdb to trace fragprog construction at that
>>>> time and found some strange interaction (which lead me to
>>>> the rework i did on fragprog).
>>>>
>>>> Anyway here from limited testing your patch seems good,
>>>> you should commit it.
>>>>
>>>> best,
>>>> Jerome Glisse
>>>>
>>> Attached a patch to fix refcounting. Basicly whenever a temporary
>>> source was used multiple time inside an instruction that lead to
>>> multiple call to t_hw_src which is correct but as we also decrement
>>> use counter in that function we over decremented the refcount.
>>>
>>> The patch decrement refcount after instruction decoding and avoid
>>> over decrementing refcount.
>>>
>>> (The patch apply over yours)
>>>
>>> best,
>>> Jerome
>> I have found that the main reason for my problem was I forgot to use the
>> keep() on the source.
>>
>> I think your patch is too intrusive. As long as keep() is used at the
>> right places, you could move the refcount inside emit_arith() making the
>> change more contained.
>>
>> Update patch attached.
>>
>> Could I get you to commit this, since I will not be able to find the
>> time to figure GIT out any time (and lost my sig, don't ask).
>>
How I managed to compile that is beyond me.
Here is a proper patch.
Rune Petersen
diff --git a/src/mesa/drivers/dri/r300/r300_context.h b/src/mesa/drivers/dri/r300/r300_context.h
index 02f8e91..b140235 100644
--- a/src/mesa/drivers/dri/r300/r300_context.h
+++ b/src/mesa/drivers/dri/r300/r300_context.h
@@ -729,6 +729,11 @@ struct r300_fragment_program {
GLboolean params_uptodate;
int max_temp_idx;
+
+ /* the index of the sin constant is stored here */
+ GLint const_sin;
+
+ GLuint optimization;
};
#define R300_MAX_AOS_ARRAYS 16
diff --git a/src/mesa/drivers/dri/r300/r300_fragprog.c b/src/mesa/drivers/dri/r300/r300_fragprog.c
index 6e85f0b..b00cf9e 100644
--- a/src/mesa/drivers/dri/r300/r300_fragprog.c
+++ b/src/mesa/drivers/dri/r300/r300_fragprog.c
@@ -33,7 +33,7 @@
/*TODO'S
*
- * - COS/SIN/SCS instructions
+ * - SCS instructions
* - Depth write, WPOS/FOGC inputs
* - FogOption
* - Verify results of opcodes for accuracy, I've only checked them
@@ -187,6 +187,10 @@ static const struct {
#define SLOT_VECTOR (1<<0)
#define SLOT_SCALAR (1<<
Re: [R300][PATCH] Add/fix COS & SIN + FP fixes
.
Rune Petersen wrote:
> Jerome Glisse wrote:
>> On 2/11/07, Jerome Glisse <[EMAIL PROTECTED]> wrote:
>>> On 2/10/07, Rune Petersen <[EMAIL PROTECTED]> wrote:
>>>> Hi,
>>>>
>>>> Getting proper SIN and COS wasn't as easy as it appeared. I had to make
>>>> make some changes to the fragment program code.
>>>>
>>>> general FP changes:
>>>> - support HHH swizzle for vector instructions.
>>>> - don't copy a source to a temp when it is not XYZW swizzled, but
>>>> combine the two and have the swizzle resolve any issues.
>>>> (saves temps/instructions with more elaborate shader code)
>>>> - Disable refcounting of temps.
>>>> The temp R0 in progs/fp/tri-cos.c is freed prematurely.
>>>> This should be resolved properly.
>>>> - fix overflow in cnstv[].
>>>>
>>>>
>>>> SIN & COS:
>>>> they are based on:
>>>> http://www.devmaster.net/forums/showthread.php?t=5784
>>>>
>>>> There is an fast and a slow(high precision) version of SIN & COS.
>>>>
>>>> For SIN:
>>>> fast = 2 vector instructions
>>>> slow = 5 vector instructions
>>>>
>>>> For COS:
>>>> fast = 5 vector instructions + 2 scaler instructions
>>>> slow = 8 vector instructions + 2 scaler instructions
>>>>
>>>> The fast version appears to do a fine enough job, at least with the
>>>> simple test I have made.
>>>>
>>>>
>>>> Rune Petersen
>>> Nice to tackle this :) few comment, maybe we could make an driconf
>>> option to switch btw fast and slow version (or a more general conf
>>> option to enable or disable fragprog optimization in case we come
>>> with more optimization like that in the future).
>>>
>>> For the refcounting i am wondering if i didn't bump into that in
>>> the past, i did use gdb to trace fragprog construction at that
>>> time and found some strange interaction (which lead me to
>>> the rework i did on fragprog).
>>>
>>> Anyway here from limited testing your patch seems good,
>>> you should commit it.
>>>
>>> best,
>>> Jerome Glisse
>>>
>> Attached a patch to fix refcounting. Basicly whenever a temporary
>> source was used multiple time inside an instruction that lead to
>> multiple call to t_hw_src which is correct but as we also decrement
>> use counter in that function we over decremented the refcount.
>>
>> The patch decrement refcount after instruction decoding and avoid
>> over decrementing refcount.
>>
>> (The patch apply over yours)
>>
>> best,
>> Jerome
>
> I have found that the main reason for my problem was I forgot to use the
> keep() on the source.
>
> I think your patch is too intrusive. As long as keep() is used at the
> right places, you could move the refcount inside emit_arith() making the
> change more contained.
>
> Update patch attached.
>
> Could I get you to commit this, since I will not be able to find the
> time to figure GIT out any time (and lost my sig, don't ask).
>
>
> Rune Petersen
>
>
diff --git a/src/mesa/drivers/dri/r300/r300_context.c b/src/mesa/drivers/dri/r300/r300_context.c
diff --git a/src/mesa/drivers/dri/r300/r300_context.h b/src/mesa/drivers/dri/r300/r300_context.h
index 02f8e91..b140235 100644
--- a/src/mesa/drivers/dri/r300/r300_context.h
+++ b/src/mesa/drivers/dri/r300/r300_context.h
@@ -729,6 +729,11 @@ struct r300_fragment_program {
GLboolean params_uptodate;
int max_temp_idx;
+
+ /* the index of the sin constant is stored here */
+ GLint const_sin;
+
+ GLuint optimization;
};
#define R300_MAX_AOS_ARRAYS 16
diff --git a/src/mesa/drivers/dri/r300/r300_fragprog.c b/src/mesa/drivers/dri/r300/r300_fragprog.c
index 6e85f0b..cb250ca 100644
--- a/src/mesa/drivers/dri/r300/r300_fragprog.c
+++ b/src/mesa/drivers/dri/r300/r300_fragprog.c
@@ -33,7 +33,7 @@
/*TODO'S
*
- * - COS/SIN/SCS instructions
+ * - SCS instructions
* - Depth write, WPOS/FOGC inputs
* - FogOption
* - Verify results of opcodes for accuracy, I've only checked them
@@ -51,6 +51,8 @@
#include "r300_fragprog.h"
#include "r300_reg.h"
+#define FAST_SIN
+
/*
* Usefull macros and values
*/
@@ -187,6 +189,10 @@ static const struct {
#define SLOT_VECTOR (1<<0)
#define SLOT_SCALAR (1<<3)
#define SLOT_BOTH (SLOT_VECTOR | SLOT_SCALAR)
+
+/* mapping from SWIZZLE_* to r300 native values for scalar insns */
+#define SWIZZLE_H
Re: [R300][PATCH] Add/fix COS & SIN + FP fixes
Jerome Glisse wrote: > On 2/11/07, Jerome Glisse <[EMAIL PROTECTED]> wrote: >> On 2/10/07, Rune Petersen <[EMAIL PROTECTED]> wrote: >> > Hi, >> > >> > Getting proper SIN and COS wasn't as easy as it appeared. I had to make >> > make some changes to the fragment program code. >> > >> > general FP changes: >> > - support HHH swizzle for vector instructions. >> > - don't copy a source to a temp when it is not XYZW swizzled, but >> > combine the two and have the swizzle resolve any issues. >> > (saves temps/instructions with more elaborate shader code) >> > - Disable refcounting of temps. >> > The temp R0 in progs/fp/tri-cos.c is freed prematurely. >> > This should be resolved properly. >> > - fix overflow in cnstv[]. >> > >> > >> > SIN & COS: >> > they are based on: >> > http://www.devmaster.net/forums/showthread.php?t=5784 >> > >> > There is an fast and a slow(high precision) version of SIN & COS. >> > >> > For SIN: >> > fast = 2 vector instructions >> > slow = 5 vector instructions >> > >> > For COS: >> > fast = 5 vector instructions + 2 scaler instructions >> > slow = 8 vector instructions + 2 scaler instructions >> > >> > The fast version appears to do a fine enough job, at least with the >> > simple test I have made. >> > >> > >> > Rune Petersen >> >> Nice to tackle this :) few comment, maybe we could make an driconf >> option to switch btw fast and slow version (or a more general conf >> option to enable or disable fragprog optimization in case we come >> with more optimization like that in the future). >> >> For the refcounting i am wondering if i didn't bump into that in >> the past, i did use gdb to trace fragprog construction at that >> time and found some strange interaction (which lead me to >> the rework i did on fragprog). >> >> Anyway here from limited testing your patch seems good, >> you should commit it. >> >> best, >> Jerome Glisse >> > > Attached a patch to fix refcounting. Basicly whenever a temporary > source was used multiple time inside an instruction that lead to > multiple call to t_hw_src which is correct but as we also decrement > use counter in that function we over decremented the refcount. > > The patch decrement refcount after instruction decoding and avoid > over decrementing refcount. > > (The patch apply over yours) > > best, > Jerome I have found that the main reason for my problem was I forgot to use the keep() on the source. I think your patch is too intrusive. As long as keep() is used at the right places, you could move the refcount inside emit_arith() making the change more contained. Update patch attached. Could I get you to commit this, since I will not be able to find the time to figure GIT out any time (and lost my sig, don't ask). Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300][PATCH] Add/fix COS & SIN + FP fixes
note to self: don't post this late...
Rune Petersen wrote:
> Hi,
>
> Getting proper SIN and COS wasn't as easy as it appeared. I had to make
> make some changes to the fragment program code.
>
> general FP changes:
> - support HHH swizzle for vector instructions.
> - don't copy a source to a temp when it is not XYZW swizzled, but
> combine the two and have the swizzle resolve any issues.
> (saves temps/instructions with more elaborate shader code)
> - Disable refcounting of temps.
> The temp R0 in progs/fp/tri-cos.c is freed prematurely.
> This should be resolved properly.
> - fix overflow in cnstv[].
>
>
> SIN & COS:
> they are based on:
> http://www.devmaster.net/forums/showthread.php?t=5784
>
> There is an fast and a slow(high precision) version of SIN & COS.
>
> For SIN:
> fast = 2 vector instructions
> slow = 5 vector instructions
>
> For COS:
> fast = 5 vector instructions + 2 scaler instructions
> slow = 8 vector instructions + 2 scaler instructions
>
> The fast version appears to do a fine enough job, at least with the
> simple test I have made.
>
>
> Rune Petersen
diff --git a/src/mesa/drivers/dri/r300/r300_context.c b/src/mesa/drivers/dri/r300/r300_context.c
diff --git a/src/mesa/drivers/dri/r300/r300_context.h b/src/mesa/drivers/dri/r300/r300_context.h
index 02f8e91..fa636d8 100644
--- a/src/mesa/drivers/dri/r300/r300_context.h
+++ b/src/mesa/drivers/dri/r300/r300_context.h
@@ -729,6 +729,9 @@ struct r300_fragment_program {
GLboolean params_uptodate;
int max_temp_idx;
+
+ /* the index of the sin constant is stored here */
+ GLint const_sin;
};
#define R300_MAX_AOS_ARRAYS 16
diff --git a/src/mesa/drivers/dri/r300/r300_fragprog.c b/src/mesa/drivers/dri/r300/r300_fragprog.c
index 6e85f0b..eff86e9 100644
--- a/src/mesa/drivers/dri/r300/r300_fragprog.c
+++ b/src/mesa/drivers/dri/r300/r300_fragprog.c
@@ -51,6 +51,8 @@
#include "r300_fragprog.h"
#include "r300_reg.h"
+#define FAST_SIN
+
/*
* Usefull macros and values
*/
@@ -187,6 +189,10 @@ static const struct {
#define SLOT_VECTOR (1<<0)
#define SLOT_SCALAR (1<<3)
#define SLOT_BOTH (SLOT_VECTOR | SLOT_SCALAR)
+
+/* mapping from SWIZZLE_* to r300 native values for scalar insns */
+#define SWIZZLE_HALF 6
+
#define MAKE_SWZ3(x, y, z) (MAKE_SWIZZLE4(SWIZZLE_##x, \
SWIZZLE_##y, \
SWIZZLE_##z, \
@@ -208,7 +214,7 @@ static const struct r300_pfs_swizzle {
{ MAKE_SWZ3(W, Z, Y), R300_FPI0_ARGC_SRC0CA_WZY, 1, SLOT_BOTH },
{ MAKE_SWZ3(ONE, ONE, ONE), R300_FPI0_ARGC_ONE, 0, 0},
{ MAKE_SWZ3(ZERO, ZERO, ZERO), R300_FPI0_ARGC_ZERO, 0, 0},
- { PFS_INVAL, R300_FPI0_ARGC_HALF, 0, 0},
+ { MAKE_SWZ3(HALF, HALF, HALF), R300_FPI0_ARGC_HALF, 0, 0},
{ PFS_INVAL, 0, 0, 0},
};
@@ -232,8 +238,6 @@ static const struct {
{ PFS_INVAL, PFS_INVAL, PFS_INVAL}
};
-/* mapping from SWIZZLE_* to r300 native values for scalar insns */
-#define SWIZZLE_HALF 6
static const struct {
int base; /* hw value of swizzle */
int stride; /* difference between SRC0/1/2 */
@@ -590,6 +594,7 @@ static GLuint do_swizzle(struct r300_fragment_program *rp,
/* If swizzling from something without an XYZW native swizzle,
* emit result to a temp, and do new swizzle from the temp.
*/
+#if 0
if (REG_GET_VSWZ(src) != SWIZZLE_XYZ ||
REG_GET_SSWZ(src) != SWIZZLE_W) {
GLuint temp = get_temp_reg(rp);
@@ -603,10 +608,33 @@ static GLuint do_swizzle(struct r300_fragment_program *rp,
0);
src = temp;
}
+#endif
/* set scalar swizzling */
REG_SET_SSWZ(src, GET_SWZ(arbswz, 3));
+ if (REG_GET_VSWZ(src) != SWIZZLE_XYZ ||
+ REG_GET_SSWZ(src) != SWIZZLE_W) {
+ GLuint vsrcswz = (v_swiz[REG_GET_VSWZ(src)].hash & (SWZ_X_MASK|SWZ_Y_MASK|SWZ_Z_MASK)) | REG_GET_SSWZ(src) << 9;
+ GLint i;
+
+ GLuint newswz = 0;
+ GLuint offset;
+ for(i=0; i < 4; ++i){
+ offset = GET_SWZ(arbswz, i);
+
+ newswz |= (offset <= 3)?GET_SWZ(vsrcswz, offset) << i*3:offset << i*3;
+ }
+
+ arbswz = newswz & (SWZ_X_MASK|SWZ_Y_MASK|SWZ_Z_MASK);
+ REG_SET_SSWZ(src, GET_SWZ(newswz, 3));
+ }
+ else
+ {
+ /* set scalar swizzling */
+ REG_SET_SSWZ(src, GET_SWZ(arbswz, 3));
+
+ }
do {
vswz = REG_GET_VSWZ(src);
do {
@@ -746,9 +774,11 @@ static int t_hw_src(struct r300_fragment_program *rp,
idx = cs->temps[index].reg;
+/*
if (!REG_GET_NO_USE(src) &&
(--cs->temps[index].refcount == 0))
free_temp(rp, src);
+*/
break;
case REG_TYPE_INPUT:
idx = cs->inputs[index].reg;
@@ -790,9 +820,11 @@ static int t_hw_dst(struct r300_fragment_program *rp,
}
idx = cs->temps[index].reg;
+/*
if (!REG_GET_NO_USE(dest) &&
(--cs->temps[index].refcount == 0))
free_temp(rp, dest);
+*/
cs->dest_in_node |= (1 << idx);
cs->used_in_no
[R300][PATCH] Add/fix COS & SIN + FP fixes
Hi, Getting proper SIN and COS wasn't as easy as it appeared. I had to make make some changes to the fragment program code. general FP changes: - support HHH swizzle for vector instructions. - don't copy a source to a temp when it is not XYZW swizzled, but combine the two and have the swizzle resolve any issues. (saves temps/instructions with more elaborate shader code) - Disable refcounting of temps. The temp R0 in progs/fp/tri-cos.c is freed prematurely. This should be resolved properly. - fix overflow in cnstv[]. SIN & COS: they are based on: http://www.devmaster.net/forums/showthread.php?t=5784 There is an fast and a slow(high precision) version of SIN & COS. For SIN: fast = 2 vector instructions slow = 5 vector instructions For COS: fast = 5 vector instructions + 2 scaler instructions slow = 8 vector instructions + 2 scaler instructions The fast version appears to do a fine enough job, at least with the simple test I have made. Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r500 - where to start?
Tilman Sauerbeck wrote: > Jerome Glisse [2006-12-23 23:23]: >> On 12/23/06, Magnus Ahlberg <[EMAIL PROTECTED]> wrote: >>> I know that there has been some discussion about the r500 chip and how >>> tough it will be to create a working driver for it. However, I for one >>> would love to see an open alternative to the fglrx and I want to know, >>> where to start? I own a laptop with a X1600 mobility radeon card. >>> >>> The current status of the radeon driver is that xorg bails out with >>> "no devices found". >>> Is there any possibility to make the radeon driver to recognize my >>> video card and at least try to initialize it? Where do I start? Are >>> there any tools I can run or anything that will help a more >>> experienced developer to point me in the right direction? >>> >>> Cheers. >>> >> >From limited informations we got on those chips we miss the 2D >> video mode setup. Basicly you need to spy bios/vbe try using >> a tools such as mjg59/airlied vbe, you might also want to spy >> fglrx maybe libsegfault can help you people.freedesktop.org/~glisse/ > > Just for the record, there's also airlied's valgrind-mmt that tracks > MMIO register writes: http://www.skynet.ie/~airlied/patches/valgrind/ > > If that's not enough, I extended it and implemented support for tracking > writes to write-only registers (and other stuff): > http://code-monkey.de/articles/2007/01/08/hacking-up-valgrind-mmt > Might it be an idea to collect these tools on a single page? Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Reduce state updates patch - please test
Hi,
In this patch I try to make the driver practice the art of doing the
least amount of work possible.
This is not complete, but a step in the right direction.
Quake 3 get a ~4% improvement and Nexuiz gets ~7%.
These changes can potentially cause lockups so I was hoping for some
testing before I commit. I intend to apply this after the 6.5.2 release.
Rune Petersen
? depend
? server
Index: r300_fragprog.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_fragprog.h,v
retrieving revision 1.12
diff -u -r1.12 r300_fragprog.h
--- r300_fragprog.h 1 Nov 2006 12:03:36 - 1.12
+++ r300_fragprog.h 25 Nov 2006 14:16:33 -
@@ -114,5 +114,6 @@
struct r300_fragment_program;
extern void r300_translate_fragment_shader(struct r300_fragment_program *rp);
+extern void r300UpdateFragmentParams(GLcontext *ctx);
#endif
Index: r300_render.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_render.c,v
retrieving revision 1.112
diff -u -r1.112 r300_render.c
--- r300_render.c 14 Sep 2006 17:44:58 - 1.112
+++ r300_render.c 25 Nov 2006 14:16:34 -
@@ -337,7 +337,6 @@
radeon_vb_to_rvb(rmesa, VB, &tnl->vb);
}
- r300UpdateShaders(rmesa);
if (r300EmitArrays(ctx))
return GL_TRUE;
@@ -493,8 +492,6 @@
return GL_TRUE;
}
- r300UpdateShaders(rmesa);
-
vp = (struct r300_vertex_program *)CURRENT_VERTEX_SHADER(ctx);
#if 0 /* Draw every second request with software arb vp */
vp->native++;
Index: r300_shader.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_shader.c,v
retrieving revision 1.19
diff -u -r1.19 r300_shader.c
--- r300_shader.c 17 Nov 2006 19:08:05 - 1.19
+++ r300_shader.c 25 Nov 2006 14:16:35 -
@@ -4,16 +4,18 @@
#include "program.h"
#include "tnl/tnl.h"
+#include "r300_state.h"
#include "r300_context.h"
#include "r300_fragprog.h"
+extern int future_hw_tcl_on;
static void
r300BindProgram(GLcontext *ctx, GLenum target, struct gl_program *prog)
{
r300ContextPtr rmesa = R300_CONTEXT(ctx);
- struct r300_vertex_program_cont *vp=(void *)prog;
-
+// struct r300_vertex_program_cont *vp=(void *)prog;
+ struct r300_vertex_program *vp;
switch(target){
case GL_VERTEX_PROGRAM_ARB:
@@ -25,8 +27,24 @@
_mesa_print_program(&vp->mesa_program.Base);
}
#endif
-
+
+ r300_select_vertex_shader(rmesa);
+ vp = (struct r300_vertex_program *)CURRENT_VERTEX_SHADER(ctx);
+ if (vp->translated == GL_FALSE) {
+ fprintf(stderr, "Failing back to sw-tcl\n");
+ hw_tcl_on = future_hw_tcl_on = 0;
+ r300ResetHwState(rmesa);
+
+ return ;
+ }
+
+ r300_setup_rs_unit(ctx);
+ /* fall-through
+ only really needed in rare cases, but good enough for now.
+ */
case GL_FRAGMENT_PROGRAM_ARB:
+// fprintf(stderr, "GL_FRAGMENT_PROGRAM_ARB\n");
+ r300SetupPixelShader(rmesa);
break;
default:
WARN_ONCE("Target not supported yet!\n");
Index: r300_state.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_state.c,v
retrieving revision 1.170
diff -u -r1.170 r300_state.c
--- r300_state.c17 Nov 2006 19:12:42 - 1.170
+++ r300_state.c25 Nov 2006 14:16:36 -
@@ -1713,18 +1713,15 @@
extern void _tnl_UpdateFixedFunctionProgram( GLcontext *ctx );
-extern int future_hw_tcl_on;
-void r300UpdateShaders(r300ContextPtr rmesa)
+void r300UpdateFixedFunctionProgram(r300ContextPtr rmesa)
{
GLcontext *ctx;
struct r300_vertex_program *vp;
int i;
ctx = rmesa->radeon.glCtx;
-
- if (rmesa->NewGLState && hw_tcl_on) {
- rmesa->NewGLState = 0;
-
+ if ( hw_tcl_on ) {
+
for (i = _TNL_FIRST_MAT; i <= _TNL_LAST_MAT; i++) {
rmesa->temp_attrib[i] =
TNL_CONTEXT(ctx)->vb.AttribPtr[i];
TNL_CONTEXT(ctx)->vb.AttribPtr[i] =
&rmesa->dummy_attrib[i];
@@ -1735,21 +1732,7 @@
for (i = _TNL_FIRST_MAT; i <= _TNL_LAST_MAT; i++) {
TNL_CONTEXT(ctx)->vb.AttribPtr[i] =
rmesa->temp_attrib[i];
}
-
- r300
Re: [r300] VBO broken by changes in mesa
Keith Whitwell wrote: > Rune Petersen wrote: >> Hi, >> >> A patch for making sure VBO's are mapped breaks r300: >> >> http://marc.theaimsgroup.com/?l=mesa3d-cvs&m=116364446305536&w=2 >> >> It would appear we "just" need to add _ae_(un)map_vbos() the right >> places in radeon_vtxfmt_a.c. > > Rune, my expectation was that the change wouldn't break drivers, but > that doing the _ae_map/unmap externally would reduce the performance > impact of the change. > I can't debug r300 unfortunately, so if adding the explict map/unmap > helps, go ahead and do so, but could you also post me stacktraces of the > crash (I assume its a crash?) so I can figure out what the underlying > problem might be? I am not that familiar with this code, I did try and all I got was a segfault in map =) Your assert caught something: backtrace: #0 0xe410 in __kernel_vsyscall () #1 0xa7d4c811 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xa7d4dfb9 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xa7d45fbf in __assert_fail () from /lib/tls/i686/cmov/libc.so.6 #4 0xa78c8bc6 in _ae_invalidate_state (ctx=0x0, new_state=4195328) at main/api_arrayelt.c:1299 #5 0xa7936a0d in _tnl_InvalidateState (ctx=0x80ebdc0, new_state=4195328) at tnl/t_context.c:158 #6 0xa78bb00a in r300InvalidateState (ctx=0x80ebdc0, new_state=4195328) at r300_state.c:1878 #7 0xa790b6ac in _mesa_update_state_locked (ctx=0x80ebdc0) at main/state.c:1107 #8 0xa790b6ea in _mesa_update_state (ctx=0x80ebdc0) at main/state.c:1118 #9 0xa793c265 in _tnl_playback_vertex_list (ctx=0x80ebdc0, data=0x8794c10) at tnl/t_save_playback.c:198 #10 0xa79399a2 in _save_compile_vertex_list (ctx=0x80ebdc0) at tnl/t_save_api.c:306 #11 0xa79399e8 in _tnl_SaveFlushVertices (ctx=0x80ebdc0) at tnl/t_save_api.c:1577 #12 0xa78e16fb in _mesa_EndList () at main/dlist.c:6814 #13 0x08050d6b in ?? () #14 0x08068fd4 in ?? () #15 0xa7f7e310 in glutMainLoop () at glut_event.c:967 #16 0x0804c02e in ?? () Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] VBO broken by changes in mesa
Hi, A patch for making sure VBO's are mapped breaks r300: http://marc.theaimsgroup.com/?l=mesa3d-cvs&m=116364446305536&w=2 It would appear we "just" need to add _ae_(un)map_vbos() the right places in radeon_vtxfmt_a.c. Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] fragment.position patch (RFC)
Brian Paul wrote: > Rune Petersen wrote: >> Hi, >> >> I finally managed to iron out the last issue with getting a fully >> working fragment.position for the r300 driver. >> >> This should really require the big discussion if it wasn't for the fact >> that it depends on functional changes in r300_vertexprog.c >> (r300_select_vertex_shader4). >> >> The patches: >> >> r300_select_vertex_shader4: >> The patch makes the vertex program output from the fragment input. It >> makes the driver capable of catching output-input mismatches. primarily >> based on some of Aapo Tahkola's code. >> >> >> mesa-support_internal_driver_state_vars: >> Makes it possible for driver to define its own internal state parameters. > > Checked in. > > >> r300_fragment_wpos5: >> Adds fragment.position support, depends on the above patches. > > This patch doesn't apply cleanly to Mesa CVS head. > > r300_select_vertex_shader4.patch applies OK, but I'll hold off it until > until the first one is resolved. > I had to use diff to make the incremental patch. I may have made it wrong, but it applies cleanly if you do patch -p0 in the r300 directory. Anyway since you have checked the mesa patch, I have concerns committing the other to patches myself. Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] fragment.position patch (RFC)
Hi,
I finally managed to iron out the last issue with getting a fully
working fragment.position for the r300 driver.
This should really require the big discussion if it wasn't for the fact
that it depends on functional changes in r300_vertexprog.c
(r300_select_vertex_shader4).
The patches:
r300_select_vertex_shader4:
The patch makes the vertex program output from the fragment input. It
makes the driver capable of catching output-input mismatches. primarily
based on some of Aapo Tahkola's code.
mesa-support_internal_driver_state_vars:
Makes it possible for driver to define its own internal state parameters.
r300_fragment_wpos5:
Adds fragment.position support, depends on the above patches.
Any questions/ideas/comments/??, I am all ears.
Rune Petersen
P.S.
Brian, Roland, Keith, thank you for your patient replies.
Index: program.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/shader/program.c,v
retrieving revision 1.59
diff -u -r1.59 program.c
--- program.c 10 Oct 2006 22:45:50 - 1.59
+++ program.c 4 Nov 2006 19:03:48 -
@@ -927,7 +927,9 @@
break;
}
default:
- _mesa_problem(ctx, "Bad state switch in _mesa_fetch_state()");
+ /* unknown state indexes are silently ignored
+ * should be handled by the driver.
+ */
return;
}
}
@@ -1000,7 +1002,9 @@
case STATE_TEXRECT_SCALE:
return _NEW_TEXTURE;
default:
- _mesa_problem(NULL, "unexpected int. state in make_state_flags()");
+ /* unknown state indexes are silently ignored and
+ * no flag set, since it is handled by the driver.
+ */
return 0;
}
@@ -1272,7 +1276,7 @@
case STATE_INTERNAL:
break;
default:
- _mesa_problem(NULL, "Invalid state in maka_state_string");
+ _mesa_problem(NULL, "Invalid state in make_state_string");
break;
}
Index: program.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/shader/program.h,v
retrieving revision 1.22
diff -u -r1.22 program.h
--- program.h 20 Sep 2006 14:30:22 - 1.22
+++ program.h 4 Nov 2006 19:03:48 -
@@ -189,7 +189,8 @@
STATE_INTERNAL, /* Mesa additions */
STATE_NORMAL_SCALE,
STATE_TEXRECT_SCALE,
- STATE_POSITION_NORMALIZED/* normalized light position */
+ STATE_POSITION_NORMALIZED, /* normalized light position */
+ STATE_INTERNAL_DRIVER /* first available state index for drivers
(must be last) */
};
diff -x '*.o' -x '*.so' -x Entries -x 'depend*' -Naur r300_context.h
r300_context.h
--- r300_context.h 2006-09-19 18:52:45.0 +0200
+++ r300_context.h 2006-11-16 19:50:22.0 +0100
@@ -549,6 +549,7 @@
/* Can be tested with colormat currently. */
#define VSF_MAX_FRAGMENT_TEMPS (14)
+#define STATE_R300_WINDOW_DIMENSION (STATE_INTERNAL_DRIVER+0)
struct r300_vertex_shader_fragment {
int length;
@@ -623,6 +624,7 @@
int pos_end;
int num_temporaries; /* Number of temp vars used by program */
+ int wpos_idx;
int inputs[VERT_ATTRIB_MAX];
int outputs[VERT_RESULT_MAX];
int native;
diff -x '*.o' -x '*.so' -x Entries -x 'depend*' -Naur r300_fragprog.c
r300_fragprog.c
--- r300_fragprog.c 2006-11-16 20:00:35.0 +0100
+++ r300_fragprog.c 2006-11-13 22:01:30.0 +0100
@@ -1555,6 +1555,13 @@
}
InputsRead &= ~FRAG_BITS_TEX_ANY;
+ /* fragment position treated as a texcoord */
+ if (InputsRead & FRAG_BIT_WPOS) {
+ cs->inputs[FRAG_ATTRIB_WPOS].refcount = 0;
+ cs->inputs[FRAG_ATTRIB_WPOS].reg = get_hw_temp(rp);
+ }
+ InputsRead &= ~FRAG_BIT_WPOS;
+
/* Then primary colour */
if (InputsRead & FRAG_BIT_COL0) {
cs->inputs[FRAG_ATTRIB_COL0].refcount = 0;
diff -x '*.o' -x '*.so' -x Entries -x 'depend*' -Naur r300_state.c r300_state.c
--- r300_state.c2006-11-16 20:00:41.0 +0100
+++ r300_state.c2006-11-16 20:17:58.0 +0100
@@ -1044,6 +1044,59 @@
#endif
}
+static void r300FetchStateParameter(GLcontext *ctx, const enum state_index
state[],
+ GLfloat *value)
+{
+r300ContextPtr r300 = R300_CONTEXT(ctx);
+
+switch(state[0])
+{
+case STATE_INTERNAL:
+ switch(state[1])
+ {
+ case STATE_R300_WINDOW_DIMENSION:
+ value[0] = r300->radeon.dri.drawable->w;/* width */
+ value[1] = r300->radeon.dri.drawable->h;/* height */
+ value[2] = 0.5F;/* for moving range [-1
1] -> [0 1] */
+ value
Re: [r300] partly working fragment.position patch
Brian Paul wrote:
> Rune Petersen wrote:
>> Brian Paul wrote:
>
>>> It seems to me that in ctx->Driver.ProgramStringNotify() you can add any
>>> extra parameters you need to the program's parameters list.
>>
>> I would prefer to make driver specific version of
>> _mesa_add_state_reference() for internal state vars.
>>
>> No matter how this is done, the driver needs to call add_parameter() to
>> safely add to the parameter list.
>>
>> Would it be all right if I made add_parameter non static?
>
> You can't use _mesa_add_state_reference()? Perhaps a new
> _mesa_add_driver_state() function otherwise?
>
Turns out I was just being silly, yes _mesa_add_driver_state() will do
just fine.
>
>>> Then, during state validation in the driver you can load/update any
>>> parameters you might have added.
>>
>> I think it is a good idea.
>>
>>
>>> In _mesa_fetch_state() we could change the default case for switch
>>> (state[i]) to be silent when it sees any state tokens it doesn't
>>> understand (rather than call _mesa_problem()).
>> Provided it is only done for STATE_INTERNAL, it should be pretty safe.
>> Also I was thinking adding something like STATE_INTERNAL_DRIVER or some
>> such so the drivers have a safe place to start adding there own vars.
>>
>>> Does that sound feasible?
>> yes, and it would be less intrusive.
>
> OK. I think the next step would be for you to post a patch with
> whatever you need changed. Then we'll understand the details better.
The program.[ch] changes should be straight forward, the only sore point
is the new state index name (STATE_INTERNAL_DRIVER).
The r300_state.c changes is incomplete, but shows how I intend to update
the state vars. _mesa_add_driver_state() will be used to add them to the
parameter list.
Rune Petersen
Index: r300_state.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_state.c,v
retrieving revision 1.166
diff -u -r1.166 r300_state.c
--- r300_state.c15 Oct 2006 18:22:28 - 1.166
+++ r300_state.c4 Nov 2006 20:07:14 -
@@ -1045,6 +1045,50 @@
#endif
}
+static void r300FetchStateParameter(GLcontext *ctx, const enum state_index
state[],
+ GLfloat *value)
+{
+ switch(state[0])
+ {
+ case STATE_INTERNAL:
+ switch(state[1])
+ {
+ case STATE_R300_WINDOW_DIMENSION:
+ break;
+ default:;
+ }
+ default:;
+ }
+}
+
+/**
+ * Update R300's own internal state parameters.
+ * For now just STATE_R300_WINDOW_DIMENSION
+ */
+static void r300UpdateStateParameters(GLcontext * ctx, GLuint new_state)
+{
+ struct r300_vertex_program_cont *vpc;
+ struct gl_program_parameter_list *paramList;
+ GLuint i;
+
+ if(!(new_state & _NEW_BUFFERS))
+ return;
+
+ vpc = (struct r300_vertex_program_cont *)ctx->VertexProgram._Current;
+ paramList = vpc->mesa_program.Base.Parameters;
+
+ if (!paramList)
+ return;
+
+ for (i = 0; i < paramList->NumParameters; i++) {
+ if (paramList->Parameters[i].Type == PROGRAM_STATE_VAR){
+ r300FetchStateParameter(ctx,
+ paramList->Parameters[i].StateIndexes,
+ paramList->ParameterValues[i]);
+ }
+ }
+}
+
/* =
* Polygon state
*/
@@ -1813,6 +1872,9 @@
if (new_state & (_NEW_BUFFERS | _NEW_COLOR | _NEW_PIXEL)) {
r300UpdateDrawBuffer(ctx);
}
+
+ r300UpdateStateParameters(ctx, new_state);
+
#ifndef CB_DPATH
/* Go inefficiency! */
r300ResetHwState(r300);
Index: program.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/shader/program.c,v
retrieving revision 1.59
diff -u -r1.59 program.c
--- program.c 10 Oct 2006 22:45:50 - 1.59
+++ program.c 4 Nov 2006 19:03:48 -
@@ -927,7 +927,9 @@
break;
}
default:
- _mesa_problem(ctx, "Bad state switch in _mesa_fetch_state()");
+ /* unknown state indexes are silently ignored
+ * should be handled by the driver.
+ */
return;
}
}
@@ -1000,7 +1002,9 @@
case STATE_TEXRECT_SCALE:
return _NEW_TEXTURE;
default:
- _mesa_problem(NULL, "unexpected int. state in make_state_flags()");
+ /* unknown state indexes are silently ignored and
+ * no flag set, since it
Re: [r300] partly working fragment.position patch
Brian Paul wrote:
> Rune Petersen wrote:
>> Keith Whitwell wrote:
>>> Rune Petersen wrote:
>>>
>>> Rune,
>>>
>>> I don't quite understand what you want to do here. Can you show me
>>> the code you'd like to have (ignoring the ctx argument issue)? I
>>> would have thought that we could determine the state statically and
>>> just rely on the driver to set that state in ctx->NewState when
>>> necessary.
>>>
>>
>>
>> I am trying to make generic state vars that the drivers can use.
>>
>> the way I read these functions:
>> make_state_flags() - returns the state flags should trigger an update
>> of the state var.
>>
>> _mesa_fetch_state() - fetches the state var.
>>
>> In order to make generic state vars.
>> - I need to get the flags via a callback to the driver from
>> make_state_flags().
>>
>> I need to fetch the vars via a callback to the driver from
>> _mesa_fetch_state().
>>
>>
>> make_state_flags()
>> {
>> .
>> case STATE_INTERNAL:
>> {
>> switch (state[1]) {
>> case STATE_NORMAL_SCALE:
>> .
>>break;
>> case STATE_TEXRECT_SCALE:
>> .
>>break;
>> case STATE_GENERIC1:
>>assert(ctx->Driver.FetchGenericState);
>>ctx->Driver.FetchGenericState(ctx, state, value);
>>break;
>> }
>> }
>> }
>>
>> _mesa_fetch_state()
>> {
>> .
>> case STATE_INTERNAL:
>> switch (state[1]) {
>> case STATE_NORMAL_SCALE:
>> return _NEW_MODELVIEW;
>> case STATE_TEXRECT_SCALE:
>> return _NEW_TEXTURE;
>> case STATE_GENERIC1:
>> assert(ctx->Driver.GetGenericStateFlags);
>> return ctx->Driver.GetGenericStateFlags(state);
>> }
>>
>> }
>
> It seems to me that in ctx->Driver.ProgramStringNotify() you can add any
> extra parameters you need to the program's parameters list.
I would prefer to make driver specific version of
_mesa_add_state_reference() for internal state vars.
No matter how this is done, the driver needs to call add_parameter() to
safely add to the parameter list.
Would it be all right if I made add_parameter non static?
>
> Then, during state validation in the driver you can load/update any
> parameters you might have added.
I think it is a good idea.
> In _mesa_fetch_state() we could change the default case for switch
> (state[i]) to be silent when it sees any state tokens it doesn't
> understand (rather than call _mesa_problem()).
Provided it is only done for STATE_INTERNAL, it should be pretty safe.
Also I was thinking adding something like STATE_INTERNAL_DRIVER or some
such so the drivers have a safe place to start adding there own vars.
>
> Does that sound feasible?
yes, and it would be less intrusive.
Rune Petersen
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Keith Whitwell wrote:
> Rune Petersen wrote:
>> Keith Whitwell wrote:
>>> Rune Petersen wrote:
>>>> Keith Whitwell wrote:
>>>>> Roland Scheidegger wrote:
>>>>>> Keith Whitwell wrote:
>>>>>> I think Rune is rather refering to the fact that you can't change
>>>>>> (not
>>>>>> with "legal" means at least) the constant you got with
>>>>>> _mesa_add_unnamed_constant.
>>>>> Ah right. I missed that.
>>>>>
>>>>>> I think there exist at least 2 solutions for that. The clean way
>>>>>> would
>>>>>> probably be to add some more INTERNAL_STATE (like i965 driver
>>>>>> uses) so
>>>>>> you use _mesa_add_state_reference instead, in this case mesa's shader
>>>>>> code would need to update program parameter based on the drawable
>>>>>> information - I'm not sure if accessing a driver's drawable
>>>>>> information there would get messy). The easier solution would
>>>>>> probably
>>>>>> be to just directly manipulate the ParameterValues entry associated
>>>>>> with the constant you added, easy though it might be considered
>>>>>> somewhat hackish. Just don't forget you not only have to update the
>>>>>> "constant" within r300UpdateWindow (if the currently bound fp
>>>>>> requires
>>>>>> it), but also when the active fp is switched to another one (and make
>>>>>> sure that a parameter upload is actually triggered if it not already
>>>>>> is upon drawable changes).
>>>>> I think the parameter approach is probably the right one. This would
>>>>> require that there be a callback into the driver to get this state,
>>>>> and
>>>>> more importantly, the driver would have to set a bit in ctx->NewState
>>>>> (perhaps _NEW_BUFFERS) to indicate that a statechange has occurred
>>>>> which
>>>>> would affect that internal state atom.
>>>> Thank you.
>>>>
>>>>
>>>> I've hit a bit of a problem:
>>>> I was planning to have state flags returned from a callback
>>>> make_state_flags().
>>>> something like:
>>>> ctx->Driver.GetGenericStateFlags(state);
>>>>
>>>> The problem being that the context ctx is not a parameter in
>>>> make_state_flags().
>>>>
>>>> Is there smart way of solving this?
>>> Rune,
>>>
>>> I don't quite understand what you want to do here. Can you show me
>>> the code you'd like to have (ignoring the ctx argument issue)? I
>>> would have thought that we could determine the state statically and
>>> just rely on the driver to set that state in ctx->NewState when
>>> necessary.
>>>
>>
>> I am trying to make generic state vars that the drivers can use.
>>
>> the way I read these functions:
>> make_state_flags() - returns the state flags should trigger an update
>> of the state var.
>>
>> _mesa_fetch_state() - fetches the state var.
>>
>> In order to make generic state vars.
>> - I need to get the flags via a callback to the driver from
>> make_state_flags().
>>
>> I need to fetch the vars via a callback to the driver from
>> _mesa_fetch_state().
>>
>>
>> make_state_flags()
>> {
>> .
>> case STATE_INTERNAL:
>> {
>> switch (state[1]) {
>> case STATE_NORMAL_SCALE:
>> .
>>break;
>> case STATE_TEXRECT_SCALE:
>> .
>>break;
>> case STATE_GENERIC1:
>>assert(ctx->Driver.FetchGenericState);
>>ctx->Driver.FetchGenericState(ctx, state, value);
>>break;
>> }
>> }
>> }
>>
>> _mesa_fetch_state()
>> {
>> .
>> case STATE_INTERNAL:
>> switch (state[1]) {
>> case STATE_NORMAL_SCALE:
>> return _NEW_MODELVIEW;
>> case STATE_TEXRECT_SCALE:
>> return _NEW_TEXTURE;
>> case STATE_GENERIC1:
>> assert(ctx->Driver.GetGenericStateFlags);
>> return ctx->Driver.GetGenericStateFlag
Re: [r300] partly working fragment.position patch
Keith Whitwell wrote:
> Rune Petersen wrote:
>> Keith Whitwell wrote:
>>> Roland Scheidegger wrote:
>>>> Keith Whitwell wrote:
>>>> I think Rune is rather refering to the fact that you can't change (not
>>>> with "legal" means at least) the constant you got with
>>>> _mesa_add_unnamed_constant.
>>> Ah right. I missed that.
>>>
>>>> I think there exist at least 2 solutions for that. The clean way would
>>>> probably be to add some more INTERNAL_STATE (like i965 driver uses) so
>>>> you use _mesa_add_state_reference instead, in this case mesa's shader
>>>> code would need to update program parameter based on the drawable
>>>> information - I'm not sure if accessing a driver's drawable
>>>> information there would get messy). The easier solution would probably
>>>> be to just directly manipulate the ParameterValues entry associated
>>>> with the constant you added, easy though it might be considered
>>>> somewhat hackish. Just don't forget you not only have to update the
>>>> "constant" within r300UpdateWindow (if the currently bound fp requires
>>>> it), but also when the active fp is switched to another one (and make
>>>> sure that a parameter upload is actually triggered if it not already
>>>> is upon drawable changes).
>>> I think the parameter approach is probably the right one. This would
>>> require that there be a callback into the driver to get this state, and
>>> more importantly, the driver would have to set a bit in ctx->NewState
>>> (perhaps _NEW_BUFFERS) to indicate that a statechange has occurred which
>>> would affect that internal state atom.
>> Thank you.
>>
>>
>> I've hit a bit of a problem:
>> I was planning to have state flags returned from a callback
>> make_state_flags().
>> something like:
>> ctx->Driver.GetGenericStateFlags(state);
>>
>> The problem being that the context ctx is not a parameter in
>> make_state_flags().
>>
>> Is there smart way of solving this?
>
> Rune,
>
> I don't quite understand what you want to do here. Can you show me the
> code you'd like to have (ignoring the ctx argument issue)? I would have
> thought that we could determine the state statically and just rely on
> the driver to set that state in ctx->NewState when necessary.
>
I am trying to make generic state vars that the drivers can use.
the way I read these functions:
make_state_flags() - returns the state flags should trigger an update
of the state var.
_mesa_fetch_state() - fetches the state var.
In order to make generic state vars.
- I need to get the flags via a callback to the driver from
make_state_flags().
I need to fetch the vars via a callback to the driver from
_mesa_fetch_state().
make_state_flags()
{
.
case STATE_INTERNAL:
{
switch (state[1]) {
case STATE_NORMAL_SCALE:
.
break;
case STATE_TEXRECT_SCALE:
.
break;
case STATE_GENERIC1:
assert(ctx->Driver.FetchGenericState);
ctx->Driver.FetchGenericState(ctx, state, value);
break;
}
}
}
_mesa_fetch_state()
{
.
case STATE_INTERNAL:
switch (state[1]) {
case STATE_NORMAL_SCALE:
return _NEW_MODELVIEW;
case STATE_TEXRECT_SCALE:
return _NEW_TEXTURE;
case STATE_GENERIC1:
assert(ctx->Driver.GetGenericStateFlags);
return ctx->Driver.GetGenericStateFlags(state);
}
}
Rune Petersen
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Keith Whitwell wrote: > Roland Scheidegger wrote: >> Keith Whitwell wrote: >> I think Rune is rather refering to the fact that you can't change (not >> with "legal" means at least) the constant you got with >> _mesa_add_unnamed_constant. > > Ah right. I missed that. > >> I think there exist at least 2 solutions for that. The clean way would >> probably be to add some more INTERNAL_STATE (like i965 driver uses) so >> you use _mesa_add_state_reference instead, in this case mesa's shader >> code would need to update program parameter based on the drawable >> information - I'm not sure if accessing a driver's drawable >> information there would get messy). The easier solution would probably >> be to just directly manipulate the ParameterValues entry associated >> with the constant you added, easy though it might be considered >> somewhat hackish. Just don't forget you not only have to update the >> "constant" within r300UpdateWindow (if the currently bound fp requires >> it), but also when the active fp is switched to another one (and make >> sure that a parameter upload is actually triggered if it not already >> is upon drawable changes). > > I think the parameter approach is probably the right one. This would > require that there be a callback into the driver to get this state, and > more importantly, the driver would have to set a bit in ctx->NewState > (perhaps _NEW_BUFFERS) to indicate that a statechange has occurred which > would affect that internal state atom. Thank you. I've hit a bit of a problem: I was planning to have state flags returned from a callback make_state_flags(). something like: ctx->Driver.GetGenericStateFlags(state); The problem being that the context ctx is not a parameter in make_state_flags(). Is there smart way of solving this? Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Keith Whitwell wrote: > Rune Petersen wrote: >> Rune Petersen wrote: >>> Roland Scheidegger wrote: >>>> Rune Petersen wrote: >>>>> I hit a problem constructing this: >>>>> >>>>> - In order to do range mapping in the vertex shader (if I so choose) >>>>> I will need a constant (0.5), but how to add it? >>>> I think this might work similar to what is used for position invariant >>>> programs, instead of using _mesa_add_state_reference you could try >>>> _mesa_add_named_parameter. Otherwise, you could always "construct" 0.5 >>>> in the shader itself, since you always have the constants 0 and 1 >>>> available thanks to the powerful swizzling capabilities, though >>>> surprsingly it seems somewhat complicated. Either use 2 instructions >>>> (ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of >>>> these, but I guess the approximated EXP should do (2^-1). >>>> >>> This math in this patch appear sound. the doom3-demo issue appear >>> unrelated to fragment.position. >>> >>> This version makes use of existing instructions to calculate >>> result.position. >>> >>> split into 2 parts: >>> - select_vertex_shader changes >>> - The actual fragment.position changes >>> >>> This patch assumes that: >>> >>> - That the temp used to calculate result.position is safe to use (true >>> for std. use). >>> >>> - That fragment.position.x & y wont be used (mostly true, except for >>> exotic programs.) >>>In order to fix this, I'll need to know the window size, but how? > > Surely it's right there in radeon->dri.drawable ? > Now I remember why I can't use radeon->dri.drawable, at least not directly when the shader code is added: When the window size changes the constants have to be updated. Is there a way for the driver to update a constant after construction? Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Rune Petersen wrote:
> Keith Whitwell wrote:
>> Rune Petersen wrote:
>>> Rune Petersen wrote:
>>>> Roland Scheidegger wrote:
>>>>> Rune Petersen wrote:
>>>>>> I hit a problem constructing this:
>>>>>>
>>>>>> - In order to do range mapping in the vertex shader (if I so choose)
>>>>>> I will need a constant (0.5), but how to add it?
>>>>> I think this might work similar to what is used for position invariant
>>>>> programs, instead of using _mesa_add_state_reference you could try
>>>>> _mesa_add_named_parameter. Otherwise, you could always "construct" 0.5
>>>>> in the shader itself, since you always have the constants 0 and 1
>>>>> available thanks to the powerful swizzling capabilities, though
>>>>> surprsingly it seems somewhat complicated. Either use 2 instructions
>>>>> (ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of
>>>>> these, but I guess the approximated EXP should do (2^-1).
>>>>>
>>>> This math in this patch appear sound. the doom3-demo issue appear
>>>> unrelated to fragment.position.
>>>>
>>>> This version makes use of existing instructions to calculate
>>>> result.position.
>>>>
>>>> split into 2 parts:
>>>>- select_vertex_shader changes
>>>>- The actual fragment.position changes
>>>>
>>>> This patch assumes that:
>>>>
>>>> - That the temp used to calculate result.position is safe to use (true
>>>> for std. use).
>>>>
>>>> - That fragment.position.x & y wont be used (mostly true, except for
>>>> exotic programs.)
>>>>In order to fix this, I'll need to know the window size, but how?
>> Surely it's right there in radeon->dri.drawable ?
>>
>>
> Sure it's is, I just managed to miss it, I'm still new at this =)
>
> It is pretty solid now. position x & y are correct. And no regressions
>
> After some extensive testing, I found that a doom3-demo vertex shader
> and the select_vertex_shader code uncovered a bug in the vertex shader.
>
> We can't output result.* unless the fragment shader expects the input.
> The fix is to change the unused outputs to an unused temp.
>
Of cause I manage to attach the right patch
Rune Petersen
? depend
? server
Index: r300_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v
retrieving revision 1.104
diff -u -r1.104 r300_context.h
--- r300_context.h 12 Sep 2006 18:34:43 - 1.104
+++ r300_context.h 7 Oct 2006 12:55:47 -
@@ -592,7 +592,8 @@
extern int hw_tcl_on;
-#define CURRENT_VERTEX_SHADER(ctx) (ctx->VertexProgram._Current)
+//#define CURRENT_VERTEX_SHADER(ctx) (ctx->VertexProgram._Current)
+#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)->selected_vp)
/* Should but doesnt work */
//#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)->curr_vp)
@@ -607,12 +608,18 @@
/* r300_vertex_shader_state and r300_vertex_program should probably be merged
together someday.
* Keeping them them seperate for now should ensure fixed pipeline keeps
functioning properly.
*/
+
+struct r300_vertex_program_key {
+ GLuint InputsRead;
+ GLuint OutputsWritten;
+};
+
struct r300_vertex_program {
- struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_program *next;
+ struct r300_vertex_program_key key;
int translated;
struct r300_vertex_shader_fragment program;
- struct r300_vertex_shader_fragment params;
int pos_end;
int num_temporaries; /* Number of temp vars used by program */
@@ -623,6 +630,12 @@
int use_ref_count;
};
+struct r300_vertex_program_cont {
+ struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_shader_fragment params;
+ struct r300_vertex_program *progs;
+};
+
#define PFS_MAX_ALU_INST 64
#define PFS_MAX_TEX_INST 64
#define PFS_MAX_TEX_INDIRECT 4
@@ -797,6 +810,7 @@
struct r300_cmdbuf cmdbuf;
struct r300_state state;
struct gl_vertex_program *curr_vp;
+ struct r300_vertex_program *selected_vp;
/* Vertex buffers
*/
@@ -854,9 +868,9 @@
extern int r300_get_num_verts(r300ContextPtr rmesa, int num_verts, int prim);
-void r300_translate_vertex_shader(struct r300_vertex_program *vp);
+extern void r300_select_vertex_shader(r300ContextPtr r300);
extern void r300InitShaderFuncs(struct dd_funct
Re: [r300] partly working fragment.position patch
Keith Whitwell wrote:
> Rune Petersen wrote:
>> Rune Petersen wrote:
>>> Roland Scheidegger wrote:
>>>> Rune Petersen wrote:
>>>>> I hit a problem constructing this:
>>>>>
>>>>> - In order to do range mapping in the vertex shader (if I so choose)
>>>>> I will need a constant (0.5), but how to add it?
>>>> I think this might work similar to what is used for position invariant
>>>> programs, instead of using _mesa_add_state_reference you could try
>>>> _mesa_add_named_parameter. Otherwise, you could always "construct" 0.5
>>>> in the shader itself, since you always have the constants 0 and 1
>>>> available thanks to the powerful swizzling capabilities, though
>>>> surprsingly it seems somewhat complicated. Either use 2 instructions
>>>> (ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of
>>>> these, but I guess the approximated EXP should do (2^-1).
>>>>
>>> This math in this patch appear sound. the doom3-demo issue appear
>>> unrelated to fragment.position.
>>>
>>> This version makes use of existing instructions to calculate
>>> result.position.
>>>
>>> split into 2 parts:
>>> - select_vertex_shader changes
>>> - The actual fragment.position changes
>>>
>>> This patch assumes that:
>>>
>>> - That the temp used to calculate result.position is safe to use (true
>>> for std. use).
>>>
>>> - That fragment.position.x & y wont be used (mostly true, except for
>>> exotic programs.)
>>>In order to fix this, I'll need to know the window size, but how?
>
> Surely it's right there in radeon->dri.drawable ?
>
>
Sure it's is, I just managed to miss it, I'm still new at this =)
It is pretty solid now. position x & y are correct. And no regressions
After some extensive testing, I found that a doom3-demo vertex shader
and the select_vertex_shader code uncovered a bug in the vertex shader.
We can't output result.* unless the fragment shader expects the input.
The fix is to change the unused outputs to an unused temp.
Rune Petersen
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend -x depend.bak
r300-dev/r300_context.h r300-dev2/r300_context.h
--- r300-dev/r300_context.h 2006-09-19 18:52:45.0 +0200
+++ r300-dev2/r300_context.h2006-10-06 22:00:40.0 +0200
@@ -623,6 +623,8 @@
int pos_end;
int num_temporaries; /* Number of temp vars used by program */
+ int wpos_idx;
+ const __DRIdrawablePrivate * dPriv;
int inputs[VERT_ATTRIB_MAX];
int outputs[VERT_RESULT_MAX];
int native;
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend -x depend.bak
r300-dev/r300_fragprog.c r300-dev2/r300_fragprog.c
--- r300-dev/r300_fragprog.c2006-09-17 13:49:38.0 +0200
+++ r300-dev2/r300_fragprog.c 2006-10-05 18:59:57.0 +0200
@@ -1400,6 +1400,13 @@
}
InputsRead &= ~FRAG_BITS_TEX_ANY;
+ /* fragment position treated as a texcoord */
+ if (InputsRead & FRAG_BIT_WPOS) {
+ cs->inputs[FRAG_ATTRIB_WPOS].refcount = 0;
+ cs->inputs[FRAG_ATTRIB_WPOS].reg = get_hw_temp(rp);
+ }
+ InputsRead &= ~FRAG_BIT_WPOS;
+
/* Then primary colour */
if (InputsRead & FRAG_BIT_COL0) {
cs->inputs[FRAG_ATTRIB_COL0].refcount = 0;
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend -x depend.bak
r300-dev/r300_state.c r300-dev2/r300_state.c
--- r300-dev/r300_state.c 2006-09-17 13:49:36.0 +0200
+++ r300-dev2/r300_state.c 2006-10-04 22:58:14.0 +0200
@@ -1305,6 +1305,20 @@
r300->hw.rr.cmd[R300_RR_ROUTE_1] = 0;
+ if (InputsRead & FRAG_BIT_WPOS){
+ for (i = 0; i < ctx->Const.MaxTextureUnits; i++)
+ if (!(InputsRead & (FRAG_BIT_TEX0 << i)))
+ break;
+
+ if(i == ctx->Const.MaxTextureUnits){
+ fprintf(stderr, "\tno free texcoord found...\n");
+ exit(0);
+ }
+
+ InputsRead |= (FRAG_BIT_TEX0 << i);
+ InputsRead &= ~FRAG_BIT_WPOS;
+ }
+
for (i=0;iConst.MaxTextureUnits;i++) {
r300->hw.ri.cmd[R300_RI_INTERP_0+i] = 0
| R300_RS_INTERP_USED
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend -x depend.bak
r300-dev/r300_vertexprog.c r300-dev2/r300_vertexprog.c
--- r300-dev/r300_vertexprog.c 2006-10-07
Re: [r300] partly working fragment.position patch
Rune Petersen wrote:
> Roland Scheidegger wrote:
>> Rune Petersen wrote:
>>> I hit a problem constructing this:
>>>
>>> - In order to do range mapping in the vertex shader (if I so choose)
>>> I will need a constant (0.5), but how to add it?
>> I think this might work similar to what is used for position invariant
>> programs, instead of using _mesa_add_state_reference you could try
>> _mesa_add_named_parameter. Otherwise, you could always "construct" 0.5
>> in the shader itself, since you always have the constants 0 and 1
>> available thanks to the powerful swizzling capabilities, though
>> surprsingly it seems somewhat complicated. Either use 2 instructions
>> (ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of
>> these, but I guess the approximated EXP should do (2^-1).
>>
>
> This math in this patch appear sound. the doom3-demo issue appear
> unrelated to fragment.position.
>
> This version makes use of existing instructions to calculate
> result.position.
>
> split into 2 parts:
> - select_vertex_shader changes
> - The actual fragment.position changes
>
> This patch assumes that:
>
> - That the temp used to calculate result.position is safe to use (true
> for std. use).
>
> - That fragment.position.x & y wont be used (mostly true, except for
> exotic programs.)
>In order to fix this, I'll need to know the window size, but how?
>
>
> - That select_vertex_shader changes (by Aapo Tahkola) is acceptable for
> the r300 driver.
>
>
> Rune Petersen
>
oops.. the select_vertex_shader patch included unrelated changes
new version attached.
Rune Petersen
? server
Index: r300_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v
retrieving revision 1.104
diff -u -r1.104 r300_context.h
--- r300_context.h 12 Sep 2006 18:34:43 - 1.104
+++ r300_context.h 5 Oct 2006 19:10:19 -
@@ -592,7 +592,8 @@
extern int hw_tcl_on;
-#define CURRENT_VERTEX_SHADER(ctx) (ctx->VertexProgram._Current)
+//#define CURRENT_VERTEX_SHADER(ctx) (ctx->VertexProgram._Current)
+#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)->selected_vp)
/* Should but doesnt work */
//#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)->curr_vp)
@@ -607,12 +608,18 @@
/* r300_vertex_shader_state and r300_vertex_program should probably be merged
together someday.
* Keeping them them seperate for now should ensure fixed pipeline keeps
functioning properly.
*/
+
+struct r300_vertex_program_key {
+ GLuint InputsRead;
+ GLuint OutputsWritten;
+};
+
struct r300_vertex_program {
- struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_program *next;
+ struct r300_vertex_program_key key;
int translated;
struct r300_vertex_shader_fragment program;
- struct r300_vertex_shader_fragment params;
int pos_end;
int num_temporaries; /* Number of temp vars used by program */
@@ -623,6 +630,12 @@
int use_ref_count;
};
+struct r300_vertex_program_cont {
+ struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_shader_fragment params;
+ struct r300_vertex_program *progs;
+};
+
#define PFS_MAX_ALU_INST 64
#define PFS_MAX_TEX_INST 64
#define PFS_MAX_TEX_INDIRECT 4
@@ -797,6 +810,7 @@
struct r300_cmdbuf cmdbuf;
struct r300_state state;
struct gl_vertex_program *curr_vp;
+ struct r300_vertex_program *selected_vp;
/* Vertex buffers
*/
@@ -854,9 +868,9 @@
extern int r300_get_num_verts(r300ContextPtr rmesa, int num_verts, int prim);
-void r300_translate_vertex_shader(struct r300_vertex_program *vp);
+extern void r300_select_vertex_shader(r300ContextPtr r300);
extern void r300InitShaderFuncs(struct dd_function_table *functions);
-extern int r300VertexProgUpdateParams(GLcontext *ctx, struct
r300_vertex_program *vp, float *dst);
+extern int r300VertexProgUpdateParams(GLcontext *ctx, struct
r300_vertex_program_cont *vp, float *dst);
extern int r300Fallback(GLcontext *ctx);
extern void radeon_vb_to_rvb(r300ContextPtr rmesa, struct radeon_vertex_buffer
*rvb, struct vertex_buffer *vb);
Index: r300_maos.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_maos.c,v
retrieving revision 1.39
diff -u -r1.39 r300_maos.c
--- r300_maos.c 14 Sep 2006 16:17:06 - 1.39
+++ r300_maos.c 5 Oct 2006 19:10:21 -
@@ -407,8 +407,8 @@
if (hw_tcl_on) {
struct r300_vertex_program *prog=(struct r300_vertex_program
*)CURRENT_VERTEX_SHADER(ctx);
Re: [r300] partly working fragment.position patch
Roland Scheidegger wrote:
> Rune Petersen wrote:
>> I hit a problem constructing this:
>>
>> - In order to do range mapping in the vertex shader (if I so choose)
>> I will need a constant (0.5), but how to add it?
> I think this might work similar to what is used for position invariant
> programs, instead of using _mesa_add_state_reference you could try
> _mesa_add_named_parameter. Otherwise, you could always "construct" 0.5
> in the shader itself, since you always have the constants 0 and 1
> available thanks to the powerful swizzling capabilities, though
> surprsingly it seems somewhat complicated. Either use 2 instructions
> (ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of
> these, but I guess the approximated EXP should do (2^-1).
>
This math in this patch appear sound. the doom3-demo issue appear
unrelated to fragment.position.
This version makes use of existing instructions to calculate
result.position.
split into 2 parts:
- select_vertex_shader changes
- The actual fragment.position changes
This patch assumes that:
- That the temp used to calculate result.position is safe to use (true
for std. use).
- That fragment.position.x & y wont be used (mostly true, except for
exotic programs.)
In order to fix this, I'll need to know the window size, but how?
- That select_vertex_shader changes (by Aapo Tahkola) is acceptable for
the r300 driver.
Rune Petersen
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend r300-dev/r300_fragprog.c
r300_fragprog.c
--- r300_fragprog.c 2006-09-17 13:49:38.0 +0200
+++ r300_fragprog.c 2006-10-05 18:59:57.0 +0200
@@ -1400,6 +1400,13 @@
}
InputsRead &= ~FRAG_BITS_TEX_ANY;
+ /* fragment position treated as a texcoord */
+ if (InputsRead & FRAG_BIT_WPOS) {
+ cs->inputs[FRAG_ATTRIB_WPOS].refcount = 0;
+ cs->inputs[FRAG_ATTRIB_WPOS].reg = get_hw_temp(rp);
+ }
+ InputsRead &= ~FRAG_BIT_WPOS;
+
/* Then primary colour */
if (InputsRead & FRAG_BIT_COL0) {
cs->inputs[FRAG_ATTRIB_COL0].refcount = 0;
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend r300_state.c r300_state.c
--- r300_state.c2006-09-17 13:49:36.0 +0200
+++ r300_state.c2006-10-04 22:58:14.0 +0200
@@ -1305,6 +1305,20 @@
r300->hw.rr.cmd[R300_RR_ROUTE_1] = 0;
+ if (InputsRead & FRAG_BIT_WPOS){
+ for (i = 0; i < ctx->Const.MaxTextureUnits; i++)
+ if (!(InputsRead & (FRAG_BIT_TEX0 << i)))
+ break;
+
+ if(i == ctx->Const.MaxTextureUnits){
+ fprintf(stderr, "\tno free texcoord found...\n");
+ exit(0);
+ }
+
+ InputsRead |= (FRAG_BIT_TEX0 << i);
+ InputsRead &= ~FRAG_BIT_WPOS;
+ }
+
for (i=0;iConst.MaxTextureUnits;i++) {
r300->hw.ri.cmd[R300_RI_INTERP_0+i] = 0
| R300_RS_INTERP_USED
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend r300_vertexprog.c
r300_vertexprog.c
--- r300_vertexprog.c 2006-10-05 19:04:22.0 +0200
+++ r300_vertexprog.c 2006-10-05 19:05:10.0 +0200
@@ -950,6 +950,133 @@
//_mesa_print_program(&mesa_vp->Base);
}
+int wpos_idx;
+
+static void insert_pos(struct gl_program *prog, int pos)
+{
+ struct prog_instruction *vpi;
+ struct prog_instruction *vpi_insert;
+ GLuint temp_index, temp_index2;
+ int i = 0;
+
+ vpi = malloc((prog->NumInstructions + 5) * sizeof(struct
prog_instruction));
+ memcpy(vpi, prog->Instructions, (pos+1) * sizeof(struct
prog_instruction));
+
+ vpi_insert = &vpi[pos];
+
+ /* make a copy before outputting VERT_RESULT_HPOS */
+ vpi_insert->DstReg.File = vpi_insert->SrcReg[2].File;
+ vpi_insert->DstReg.Index = temp_index = vpi_insert->SrcReg[2].Index;
+
+ vpi_insert++;
+ memset(vpi_insert, 0, 5 * sizeof(struct prog_instruction));
+
+ vpi_insert[i].Opcode = OPCODE_MOV;
+
+ vpi_insert[i].DstReg.File = PROGRAM_OUTPUT;
+ vpi_insert[i].DstReg.Index = VERT_RESULT_HPOS;
+ vpi_insert[i].DstReg.WriteMask = WRITEMASK_XYZW;
+ vpi_insert[i].DstReg.CondMask = COND_TR;
+
+ vpi_insert[i].SrcReg[0].File = PROGRAM_TEMPORARY;
+ vpi_insert[i].SrcReg[0].Index = temp_index;
+ vpi_insert[i].SrcReg[0].Swizzle = MAKE_SWIZZLE4(SWIZZLE_X, SWIZZLE_Y,
SWIZZLE_Z, SWIZZLE_W);
+ i++;
+
+ /* perspective divide */
+ vpi_insert[i].Opcode = OPCODE_RCP;
+
+ vpi_insert[i].DstReg.File = PROGRAM_TEMPORARY;
+ vpi_insert[i]
Re: [r300] Segfault with Nexius
Paul Heldens wrote: > Rune Petersen wrote: >> I found a suspect, EnablePageFlip. >> Would you happend to have EnablePageFlip enabled? > > I changed/varied all of these options individually, none had an effect. > It keeps crashing at the same moment in the demo (I assume in that same > function.) > > Option "AccelMethod" "XAA" > Option "FBTexPercent" "10" > Option "GARTSize" "64" > Option "EnablePageFlip" "1" > Option "ColorTiling" "1" > Then my bug appear unrelated, what demo did you run? Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Segfault with Nexius
Hi, I found a suspect, EnablePageFlip. Would you happend to have EnablePageFlip enabled? Rune Petersen Paul Heldens wrote: > Rune Petersen wrote: > >> Nexiuz segfaults if you select some "powerups" or use the more exotic >> weapons. > > same here with git xserver, git drm, git radeon, mesa cvs. > (either nexuiz glx or nexuiz sdl) > when I run a demo: > > #0 0xb74b3aea in r300_setup_textures () > from /usr/X11R6/lib/modules/dri/r300_dri.so > #1 0xb74b5569 in r300UpdateShaderStates () > from /usr/X11R6/lib/modules/dri/r300_dri.so > #2 0xb74ab335 in radeonDrawRangeElements () > from /usr/X11R6/lib/modules/dri/r300_dri.so > #3 0x080926ba in ?? () > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Roland Scheidegger wrote:
> Rune Petersen wrote:
>> I hit a problem constructing this:
>>
>> - In order to do range mapping in the vertex shader (if I so choose)
>> I will need a constant (0.5), but how to add it?
> I think this might work similar to what is used for position invariant
> programs, instead of using _mesa_add_state_reference you could try
> _mesa_add_named_parameter. Otherwise, you could always "construct" 0.5
> in the shader itself, since you always have the constants 0 and 1
> available thanks to the powerful swizzling capabilities, though
> surprsingly it seems somewhat complicated. Either use 2 instructions
> (ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of
> these, but I guess the approximated EXP should do (2^-1).
Thank you.
EXP works fine: fp/tri-depth & tri-depth2 now look correct.
I tries Doom-demo (arb2) still looks bad...
Nexiuz is unstable on my system (for some unknown reason)
Are there other games that use fragment.position?
Rune Petersen
? depend
? server
Index: r300_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v
retrieving revision 1.104
diff -u -r1.104 r300_context.h
--- r300_context.h 12 Sep 2006 18:34:43 - 1.104
+++ r300_context.h 23 Sep 2006 21:33:49 -
@@ -592,7 +592,8 @@
extern int hw_tcl_on;
-#define CURRENT_VERTEX_SHADER(ctx) (ctx->VertexProgram._Current)
+//#define CURRENT_VERTEX_SHADER(ctx) (ctx->VertexProgram._Current)
+#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)->selected_vp)
/* Should but doesnt work */
//#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)->curr_vp)
@@ -607,12 +608,18 @@
/* r300_vertex_shader_state and r300_vertex_program should probably be merged
together someday.
* Keeping them them seperate for now should ensure fixed pipeline keeps
functioning properly.
*/
+
+struct r300_vertex_program_key {
+ GLuint InputsRead;
+ GLuint OutputsWritten;
+};
+
struct r300_vertex_program {
- struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_program *next;
+ struct r300_vertex_program_key key;
int translated;
struct r300_vertex_shader_fragment program;
- struct r300_vertex_shader_fragment params;
int pos_end;
int num_temporaries; /* Number of temp vars used by program */
@@ -623,6 +630,12 @@
int use_ref_count;
};
+struct r300_vertex_program_cont {
+ struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_shader_fragment params;
+ struct r300_vertex_program *progs;
+};
+
#define PFS_MAX_ALU_INST 64
#define PFS_MAX_TEX_INST 64
#define PFS_MAX_TEX_INDIRECT 4
@@ -797,6 +810,7 @@
struct r300_cmdbuf cmdbuf;
struct r300_state state;
struct gl_vertex_program *curr_vp;
+ struct r300_vertex_program *selected_vp;
/* Vertex buffers
*/
@@ -854,9 +868,9 @@
extern int r300_get_num_verts(r300ContextPtr rmesa, int num_verts, int prim);
-void r300_translate_vertex_shader(struct r300_vertex_program *vp);
+extern void r300_select_vertex_shader(r300ContextPtr r300);
extern void r300InitShaderFuncs(struct dd_function_table *functions);
-extern int r300VertexProgUpdateParams(GLcontext *ctx, struct
r300_vertex_program *vp, float *dst);
+extern int r300VertexProgUpdateParams(GLcontext *ctx, struct
r300_vertex_program_cont *vp, float *dst);
extern int r300Fallback(GLcontext *ctx);
extern void radeon_vb_to_rvb(r300ContextPtr rmesa, struct radeon_vertex_buffer
*rvb, struct vertex_buffer *vb);
Index: r300_fragprog.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_fragprog.c,v
retrieving revision 1.29
diff -u -r1.29 r300_fragprog.c
--- r300_fragprog.c 31 Aug 2006 18:19:50 - 1.29
+++ r300_fragprog.c 23 Sep 2006 21:33:50 -
@@ -1400,6 +1400,13 @@
}
InputsRead &= ~FRAG_BITS_TEX_ANY;
+ /* fragment position treated as a texcoord */
+ if (InputsRead & FRAG_BIT_WPOS) {
+ cs->inputs[FRAG_ATTRIB_WPOS].refcount = 0;
+ cs->inputs[FRAG_ATTRIB_WPOS].reg = get_hw_temp(rp);
+ }
+ InputsRead &= ~FRAG_BIT_WPOS;
+
/* Then primary colour */
if (InputsRead & FRAG_BIT_COL0) {
cs->inputs[FRAG_ATTRIB_COL0].refcount = 0;
Index: r300_maos.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_maos.c,v
retrieving revision 1.39
diff -u -r1.39 r300_maos.c
--- r300_maos.c 14 Sep 2006 16:17:06 - 1.39
+++ r300_maos.c 23 Sep 2006 21:33:51 -
@@ -407,8 +407,8 @@
if (hw_tcl_on) {
struct
Re: [r300] partly working fragment.position patch
Keith Whitwell wrote: > Rune Petersen wrote: >> It turns out I missed something obvious... >> >> The parameters are passed correctly, I have just not transformed the >> vertex.position to the fragment.position > > I guess that's the viewport transformation, or maybe a perspective > divide followed by viewport transformation. I did do a viewport transformation, but I didn't map the z component from a range of [-1 1] to [0 1]. Perspective divide is also needed, but not in my test app (w=1) ATI appears to do perspective divide in the fragment shader. I hit a problem constructing this: - In order to do range mapping in the vertex shader (if I so choose) I will need a constant (0.5), but how to add it? - If I do perspective divide in the fragment shader, I will need to remap the WPOS from an INPUT to a TEMP. > > But I think there's a bigger problem here -- somehow you're going to > have to arrange for that value to be interpolated over the triangle so > that each fragment ends up with the correct position. > > Maybe they are being interpolated already? I guess it then depends on > whether the interpolation is perspective correct so that once > transformed you really get the right pixel coordinates rather than just > a linear interpolation across the triangle. Is there a way to visually verify this? Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
It turns out I missed something obvious... The parameters are passed correctly, I have just not transformed the vertex.position to the fragment.position Now I just need to figure out how =) Rune Petersen Rune Petersen wrote: > Hi, > > Found some time to have a look at routing fragment.position from the > vertex shader. > > Patch notes: > x & y appear correct, but z is 0 % w is 1. > z appears to be 0 in the vertex shader, because swizzling Z to > position.x is is also 0. > > Most of the patch is the select_vertex_shader changes by Aapo Tahkola. > of interest is in r300_state.c and the bottom of r300_vertexprog.c > > color0 is now always passed from the vertex to the fragment, otherwise > the fragment input registers wont be correctly aligned... > > > I would be grateful for any suggestions. > > Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] partly working fragment.position patch
Hi,
Found some time to have a look at routing fragment.position from the
vertex shader.
Patch notes:
x & y appear correct, but z is 0 % w is 1.
z appears to be 0 in the vertex shader, because swizzling Z to
position.x is is also 0.
Most of the patch is the select_vertex_shader changes by Aapo Tahkola.
of interest is in r300_state.c and the bottom of r300_vertexprog.c
color0 is now always passed from the vertex to the fragment, otherwise
the fragment input registers wont be correctly aligned...
I would be grateful for any suggestions.
Rune Petersen
? depend
? server
Index: r300_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v
retrieving revision 1.104
diff -u -r1.104 r300_context.h
--- r300_context.h 12 Sep 2006 18:34:43 - 1.104
+++ r300_context.h 22 Sep 2006 16:23:28 -
@@ -592,7 +592,8 @@
extern int hw_tcl_on;
-#define CURRENT_VERTEX_SHADER(ctx) (ctx->VertexProgram._Current)
+//#define CURRENT_VERTEX_SHADER(ctx) (ctx->VertexProgram._Current)
+#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)->selected_vp)
/* Should but doesnt work */
//#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)->curr_vp)
@@ -607,12 +608,18 @@
/* r300_vertex_shader_state and r300_vertex_program should probably be merged
together someday.
* Keeping them them seperate for now should ensure fixed pipeline keeps
functioning properly.
*/
+
+struct r300_vertex_program_key {
+ GLuint InputsRead;
+ GLuint OutputsWritten;
+};
+
struct r300_vertex_program {
- struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_program *next;
+ struct r300_vertex_program_key key;
int translated;
struct r300_vertex_shader_fragment program;
- struct r300_vertex_shader_fragment params;
int pos_end;
int num_temporaries; /* Number of temp vars used by program */
@@ -623,6 +630,12 @@
int use_ref_count;
};
+struct r300_vertex_program_cont {
+ struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_shader_fragment params;
+ struct r300_vertex_program *progs;
+};
+
#define PFS_MAX_ALU_INST 64
#define PFS_MAX_TEX_INST 64
#define PFS_MAX_TEX_INDIRECT 4
@@ -797,6 +810,7 @@
struct r300_cmdbuf cmdbuf;
struct r300_state state;
struct gl_vertex_program *curr_vp;
+ struct r300_vertex_program *selected_vp;
/* Vertex buffers
*/
@@ -854,9 +868,9 @@
extern int r300_get_num_verts(r300ContextPtr rmesa, int num_verts, int prim);
-void r300_translate_vertex_shader(struct r300_vertex_program *vp);
+extern void r300_select_vertex_shader(r300ContextPtr r300);
extern void r300InitShaderFuncs(struct dd_function_table *functions);
-extern int r300VertexProgUpdateParams(GLcontext *ctx, struct
r300_vertex_program *vp, float *dst);
+extern int r300VertexProgUpdateParams(GLcontext *ctx, struct
r300_vertex_program_cont *vp, float *dst);
extern int r300Fallback(GLcontext *ctx);
extern void radeon_vb_to_rvb(r300ContextPtr rmesa, struct radeon_vertex_buffer
*rvb, struct vertex_buffer *vb);
Index: r300_fragprog.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_fragprog.c,v
retrieving revision 1.29
diff -u -r1.29 r300_fragprog.c
--- r300_fragprog.c 31 Aug 2006 18:19:50 - 1.29
+++ r300_fragprog.c 22 Sep 2006 16:23:29 -
@@ -1400,6 +1400,13 @@
}
InputsRead &= ~FRAG_BITS_TEX_ANY;
+ /* fragment position treated as a texcoord */
+ if (InputsRead & FRAG_BIT_WPOS) {
+ cs->inputs[FRAG_ATTRIB_WPOS].refcount = 0;
+ cs->inputs[FRAG_ATTRIB_WPOS].reg = get_hw_temp(rp);
+ }
+ InputsRead &= ~FRAG_BIT_WPOS;
+
/* Then primary colour */
if (InputsRead & FRAG_BIT_COL0) {
cs->inputs[FRAG_ATTRIB_COL0].refcount = 0;
Index: r300_maos.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_maos.c,v
retrieving revision 1.39
diff -u -r1.39 r300_maos.c
--- r300_maos.c 14 Sep 2006 16:17:06 - 1.39
+++ r300_maos.c 22 Sep 2006 16:23:30 -
@@ -407,8 +407,8 @@
if (hw_tcl_on) {
struct r300_vertex_program *prog=(struct r300_vertex_program
*)CURRENT_VERTEX_SHADER(ctx);
inputs = prog->inputs;
- InputsRead = CURRENT_VERTEX_SHADER(ctx)->Base.InputsRead;
- OutputsWritten =
CURRENT_VERTEX_SHADER(ctx)->Base.OutputsWritten;
+ InputsRead = CURRENT_VERTEX_SHADER(ctx)->key.InputsRead;
+ OutputsWritten = CURRENT_VERTEX_SHADER(ctx)->key.OutputsWritten;
} else {
DECLARE_RENDERINPUTS(inputs_bitset);
Re: Doom3 benchmarks.
Aapo Tahkola wrote: > On Sun, 13 Aug 2006 02:17:40 +0200 > Rune Petersen <[EMAIL PROTECTED]> wrote: > >> Roland Scheidegger wrote: >>> Rune Petersen wrote: >>>> Roland Scheidegger wrote: >>>> fragment.position input is not implemented yet. fglrx driver parses >>>> it from VP to FP via a texcoord route. I've been hitting my head on >>>> this for some time. Only got as far as only getting a soft lockup >>>> which isn't very useful. >>> That kinda makes sense. On r200 you could already pass vertex data >>> to the fragment registers (but you couldn't use position as input), >>> so the data was interpolated by the texcoord interpolator but >>> texture lookup was disabled (see the ATI_fs spec / r200 dri >>> implementation). At first sight looks like a similar mechanism >>> might be used by r300 I guess, interpolating position or texcoords >>> isn't too different is it? >>> >> I've had been looking into this, and the vertex shader is supplying >> the position to the fragment shader as a texcoord, the only apparent >> difference in shader setup between a position and a real texcoord, is >> a real texcoord is supplied as input for the vertex shader. >> >> >> I would really like to capture the vertex program of >> program/fp/tri-depth and the fglrx driver. >> >> But I'm betting the vertex shader is capable of writing to a texcoord. >> All I need is a safe way for the vertex shader code to know if the >> fragment shader needs the position. >> >> Any help with this would be great. > > Bug #8056 patch can do this. Take a look at r300_select_vertex_shader(). > Thank you. Getting wpos to the fragment shader is not too reliable atm, but something strange: Only x & y are valid for hpos in the vertex shader.. z = 0 & w = 1 as you would expect if they weren't set... Am I missing something obvious? Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Segfault with Nexius
Hi,
Nexiuz segfaults if you select some "powerups" or use the more exotic
weapons.
It would appear that the enabled texture unit have no assigned texobj.
Mesa = current CVS
Nexiuz = 2.0.1 (I expect any version will do)
gdb:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1480714560 (LWP 9519)]
r300_setup_textures (ctx=0xad8d350) at r300_state.c:1188
1188if((t->format & 0xff00)==0xff00) {
(gdb) bt
#0 r300_setup_textures (ctx=0xad8d350) at r300_state.c:1188
#1 0xa753d758 in r300UpdateShaderStates (rmesa=0xad83448) at
r300_state.c:1697
#2 0xa7533b68 in radeonDrawRangeElements (mode=4, min=10620, max=10624,
count=6, type=5125, c_indices=0x98f1f260) at radeon_vtxfmt_a.c:490
Rune Petersen
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
Aapo Tahkola wrote: > On Sun, 13 Aug 2006 02:17:40 +0200 > Rune Petersen <[EMAIL PROTECTED]> wrote: > >> Roland Scheidegger wrote: >>> Rune Petersen wrote: >>>> Roland Scheidegger wrote: >>>>> Adam K Kirchhoff wrote: >>>>>> Just thought I'd post some updated benchmarks of Doom3. These >>>>>> were all run with the first timedemo at 640x480, and (for the >>>>>> open source drivers) with ColorTiling turned on in the xorg.conf >>>>>> file. I'll list all tests with the open source drivers first: >>>>>> >>>>>> x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point >>>>>> in testing it with the r200 or arb2 renderers at the moment.) >>>>> What's the problem with arb2? >>>> fragment.position input is not implemented yet. fglrx driver parses >>>> it from VP to FP via a texcoord route. I've been hitting my head on >>>> this for some time. Only got as far as only getting a soft lockup >>>> which isn't very useful. >>> That kinda makes sense. On r200 you could already pass vertex data >>> to the fragment registers (but you couldn't use position as input), >>> so the data was interpolated by the texcoord interpolator but >>> texture lookup was disabled (see the ATI_fs spec / r200 dri >>> implementation). At first sight looks like a similar mechanism >>> might be used by r300 I guess, interpolating position or texcoords >>> isn't too different is it? >>> >> I've had been looking into this, and the vertex shader is supplying >> the position to the fragment shader as a texcoord, the only apparent >> difference in shader setup between a position and a real texcoord, is >> a real texcoord is supplied as input for the vertex shader. >> >> >> I would really like to capture the vertex program of >> program/fp/tri-depth and the fglrx driver. >> >> But I'm betting the vertex shader is capable of writing to a texcoord. >> All I need is a safe way for the vertex shader code to know if the >> fragment shader needs the position. >> >> Any help with this would be great. > > Bug #8056 patch can do this. Take a look at r300_select_vertex_shader(). > Thank you. About your patch: Can't reproduce your result with gearbox [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4e28 sz=1) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed subtexrate: The result is not too reliable with this, but at least it doesn't crash =) There looks to be a mess up of src & dest. sometimes the src is the teapot other times the root window. Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] TCL fallback with Quake3
Brian Paul wrote: > Rune Petersen wrote: >> Brian Paul wrote: >> >>> Rune Petersen wrote: >>> >>>> Roland Scheidegger wrote: >>>> >>>> >>>>> Rune Petersen wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> Quake3 causes fallback because r300_translate_vertex_shader() returns >>>>>> early and doesn't translate the shader. >>>>>> >>>>>> The culprit: >>>>>> if (!mesa_vp->Base.String) >>>>>> return; >>>>>> >>>>>> To me it looks suspect because checking a pointer to the shader >>>>>> string >>>>>> to verify that the parsed shader is valid doesn't make sense to me. >>>>>> And this check i omitted for fragment translation which uses the same >>>>>> structure. >>>>>> >>>>>> Anything obvious I missed? >>>>> >>>>> That check is there to check if a shader string was even specified in >>>>> the first place (see the thread about "Radeon 9200 >>>>> GetProgramiv(GL_VERTEX_PROGRAM_ARB,..." at the mesa3d-dev list). Maybe >>>>> there is some trouble with that, in the case of quake3 and r300 I'd >>>>> suspect it's because no string exists for the shader at all, because >>>>> quake3 obviously doesn't use vertex shaders and it's internally >>>>> generated by fixed function to shader conversion code. >>>>> >>>> >>>> That is what I suspected. >>>> The way I see it Base.String is always set along side the >>>> Base.Instructions pointer. Since the the code actual depends on >>>> Base.Instructions it makes more sense to check it. >>>> >>>> The only problem is I am unable to test if it failes as intended. >>> >>> If you remove the test for mesa_vp->Base.String does Quake3 work? >> >> >> It does. >> The Mesa generated shaders doesn't set Base.String making Base.String a >> bad choice for checking the validity of the Base struct. >> >> I am just trying to find a check that is valid in all cases and can be >> used by r300 & r200. > > Does replacing the above test with this work? > >if (mesa_vp->Base.NumInstructions == 0) > return GL_FALSE; yes (remove GL_FALSE, void function) Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] TCL fallback with Quake3
Brian Paul wrote: > Rune Petersen wrote: >> Roland Scheidegger wrote: >> >>> Rune Petersen wrote: >>> >>>> Hi, >>>> >>>> Quake3 causes fallback because r300_translate_vertex_shader() returns >>>> early and doesn't translate the shader. >>>> >>>> The culprit: >>>> if (!mesa_vp->Base.String) >>>>return; >>>> >>>> To me it looks suspect because checking a pointer to the shader string >>>> to verify that the parsed shader is valid doesn't make sense to me. >>>> And this check i omitted for fragment translation which uses the same >>>> structure. >>>> >>>> Anything obvious I missed? >>> >>> That check is there to check if a shader string was even specified in >>> the first place (see the thread about "Radeon 9200 >>> GetProgramiv(GL_VERTEX_PROGRAM_ARB,..." at the mesa3d-dev list). Maybe >>> there is some trouble with that, in the case of quake3 and r300 I'd >>> suspect it's because no string exists for the shader at all, because >>> quake3 obviously doesn't use vertex shaders and it's internally >>> generated by fixed function to shader conversion code. >>> >> >> That is what I suspected. >> The way I see it Base.String is always set along side the >> Base.Instructions pointer. Since the the code actual depends on >> Base.Instructions it makes more sense to check it. >> >> The only problem is I am unable to test if it failes as intended. > > If you remove the test for mesa_vp->Base.String does Quake3 work? It does. The Mesa generated shaders doesn't set Base.String making Base.String a bad choice for checking the validity of the Base struct. I am just trying to find a check that is valid in all cases and can be used by r300 & r200. Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] TCL fallback with Quake3
Roland Scheidegger wrote: > Rune Petersen wrote: >> Hi, >> >> Quake3 causes fallback because r300_translate_vertex_shader() returns >> early and doesn't translate the shader. >> >> The culprit: >> if (!mesa_vp->Base.String) >> return; >> >> To me it looks suspect because checking a pointer to the shader string >> to verify that the parsed shader is valid doesn't make sense to me. >> And this check i omitted for fragment translation which uses the same >> structure. >> >> Anything obvious I missed? > That check is there to check if a shader string was even specified in > the first place (see the thread about "Radeon 9200 > GetProgramiv(GL_VERTEX_PROGRAM_ARB,..." at the mesa3d-dev list). Maybe > there is some trouble with that, in the case of quake3 and r300 I'd > suspect it's because no string exists for the shader at all, because > quake3 obviously doesn't use vertex shaders and it's internally > generated by fixed function to shader conversion code. > That is what I suspected. The way I see it Base.String is always set along side the Base.Instructions pointer. Since the the code actual depends on Base.Instructions it makes more sense to check it. The only problem is I am unable to test if it failes as intended. Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] TCL fallback with Quake3
Hi, Quake3 causes fallback because r300_translate_vertex_shader() returns early and doesn't translate the shader. The culprit: if (!mesa_vp->Base.String) return; To me it looks suspect because checking a pointer to the shader string to verify that the parsed shader is valid doesn't make sense to me. And this check i omitted for fragment translation which uses the same structure. Anything obvious I missed? Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] sauerbraten and ut2k4 performance tips
Aapo Tahkola wrote:
> On Tue, 15 Aug 2006 22:16:48 +0200
> Rune Petersen <[EMAIL PROTECTED]> wrote:
>
>> Aapo Tahkola wrote:
>>> Sauerbraten:
>>> a) open console and type "/floatvtx 1" or
>>> b) use this patch or
>>> c) wait for this patch to get integrated
>> What version did you use?
>> the latest release hits a fallback:
>>
>> *WARN_ONCE*
>> File r300_render.c function r300Fallback line 402
>> Software fallback:ctx->Polygon.OffsetLine
>> ***
>
> So I lied. Maybe we should add dri-conf options for them? It's not like
> we could magically fix them all in any case.
Something like this? (could be made nicer =)
I couldn't really decide if it should be part of the driver or as a
separate patch to apply.
It does 2 things:
1) Allows you to disable S3TC, wine-games sometimes need S3TC enabled.
2) Disable fallbacks that usually have low impact.
Rune Petersen
Index: radeon/radeon_screen.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c,v
retrieving revision 1.63
diff -u -r1.63 radeon_screen.c
--- radeon/radeon_screen.c 27 May 2006 09:03:25 - 1.63
+++ radeon/radeon_screen.c 17 Aug 2006 19:03:50 -
@@ -153,6 +153,17 @@
DRI_CONF_DESC(de,"Grösse des Befehlspuffers (in KB)") \
DRI_CONF_OPT_END
+#define DRI_CONF_DISABLE_S3TC(def) \
+DRI_CONF_OPT_BEGIN(disable_s3tc,bool,def) \
+DRI_CONF_DESC(en,"Disable S3TC compression") \
+DRI_CONF_OPT_END
+
+#define DRI_CONF_DISABLE_FALLBACK(def) \
+DRI_CONF_OPT_BEGIN(disable_lowimpact_fallback,bool,def) \
+DRI_CONF_DESC(en,"Disable Low-impact fallback") \
+DRI_CONF_OPT_END
+
+
const char __driConfigOptions[] =
DRI_CONF_BEGIN
DRI_CONF_SECTION_PERFORMANCE
@@ -162,12 +173,14 @@
DRI_CONF_MAX_TEXTURE_IMAGE_UNITS(8, 2, 8)
DRI_CONF_MAX_TEXTURE_COORD_UNITS(8, 2, 8)
DRI_CONF_COMMAND_BUFFER_SIZE(8, 8, 32)
+ DRI_CONF_DISABLE_FALLBACK(false)
DRI_CONF_SECTION_END
DRI_CONF_SECTION_QUALITY
DRI_CONF_TEXTURE_DEPTH(DRI_CONF_TEXTURE_DEPTH_FB)
DRI_CONF_DEF_MAX_ANISOTROPY(1.0, "1.0,2.0,4.0,8.0,16.0")
DRI_CONF_NO_NEG_LOD_BIAS(false)
DRI_CONF_FORCE_S3TC_ENABLE(false)
+ DRI_CONF_DISABLE_S3TC(false)
DRI_CONF_COLOR_REDUCTION(DRI_CONF_COLOR_REDUCTION_DITHER)
DRI_CONF_ROUND_MODE(DRI_CONF_ROUND_TRUNC)
DRI_CONF_DITHER_MODE(DRI_CONF_DITHER_XERRORDIFF)
@@ -176,7 +189,7 @@
DRI_CONF_NO_RAST(false)
DRI_CONF_SECTION_END
DRI_CONF_END;
-static const GLuint __driNConfigOptions = 14;
+static const GLuint __driNConfigOptions = 16;
#ifndef RADEON_DEBUG
int RADEON_DEBUG = 0;
Index: r300/r300_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.c,v
retrieving revision 1.58
diff -u -r1.58 r300_context.c
--- r300/r300_context.c 15 Aug 2006 16:48:06 - 1.58
+++ r300/r300_context.c 17 Aug 2006 19:03:51 -
@@ -166,7 +166,7 @@
0,
};
-
+int disable_lowimpact_fallback;
/* Create the device specific rendering context.
*/
GLboolean r300CreateContext(const __GLcontextModes * glVisual,
@@ -331,7 +331,7 @@
driInitExtensions(ctx, card_extensions, GL_TRUE);
- if (r300->radeon.glCtx->Mesa_DXTn) {
+ if (r300->radeon.glCtx->Mesa_DXTn && !driQueryOptionb
(&r300->radeon.optionCache, "disable_s3tc")) {
_mesa_enable_extension( ctx, "GL_EXT_texture_compression_s3tc" );
_mesa_enable_extension( ctx, "GL_S3_s3tc" );
}
@@ -339,6 +339,8 @@
_mesa_enable_extension( ctx, "GL_EXT_texture_compression_s3tc" );
}
+ disable_lowimpact_fallback = driQueryOptionb(&r300->radeon.optionCache,
"disable_lowimpact_fallback");
+
radeonInitSpanFuncs(ctx);
r300InitCmdBuf(r300);
r300InitState(r300);
Index: r300/r300_render.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_render.c,v
retrieving revision 1.108
diff -u -r1.108 r300_render.c
--- r300/r300_render.c 11 Aug 2006 13:59:37 - 1.108
+++ r300/r300_render.c 17 Aug 2006 19:03:51 -
@@ -397,6 +397,9 @@
FALLBACK_IF(ctx->Polygon.OffsetFill); // GL_POLYGON_OFFSET_FILL
FALLBACK_IF(ctx->Fog.Enabled);
#endif
+
+ if(!disable_lowimpact_fallback){
+
FALLBACK_IF(ctx->Polygon.OffsetPoint); // GL_POLYGON_OF
Re: [r300] sauerbraten and ut2k4 performance tips
Aapo Tahkola wrote: > Sauerbraten: > a) open console and type "/floatvtx 1" or > b) use this patch or > c) wait for this patch to get integrated What version did you use? the latest release hits a fallback: *WARN_ONCE* File r300_render.c function r300Fallback line 402 Software fallback:ctx->Polygon.OffsetLine *** Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] sauerbraten and ut2k4 performance tips
Aapo Tahkola wrote: > Sauerbraten: > a) open console and type "/floatvtx 1" or > b) use this patch or > c) wait for this patch to get integrated > > Unreal Tournament 2004: > Set "UseVBO" option to "True" > in ~/.ut2004/System/UT2004.ini . > > Rune, could you add these to your status list? Yes, thank you. Rune Petersen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
Roland Scheidegger wrote: > Rune Petersen wrote: >> Roland Scheidegger wrote: >>> Adam K Kirchhoff wrote: >>>> Just thought I'd post some updated benchmarks of Doom3. These >>>> were all run with the first timedemo at 640x480, and (for the >>>> open source drivers) with ColorTiling turned on in the xorg.conf >>>> file. I'll list all tests with the open source drivers first: >>>> >>>> x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point >>>> in testing it with the r200 or arb2 renderers at the moment.) >>> What's the problem with arb2? >> >> fragment.position input is not implemented yet. fglrx driver parses >> it from VP to FP via a texcoord route. I've been hitting my head on >> this for some time. Only got as far as only getting a soft lockup >> which isn't very useful. > That kinda makes sense. On r200 you could already pass vertex data to > the fragment registers (but you couldn't use position as input), so the > data was interpolated by the texcoord interpolator but texture lookup > was disabled (see the ATI_fs spec / r200 dri implementation). At first > sight looks like a similar mechanism might be used by r300 I guess, > interpolating position or texcoords isn't too different is it? > I've had been looking into this, and the vertex shader is supplying the position to the fragment shader as a texcoord, the only apparent difference in shader setup between a position and a real texcoord, is a real texcoord is supplied as input for the vertex shader. I would really like to capture the vertex program of program/fp/tri-depth and the fglrx driver. But I'm betting the vertex shader is capable of writing to a texcoord. All I need is a safe way for the vertex shader code to know if the fragment shader needs the position. Any help with this would be great. Rune Petsen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: capturing fglrx command streams?
Roland Scheidegger wrote: > Rune Petersen wrote: >> Hi, >> >> I had absolutely no luck getting any usable R300_CP_IB_BASE address with >> glxtest. >> >> I get and address like this 0xe0711000 which is not a valid address for >> the application. Am I missing something obvious? > Neither can I recently (though I use it for r200). I believe it got > broken with a kernel update some time ago (could have been a fglrx > driver update though). I didn't really look into it (you can still > extract information from the map file if you search for some known > packets). I've been trying to use it for fragment program comparison, but the the only commands for the fragment shader is either stale or bogus, the same for every program. I can read the fragment program from the MMIO, but it doesn't give me the whole picture. Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3 benchmarks.
Roland Scheidegger wrote: > Adam K Kirchhoff wrote: >> Just thought I'd post some updated benchmarks of Doom3. These were >> all run with the first timedemo at 640x480, and (for the open source >> drivers) with ColorTiling turned on in the xorg.conf file. I'll >> list all tests with the open source drivers first: >> >> x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point in >> testing it with the r200 or arb2 renderers at the moment.) > What's the problem with arb2? fragment.position input is not implemented yet. fglrx driver parses it from VP to FP via a texcoord route. I've been hitting my head on this for some time. Only got as far as only getting a soft lockup which isn't very useful. > The r300 driver does not > currently support the r200 render path (and I doubt it will in the > future - there's just not enough interest in supporting ATI_fs on r300 > which is not widely used). > >> 9000 (with arb renderer) - 15.9 9000 (with r200 renderer) - 15.4 >> >> The huge performance increase I get by using an r200 card is pretty >> consistent with what I see in other games. > There seems to be some performance problems with the r300 driver. I > don't think anyone knows what's going on but I could be wrong... I have seen some strange slowdowns not caused bu any apparent fallback (Nexiuz w/bloom) though I could have missed a fallback path. Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
capturing fglrx command streams?
Hi, I had absolutely no luck getting any usable R300_CP_IB_BASE address with glxtest. I get and address like this 0xe0711000 which is not a valid address for the application. Am I missing something obvious? Rune Petersen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][PATCH] fix fp swizzle error
No need, just committed it myself. Thank you Daniel. Rune Petersen Rune Petersen wrote: > Hi, > > Could someone commit this, I don't have CVS access yet, partly my own > fault.. > > A small logic error. > > We need to call do_swizzle() when the scaler _or_ vector unit have a > swizzle other 000/ZERO/111/ONE. > > This ensures that the gloss on banners in ut2004 is not angel-dependent > (since when was banners glossy?). - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300][PATCH] fix fp swizzle error
Hi, Could someone commit this, I don't have CVS access yet, partly my own fault.. A small logic error. We need to call do_swizzle() when the scaler _or_ vector unit have a swizzle other 000/ZERO/111/ONE. This ensures that the gloss on banners in ut2004 is not angel-dependent (since when was banners glossy?). Rune Petersen Index: r300_fragprog.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_fragprog.c,v retrieving revision 1.26 diff -u -r1.26 r300_fragprog.c --- r300_fragprog.c 23 May 2006 02:16:20 - 1.26 +++ r300_fragprog.c 14 Jul 2006 23:51:03 - @@ -529,7 +529,7 @@ } /* no point swizzling ONE/ZERO/HALF constants... */ - if (r.v_swz < SWIZZLE_111 && r.s_swz < SWIZZLE_ZERO) + if (r.v_swz < SWIZZLE_111 || r.s_swz < SWIZZLE_ZERO) r = do_swizzle(rp, r, fpsrc.Swizzle, fpsrc.NegateBase); #if 0 /* WRONG! Need to be able to do individual component negation, - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][PATCH] minor patches
Brian Paul wrote: > Rune Petersen wrote: >> Hi, >> >> Thought I'd share some of my patches. >> >> >> Change vp max instructions: >> The current state op the vp code is capable of executing 255 >> instructions not 255*4. >> >> Disable unused routes (speedup): >> When trying to get fragment.position to work I found the routes were >> only set for the used routes and disabling it gives a few fps in some >> games. I have found no regressions... > > Rune, would you like CVS-write access so you can check in your own > changes? You seem to be getting pretty familiar with the code. > Write access would be nice. I decided to read an OpenGL book, did wonders. Rune Petersen Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300][PATCH] minor patches
Hi,
Thought I'd share some of my patches.
Change vp max instructions:
The current state op the vp code is capable of executing 255
instructions not 255*4.
Disable unused routes (speedup):
When trying to get fragment.position to work I found the routes were
only set for the used routes and disabling it gives a few fps in some
games. I have found no regressions...
Does anyone have any luck enabling fragment.position for the fragment
program.
Rune Petersen
Index: r300_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.c,v
retrieving revision 1.55
diff -u -r1.55 r300_context.c
--- r300_context.c 29 Jun 2006 18:36:51 - 1.55
+++ r300_context.c 29 Jun 2006 20:04:20 -
@@ -308,7 +308,8 @@
_tnl_allow_vertex_fog(ctx, GL_TRUE);
/* currently bogus data */
- ctx->Const.VertexProgram.MaxNativeInstructions=VSF_MAX_FRAGMENT_LENGTH;
+ ctx->Const.VertexProgram.MaxInstructions=VSF_MAX_FRAGMENT_LENGTH/4;
+
ctx->Const.VertexProgram.MaxNativeInstructions=VSF_MAX_FRAGMENT_LENGTH/4;
ctx->Const.VertexProgram.MaxNativeAttribs=16; /* r420 */
ctx->Const.VertexProgram.MaxTemps=32;
ctx->Const.VertexProgram.MaxNativeTemps=/*VSF_MAX_FRAGMENT_TEMPS*/32;
Index: r300_state.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_state.c,v
retrieving revision 1.158
diff -u -r1.158 r300_state.c
--- r300_state.c6 Jun 2006 22:24:12 - 1.158
+++ r300_state.c29 Jun 2006 20:05:39 -
@@ -1316,8 +1316,6 @@
R300_STATECHANGE(r300, rr);
fp_reg = in_texcoords = col_interp_nr = high_rr = 0;
- r300->hw.rr.cmd[R300_RR_ROUTE_0] = 0;
- r300->hw.rr.cmd[R300_RR_ROUTE_1] = 0;
for (i=0;iConst.MaxTextureUnits;i++) {
r300->hw.ri.cmd[R300_RI_INTERP_0+i] = 0
@@ -1325,10 +1323,11 @@
| (in_texcoords << R300_RS_INTERP_SRC_SHIFT)
| interp_magic[i];
+ r300->hw.rr.cmd[R300_RR_ROUTE_0 + fp_reg] = 0;
if (InputsRead & (FRAG_BIT_TEX0<state.texture.tc_count != 0);
- r300->hw.rr.cmd[R300_RR_ROUTE_0 + fp_reg] = 0
- | R300_RS_ROUTE_ENABLE
+ r300->hw.rr.cmd[R300_RR_ROUTE_0 + fp_reg] |=
+ R300_RS_ROUTE_ENABLE
| i /* source INTERP */
| (fp_reg << R300_RS_ROUTE_DEST_SHIFT);
high_rr = fp_reg;
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Doom3 causes VBO leak
Tilman Sauerbeck wrote: > Tilman Sauerbeck [2006-06-11 12:35]: >> Tilman Sauerbeck [2006-05-22 19:42]: >>> [...] >>> >>> I found out that the buffer in question was allocated by >>> r300BufferData(). Now, the proper call to radeon_mm_free() would have >>> been made by r300DeleteBuffer(), but that function was never called. >>> >>> From looking at the code I think this means that it's an application >>> error. >>> Now the question is, should Mesa call the "DeleteBuffer" callback for >>> all buffers that are still alive when the context is destroyed or should >>> r300 be able to cope with it the way it currently is? >> Here's a patch that deletes all VBOs that are still alive when the >> context is destroyed. >> >> Because r300DeleteBuffer() calls radeon_mm_free(), which depends on >> ctx->DriverCtx, we now cannot set DriverCtx to NULL before destroying >> the Mesa context however. >> >> Is this a problem? There's lots of driver calls in free_share_state() >> that might depend on DriverCtx not being NULL, so I don't think I'm >> adding new evil code here. > > Can anyone please comment on that patch? > Other than it fixes the problem for me with no regressions, no sorry. Rune Petersen Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300][PATCH] fix vertex attribs - try 2 - Re: [r300] ARB vp attribs broken?
Brian Paul wrote:
Rune Petersen wrote:
Tilman Sauerbeck wrote:
Rune Petersen [2006-06-25 16:31]:
I've been looking at vertex shaders this weekend.
It would appear that attribs are broken. The most straight forward
way to test this it to compare progs/tests/arbvptest3 to
progs/tests/vptest3
On my system I get different colors when I resize the window.
Can someone confirm this? (it would explain why Doom 3 is broken)
Yes, I have reported this some weeks ago:
http://marc.theaimsgroup.com/?l=dri-devel&m=114855685402158&w=2
Don't know how I fixed that...
It would appear to be caused bu the reshuffling of the attribs.
Any idea where the attribs are passed to the driver?
and how to read the data in the attribs...
I can't comment on the r300 driver, but the change in vertex aliasing in
core Mesa is pretty simple. It's really just a change of which index
into the VB->Attribs[] array corresponds to glVertexAttribARB(index, ...).
This is getting embarrassing...
try 3 attached.
Rune Petersen
Index: radeon_vtxfmt_a.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_vtxfmt_a.c,v
retrieving revision 1.14
diff -u -r1.14 radeon_vtxfmt_a.c
--- radeon_vtxfmt_a.c 12 Jun 2006 22:39:49 - 1.14
+++ radeon_vtxfmt_a.c 26 Jun 2006 19:18:54 -
@@ -73,6 +73,9 @@
for (i=0; i < ctx->Const.MaxTextureCoordUnits; i++)
CONV_VB(VERT_ATTRIB_TEX0 + i, TexCoordPtr[i]);
+
+ for (i=0; i < 16; i++)
+ CONV_VB(VERT_ATTRIB_GENERIC0 + i,
AttribPtr[VERT_ATTRIB_GENERIC0 + i]);
rvb->Primitive = vb->Primitive;
rvb->PrimitiveCount = vb->PrimitiveCount;
Index: r300_maos.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_maos.c,v
retrieving revision 1.33
diff -u -r1.33 r300_maos.c
--- r300_maos.c 12 Jun 2006 22:39:49 - 1.33
+++ r300_maos.c 26 Jun 2006 19:18:54 -
@@ -368,6 +368,12 @@
rmesa->state.aos[nr++].aos_reg =
prog->inputs[VERT_ATTRIB_TEX0+i];
}
}
+ for (i=0;i<(_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC);i++) {
+ if (InputsRead & (1<<(VERT_ATTRIB_GENERIC0+i))) {
+ RENDERINPUTS_SET( inputs_bitset,
_TNL_ATTRIB_GENERIC(i) );
+ rmesa->state.aos[nr++].aos_reg =
prog->inputs[VERT_ATTRIB_GENERIC0+i];
+ }
+ }
nr = 0;
} else {
RENDERINPUTS_COPY( inputs_bitset,
TNL_CONTEXT(ctx)->render_inputs_bitset );
@@ -457,6 +463,14 @@
r300->state.texture.tc_count++;
}
}
+ for (i = 0; i < (_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC); i++) {
+ if (RENDERINPUTS_TEST( inputs_bitset, _TNL_ATTRIB_GENERIC(i) ))
{
+ CONFIGURE_AOS(i_attrib[i], AOS_FORMAT_FLOAT,
+
VB->AttribPtr[VERT_ATTRIB_GENERIC0+i],
+ immd ? 4 :
VB->AttribPtr[VERT_ATTRIB_GENERIC0+i].size,
+ count);
+ }
+ }
for(i=0; i < nr; i++)
if(r300->state.aos[i].aos_format == 2){
assert(r300->state.aos[i].aos_size == 1);
Index: r300_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v
retrieving revision 1.97
diff -u -r1.97 r300_context.h
--- r300_context.h 26 Apr 2006 11:36:27 - 1.97
+++ r300_context.h 26 Jun 2006 19:18:55 -
@@ -544,6 +544,7 @@
int i_color[2];
int i_fog;
int i_tex[R300_MAX_TEXTURE_UNITS];
+ int i_attrib[_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC];
int i_index;
int i_pointsize;
};
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300][PATCH] fix vertex attribs - try 2 - Re: [r300] ARB vp attribs broken?
Brian Paul wrote:
Rune Petersen wrote:
Tilman Sauerbeck wrote:
Rune Petersen [2006-06-25 16:31]:
I've been looking at vertex shaders this weekend.
It would appear that attribs are broken. The most straight forward
way to test this it to compare progs/tests/arbvptest3 to
progs/tests/vptest3
On my system I get different colors when I resize the window.
Can someone confirm this? (it would explain why Doom 3 is broken)
Yes, I have reported this some weeks ago:
http://marc.theaimsgroup.com/?l=dri-devel&m=114855685402158&w=2
Don't know how I fixed that...
It would appear to be caused bu the reshuffling of the attribs.
Any idea where the attribs are passed to the driver?
and how to read the data in the attribs...
I can't comment on the r300 driver, but the change in vertex aliasing in
core Mesa is pretty simple. It's really just a change of which index
into the VB->Attribs[] array corresponds to glVertexAttribARB(index, ...).
try 2:
I believe I have found the problem... the attributes weren't copied..
Patch attached.
Rune Petersen
Index: radeon_vtxfmt_a.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_vtxfmt_a.c,v
retrieving revision 1.14
diff -u -r1.14 radeon_vtxfmt_a.c
--- radeon_vtxfmt_a.c 12 Jun 2006 22:39:49 - 1.14
+++ radeon_vtxfmt_a.c 26 Jun 2006 18:18:06 -
@@ -73,6 +73,9 @@
for (i=0; i < ctx->Const.MaxTextureCoordUnits; i++)
CONV_VB(VERT_ATTRIB_TEX0 + i, TexCoordPtr[i]);
+
+ for (i=0; i < 16; i++)
+ CONV_VB(VERT_ATTRIB_GENERIC0 + i,
AttribPtr[VERT_ATTRIB_GENERIC0 + i]);
rvb->Primitive = vb->Primitive;
rvb->PrimitiveCount = vb->PrimitiveCount;
Index: r300_maos.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_maos.c,v
retrieving revision 1.33
diff -u -r1.33 r300_maos.c
--- r300_maos.c 12 Jun 2006 22:39:49 - 1.33
+++ r300_maos.c 26 Jun 2006 18:18:06 -
@@ -368,6 +368,12 @@
rmesa->state.aos[nr++].aos_reg =
prog->inputs[VERT_ATTRIB_TEX0+i];
}
}
+ for (i=0;i<(_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC);i++) {
+ if (InputsRead & (1<<(VERT_ATTRIB_GENERIC0+i))) {
+ RENDERINPUTS_SET( inputs_bitset,
_TNL_ATTRIB_GENERIC(i) );
+ rmesa->state.aos[nr++].aos_reg =
prog->inputs[VERT_ATTRIB_GENERIC0+i];
+ }
+ }
nr = 0;
} else {
RENDERINPUTS_COPY( inputs_bitset,
TNL_CONTEXT(ctx)->render_inputs_bitset );
@@ -457,6 +463,14 @@
r300->state.texture.tc_count++;
}
}
+ for (i = 0; i < (_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC); i++) {
+ if (RENDERINPUTS_TEST( inputs_bitset, _TNL_ATTRIB_GENERIC(i) ))
{
+ CONFIGURE_AOS(i_attrib[i], AOS_FORMAT_FLOAT,
+
VB->AttribPtr[VERT_ATTRIB_GENERIC0+i],
+ immd ? 4 :
VB->AttribPtr[VERT_ATTRIB_GENERIC0+i].size,
+ count);
+ }
+ }
for(i=0; i < nr; i++)
if(r300->state.aos[i].aos_format == 2){
assert(r300->state.aos[i].aos_size == 1);
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][PATCH] fix vertex attribs - Re: [r300] ARB vp attribs broken
f* it up Rune Petersen Rune Petersen wrote: > Brian Paul wrote: >> Rune Petersen wrote: >>> Tilman Sauerbeck wrote: >>> >>>> Rune Petersen [2006-06-25 16:31]: >>>> >>>>> I've been looking at vertex shaders this weekend. >>>>> >>>>> It would appear that attribs are broken. The most straight forward >>>>> way to test this it to compare progs/tests/arbvptest3 to >>>>> progs/tests/vptest3 >>>>> >>>>> On my system I get different colors when I resize the window. >>>>> >>>>> Can someone confirm this? (it would explain why Doom 3 is broken) >>>> >>>> Yes, I have reported this some weeks ago: >>>> http://marc.theaimsgroup.com/?l=dri-devel&m=114855685402158&w=2 >>>> >>> >>> Don't know how I fixed that... >>> >>> It would appear to be caused bu the reshuffling of the attribs. >>> >>> Any idea where the attribs are passed to the driver? >>> and how to read the data in the attribs... >> >> I can't comment on the r300 driver, but the change in vertex aliasing >> in core Mesa is pretty simple. It's really just a change of which >> index into the VB->Attribs[] array corresponds to >> glVertexAttribARB(index, ...). > > I believe I have found the problem... the attributes weren't copied.. > > Patch attached. > > > Rune Petersen Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300][PATCH] fix vertex attribs - Re: [r300] ARB vp attribs broken
Brian Paul wrote: Rune Petersen wrote: Tilman Sauerbeck wrote: Rune Petersen [2006-06-25 16:31]: I've been looking at vertex shaders this weekend. It would appear that attribs are broken. The most straight forward way to test this it to compare progs/tests/arbvptest3 to progs/tests/vptest3 On my system I get different colors when I resize the window. Can someone confirm this? (it would explain why Doom 3 is broken) Yes, I have reported this some weeks ago: http://marc.theaimsgroup.com/?l=dri-devel&m=114855685402158&w=2 Don't know how I fixed that... It would appear to be caused bu the reshuffling of the attribs. Any idea where the attribs are passed to the driver? and how to read the data in the attribs... I can't comment on the r300 driver, but the change in vertex aliasing in core Mesa is pretty simple. It's really just a change of which index into the VB->Attribs[] array corresponds to glVertexAttribARB(index, ...). I believe I have found the problem... the attributes weren't copied.. Patch attached. Rune Petersen Index: radeon_vtxfmt_a.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_vtxfmt_a.c,v retrieving revision 1.14 diff -u -r1.14 radeon_vtxfmt_a.c --- radeon_vtxfmt_a.c 12 Jun 2006 22:39:49 - 1.14 +++ radeon_vtxfmt_a.c 26 Jun 2006 17:52:09 - @@ -73,6 +73,9 @@ for (i=0; i < ctx->Const.MaxTextureCoordUnits; i++) CONV_VB(VERT_ATTRIB_TEX0 + i, TexCoordPtr[i]); + + for (i=0; i < 16; i++) + CONV_VB(VERT_ATTRIB_GENERIC0 + i, AttribPtr[VERT_ATTRIB_GENERIC0 + i]); rvb->Primitive = vb->Primitive; rvb->PrimitiveCount = vb->PrimitiveCount; Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] ARB vp attribs broken?
Brian Paul wrote: > Rune Petersen wrote: >> Tilman Sauerbeck wrote: >> >>> Rune Petersen [2006-06-25 16:31]: >>> >>>> I've been looking at vertex shaders this weekend. >>>> >>>> It would appear that attribs are broken. The most straight forward >>>> way to test this it to compare progs/tests/arbvptest3 to >>>> progs/tests/vptest3 >>>> >>>> On my system I get different colors when I resize the window. >>>> >>>> Can someone confirm this? (it would explain why Doom 3 is broken) >>> >>> Yes, I have reported this some weeks ago: >>> http://marc.theaimsgroup.com/?l=dri-devel&m=114855685402158&w=2 >>> >> >> Don't know how I fixed that... >> >> It would appear to be caused bu the reshuffling of the attribs. >> >> Any idea where the attribs are passed to the driver? >> and how to read the data in the attribs... > > I can't comment on the r300 driver, but the change in vertex aliasing in > core Mesa is pretty simple. It's really just a change of which index > into the VB->Attribs[] array corresponds to glVertexAttribARB(index, ...). > But how do I pass the data? I assume there is an existing function that does this... Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] ARB vp attribs broken?
Tilman Sauerbeck wrote: > Rune Petersen [2006-06-25 16:31]: >> I've been looking at vertex shaders this weekend. >> >> It would appear that attribs are broken. The most straight forward way >> to test this it to compare progs/tests/arbvptest3 to progs/tests/vptest3 >> >> On my system I get different colors when I resize the window. >> >> Can someone confirm this? (it would explain why Doom 3 is broken) > > Yes, I have reported this some weeks ago: > http://marc.theaimsgroup.com/?l=dri-devel&m=114855685402158&w=2 > Don't know how I fixed that... It would appear to be caused bu the reshuffling of the attribs. Any idea where the attribs are passed to the driver? and how to read the data in the attribs... Rune Petersen Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] ARB vp attribs broken?
Hi, I've been looking at vertex shaders this weekend. It would appear that attribs are broken. The most straight forward way to test this it to compare progs/tests/arbvptest3 to progs/tests/vptest3 On my system I get different colors when I resize the window. Can someone confirm this? (it would explain why Doom 3 is broken) Rune Petersen Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Tremulous & Nexuiz crashes Xorg
Hi, I've just updated Mesa from CVS and now Tremulous & Nexuiz crashes and takes Xorg along with it. Both games causes the same backtrace: Backtrace: 0: /usr/bin/X(xf86SigHandler+0x84) [0x80cef64] 1: [0xe420] 2: /xorg7/lib/xorg/modules/extensions/libGLcore.so(_mesa_resize_framebuffer+0x13b) [0x9b75edfb] 3: /xorg7/lib/xorg/modules/extensions/libGLcore.so(xmesa_resize_buffers+0x4d) [0x9b85b53d] 4: /xorg7/lib/xorg/modules/extensions/libGLcore.so(XMesaResizeBuffers+0x64) [0x9b85fda4] My Xorg is from CVS (June 4 2006) Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Tilman Sauerbeck wrote: > Rune Petersen [2006-06-17 23:38]: > >> I'm having problems with the ARL instruction. >> It appears to mostly return 0. > > Yes. It would probably help if you could document in which cases it > works reliably and in which cases it doesn't :) Something very strange is going on with ARL: I have an array with all non-zero values. I do an ARL on any given value within the array. I read the array myArray[addr.x] and I allways get the value at index 0. if I add an offset myArray[addr.x + ] where addr.x + > "array size" provided addr.x is the correct value, I get 0. Looks to me like there is a bounds check on arrays that work correctly, but the actual array lookup is broken. Is this at all possible? Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Tilman Sauerbeck wrote: > Rune Petersen [2006-06-17 23:38]: > >> I'm having problems with the ARL instruction. >> It appears to mostly return 0. > > Yes. It would probably help if you could document in which cases it > works reliably and in which cases it doesn't :) > Is there a reliable way to read/display the the ADDRESS? I have a hard time trusting a lookup in a array. Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Aapo Tahkola wrote: >>> Try this. >>> It should start working again when you move "MOV R14, R0;" more >>> closer to the instruction that reads R14. >>> >> Gave it a try: >> 23 or less instructions between the two MOV instructions and it works. >> Translates into VSF_MAX_FRAGMENT_TEMPS being 17. >> >> The card is an X800 XT. > > You cannot count it based on how many instructions are between them, > those are there just to increase the time that temp needs to hold its > value before its read. You need to add and initialize new temps if you > want to test higher temps. _mesa_print_program is probably useful. > It was late, what can I say I can confirm the limit of 14 temps. Another thing: I'm having problems with the ARL instruction. It appears to mostly return 0. Is this a known issue? Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Adam K Kirchhoff wrote: Rune Petersen wrote: >> Adam K Kirchhoff wrote: >> >>> Rune Petersen wrote: >>> >>>> set r_renderer "arb" >>>> >>>> r_renderer "arb2" is broken. My guess is that with Mesa 6.5, Doom 3 >>>> (demo) defaults to arb unlike with Mesa CVS. >>>> >>>> Another thing: >>>> I think we need an up-to-date list of what is working and what is >>>> still missing. >>>> I have a small list for my own enjoyment, but it is far from complete: >>>> >>>> http://megahurts.dk/rune/r300_status.html >>>> >>>> >>>> Rune Petersen >>>> >>> Well, certainly one of the biggest bugs (lockups with the 9800) isn't >>> on there :-) >>> >>> >> I added a list of working cards and a list of non-working cards, both >> incomplete, but it's a start :) >> > > When you get a chance, you can add X700 (specifically AGP, though I > imagine PCIe would work) to the list of working cards. > Added, thank you. Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Adam K Kirchhoff wrote: > Rune Petersen wrote: >> >> set r_renderer "arb" >> >> r_renderer "arb2" is broken. My guess is that with Mesa 6.5, Doom 3 >> (demo) defaults to arb unlike with Mesa CVS. >> >> Another thing: >> I think we need an up-to-date list of what is working and what is >> still missing. >> I have a small list for my own enjoyment, but it is far from complete: >> >> http://megahurts.dk/rune/r300_status.html >> >> >> Rune Petersen > > Well, certainly one of the biggest bugs (lockups with the 9800) isn't on > there :-) > I added a list of working cards and a list of non-working cards, both incomplete, but it's a start :) Rune Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Aapo Tahkola wrote: > On Sun, 11 Jun 2006 15:01:15 +0200 > Rune Petersen <[EMAIL PROTECTED]> wrote: > >> Aapo Tahkola wrote: >>> On Wed, 07 Jun 2006 17:49:00 +0200 >>> Rune Petersen <[EMAIL PROTECTED]> wrote: >>> >>>> Aapo Tahkola wrote: >>>>> On Wed, 07 Jun 2006 10:51:08 +0200 >>>>> Rune Petersen <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> Aapo Tahkola wrote: >>>>>>> On Sat, 3 Jun 2006 05:04:04 +0200 >>>>>>> "Jacek Poplawski" <[EMAIL PROTECTED]> wrote: >>>>>>> >>>>>>>> I am trying to run http://maniadrive.raydium.org/ on Radeon >>>>>>>> 9800 with Mesa CVS. >>>>>>>> 3D view in the menu background works, but when I want to play I >>>>>>>> see: >>>>>>>> >>>>>>>> *WARN_ONCE* >>>>>>>> File r300_vertexprog.c function r300_translate_vertex_shader >>>>>>>> line 564 Ran out of temps, num temps 13, us 12 >>>>>>>> *** >>>>>> Can the driver only use 13 temps natively? >>>>>> I was under the impression that there was 32 or 64 vertex temps. >>>>> r300 - r480 only have 14. A good optimizer can make sure that the >>>>> limits are never really hit. >>>>> >>>> Ok, but How do you find there numbers? >>>> >>>> I can only find reports like this (X850: 32 vp temps): >>>> http://www.delphi3d.net/hardware/viewreport.php?report=1412 >>> Remove fallback, craft test app that uses 15 temps and see if it >>> works. Be aware though that you need to beat it hard to get >>> reliable results. I guess there's some capacitance in the >>> circuits... >>> >> I found the 3dsmax viewset in SPECViewperf 8.1 which uses 15 temps. >> increasing the temps count to 15 I can run the viewset multiple times >> without lockup or visible errors. >> >> I think the safest safest way is to set it to 15 and if an app hits >> the fallback do a test to see if the app can run without fallback. > > Try this. > It should start working again when you move "MOV R14, R0;" more > closer to the instruction that reads R14. > Gave it a try: 23 or less instructions between the two MOV instructions and it works. Translates into VSF_MAX_FRAGMENT_TEMPS being 17. The card is an X800 XT. Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Aapo Tahkola wrote: > On Wed, 07 Jun 2006 17:49:00 +0200 > Rune Petersen <[EMAIL PROTECTED]> wrote: > >> Aapo Tahkola wrote: >>> On Wed, 07 Jun 2006 10:51:08 +0200 >>> Rune Petersen <[EMAIL PROTECTED]> wrote: >>> >>>> Aapo Tahkola wrote: >>>>> On Sat, 3 Jun 2006 05:04:04 +0200 >>>>> "Jacek Poplawski" <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> I am trying to run http://maniadrive.raydium.org/ on Radeon 9800 >>>>>> with Mesa CVS. >>>>>> 3D view in the menu background works, but when I want to play I >>>>>> see: >>>>>> >>>>>> *WARN_ONCE* >>>>>> File r300_vertexprog.c function r300_translate_vertex_shader line >>>>>> 564 Ran out of temps, num temps 13, us 12 >>>>>> *** >>>> Can the driver only use 13 temps natively? >>>> I was under the impression that there was 32 or 64 vertex temps. >>> r300 - r480 only have 14. A good optimizer can make sure that the >>> limits are never really hit. >>> >> Ok, but How do you find there numbers? >> >> I can only find reports like this (X850: 32 vp temps): >> http://www.delphi3d.net/hardware/viewreport.php?report=1412 > > Remove fallback, craft test app that uses 15 temps and see if it works. > Be aware though that you need to beat it hard to get reliable results. > I guess there's some capacitance in the circuits... > I found the 3dsmax viewset in SPECViewperf 8.1 which uses 15 temps. increasing the temps count to 15 I can run the viewset multiple times without lockup or visible errors. I think the safest safest way is to set it to 15 and if an app hits the fallback do a test to see if the app can run without fallback. Rune Petersen Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Jerome Glisse wrote: > On 6/11/06, Rune Petersen <[EMAIL PROTECTED]> wrote: >> Another thing: >> I think we need an up-to-date list of what is working and what is still >> missing. >> I have a small list for my own enjoyment, but it is far from complete: >> >> http://megahurts.dk/rune/r300_status.html >> > > Yes such things is usefull. Between i already done individual > component swizzling for fragment program. I got few others > things pending that i need to finish on fragment program... Great, Just remember to update the TODO in fragprog.c. Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Adam K Kirchhoff wrote: > Rune Petersen wrote: >> Adam K Kirchhoff wrote: >> >>> Rune Petersen wrote: >>> >>>> Adam K Kirchhoff wrote: >>>> >>>>> So last night I decided to give the new vertex programs on the r200 >>>>> driver a shot and to see how doom3 stacked up with the r200 driver >>>>> vs the fglrx driver now. With both drivers, I was getting >>>>> approximately 12 FPS with demo1 (with the r200 renderer, of course). >>>>> >>>>> This morning I decided to give the r300 driver a shot, but ran into >>>>> some problems: >>>>> >>>>> http://68.44.156.246/shot-current.jpg >>>>> >>>>> Everything is shiny and textures are all screwed up :-) >>>>> >>>>> Same room, but with the Mesa 6.5 drivers: >>>>> >>>>> http://68.44.156.246/shot-6.5.jpg >>>>> >>>>> If this isn't something currently being worked on, I'll go ahead >>>>> and open up a new bug for it. >>>> set r_renderer "arb" >>>> >>>> r_renderer "arb2" is broken. My guess is that with Mesa 6.5, Doom 3 >>>> (demo) defaults to arb unlike with Mesa CVS. >>>> >>>> >>> Sorry, but according to the output from doom3, it's using the ARB >>> render path for both 6.5 and CVS. >>> >>> >> >> Not for me unless I set r_renderer to "arb". >> >> > You're absolutely right, my mistake... Not sure how I missed that :-) > > However, with drivers from CVS, I do get a segfault when quitting doom3, > which I believe has been brought up here before: > > idRenderSystem::Shutdown() > doom.x86: r300_context.c:389: r300FreeGartAllocations: Assertion I brought it up some time ago, but I had a more pressing problem with Quake3 at the time. Just commenting out r300FreeGartAllocations() makes Doom 3 happy. Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Adam K Kirchhoff wrote: > Rune Petersen wrote: >> Adam K Kirchhoff wrote: >>> So last night I decided to give the new vertex programs on the r200 >>> driver a shot and to see how doom3 stacked up with the r200 driver vs >>> the fglrx driver now. With both drivers, I was getting approximately >>> 12 FPS with demo1 (with the r200 renderer, of course). >>> >>> This morning I decided to give the r300 driver a shot, but ran into >>> some problems: >>> >>> http://68.44.156.246/shot-current.jpg >>> >>> Everything is shiny and textures are all screwed up :-) >>> >>> Same room, but with the Mesa 6.5 drivers: >>> >>> http://68.44.156.246/shot-6.5.jpg >>> >>> If this isn't something currently being worked on, I'll go ahead and >>> open up a new bug for it. >> >> set r_renderer "arb" >> >> r_renderer "arb2" is broken. My guess is that with Mesa 6.5, Doom 3 >> (demo) defaults to arb unlike with Mesa CVS. >> > > Sorry, but according to the output from doom3, it's using the ARB render > path for both 6.5 and CVS. > Not for me unless I set r_renderer to "arb". My autoexec.cfg looks like this: image_useCache "1" image_cacheMegs "256" image_cacheMinK "30640" r_colorbits "32" r_useGL2 "1" image_useNormalCompression "2" com_showFPS "1" image_filter "GL_LINEAR_MIPMAP_LINEAR" image_depth "2" r_preload "1" r_cgVertexProfile "best" r_cgFragmentProfile "best" r_forceLoadImages "1" r_shadows "0" r_useOptimizedShadows "1" r_useTurboShadow "1" r_displayRefresh "85" com_purgeAll "1" r_vertexBufferMegs "48" r_orderIndexes "1" r_renderer "arb" g_skipViewEffects "0" image_preload "1" com_videoRam "256" com_allowconsole "1" r_useDepthBoundsTest "0" r_useCachedDynamicModels "1" image_useCompression "0" image_usePrecompressedTextures "0" r_forceLoadImages "1" r_Multisamples "0" r_useConstantMaterials "1" r_skipSpecular "0" r_skipParticles "0" r_useTripleTextureARB "1" r_skipPostProcess "0" Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Doom3/r300 problems.
Adam K Kirchhoff wrote: > So last night I decided to give the new vertex programs on the r200 > driver a shot and to see how doom3 stacked up with the r200 driver vs > the fglrx driver now. With both drivers, I was getting approximately 12 > FPS with demo1 (with the r200 renderer, of course). > > This morning I decided to give the r300 driver a shot, but ran into some > problems: > > http://68.44.156.246/shot-current.jpg > > Everything is shiny and textures are all screwed up :-) > > Same room, but with the Mesa 6.5 drivers: > > http://68.44.156.246/shot-6.5.jpg > > If this isn't something currently being worked on, I'll go ahead and > open up a new bug for it. set r_renderer "arb" r_renderer "arb2" is broken. My guess is that with Mesa 6.5, Doom 3 (demo) defaults to arb unlike with Mesa CVS. Another thing: I think we need an up-to-date list of what is working and what is still missing. I have a small list for my own enjoyment, but it is far from complete: http://megahurts.dk/rune/r300_status.html Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Aapo Tahkola wrote: > On Wed, 07 Jun 2006 10:51:08 +0200 > Rune Petersen <[EMAIL PROTECTED]> wrote: > >> Aapo Tahkola wrote: >>> On Sat, 3 Jun 2006 05:04:04 +0200 >>> "Jacek Poplawski" <[EMAIL PROTECTED]> wrote: >>> >>>> I am trying to run http://maniadrive.raydium.org/ on Radeon 9800 >>>> with Mesa CVS. >>>> 3D view in the menu background works, but when I want to play I >>>> see: >>>> >>>> *WARN_ONCE* >>>> File r300_vertexprog.c function r300_translate_vertex_shader line >>>> 564 Ran out of temps, num temps 13, us 12 >>>> *** >> Can the driver only use 13 temps natively? >> I was under the impression that there was 32 or 64 vertex temps. > > r300 - r480 only have 14. A good optimizer can make sure that the > limits are never really hit. > Ok, but How do you find there numbers? I can only find reports like this (X850: 32 vp temps): http://www.delphi3d.net/hardware/viewreport.php?report=1412 Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: how to disable vertex programs?
Aapo Tahkola wrote: > On Sat, 3 Jun 2006 05:04:04 +0200 > "Jacek Poplawski" <[EMAIL PROTECTED]> wrote: > >> I am trying to run http://maniadrive.raydium.org/ on Radeon 9800 with >> Mesa CVS. >> 3D view in the menu background works, but when I want to play I see: >> >> *WARN_ONCE* >> File r300_vertexprog.c function r300_translate_vertex_shader line 564 >> Ran out of temps, num temps 13, us 12 >> *** Can the driver only use 13 temps natively? I was under the impression that there was 32 or 64 vertex temps. Rune Petersen -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][patch] retry when busy
Roland Scheidegger wrote: (e.g. while (ret && (errno == EINTR || errno == EBUSY));) And by looking at it, does it make sense that the timeout value in the kernel depends on the kernel-of-the-day HZ value, rather than some hardware-dependant (probably fixed) value? Isn't the timeout value dependent on HZ? 3*HZ is always 3 seconds no matter what HZ is (provided its the same value used to compile the kernel). Ah right. I think I misinterpreted something. That said, 3 seconds sounds like a rather long time, why would there still be timeouts? Two reasons: 1) Badly configured hardware, the hardware does more than it has to (driver optimization issue). 2) Give the hardware a computational task that takes more than 3 seconds in this hardware (some benchmarks or maybe Doom 3 @ 1600x1200 :) ). Not everyday situations, but exiting an app because the frame rate is below 1/3 fps is not very helpful. Maybe print a warning when this happens. Rune Petersen --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][patch] retry when busy
Roland Scheidegger wrote:
Rune Petersen wrote:
The patch makes radeonWaitIrq() try again if -EBUSY is returned.
This fixes benchmark 3 & 4 in progs/demos/gltestperf
Benchmark: 3 - ZSmooth Tex Blend Triangles
Benchmark: 4 - ZSmooth Tex Blend TMesh Triangles
Not an important app, but other apps might run in to this problem.
static void radeonWaitIrq(radeonContextPtr radeon)
{
int ret;
+int tries = 5;
do {
ret = drmCommandWrite(radeon->dri.fd, DRM_RADEON_IRQ_WAIT,
&radeon->iw, sizeof(radeon->iw));
-} while (ret && (errno == EINTR || errno == EAGAIN));
+} while (ret && (errno == EINTR || errno == EAGAIN || (errno ==
EBUSY && --tries)));
Hmm, interesting. This problem does not appear to be r300 specific,
radeon/r200 use the same code (haven't seen problems with it, though).
That said, it looks to me like that ioctl will actually never return
EAGAIN, maybe the original intention was to just wait indefinitely on
EBUSY instead of EAGAIN?
I would agree, but mu knowledge is limited.
(e.g. while (ret && (errno == EINTR || errno == EBUSY));)
And by looking at it, does it make sense that the timeout value in the
kernel depends on the kernel-of-the-day HZ value, rather than some
hardware-dependant (probably fixed) value?
Isn't the timeout value dependent on HZ?
3*HZ is always 3 seconds no matter what HZ is (provided its the same
value used to compile the kernel).
Rune Petersen
---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300][patch] retry when busy
Hi,
The patch makes radeonWaitIrq() try again if -EBUSY is returned.
This fixes benchmark 3 & 4 in progs/demos/gltestperf
Benchmark: 3 - ZSmooth Tex Blend Triangles
Benchmark: 4 - ZSmooth Tex Blend TMesh Triangles
Not an important app, but other apps might run in to this problem.
Rune Petersen
Index: radeon_ioctl.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/radeon_ioctl.c,v
retrieving revision 1.11
diff -u -r1.11 radeon_ioctl.c
--- radeon_ioctl.c 31 Mar 2006 15:48:04 - 1.11
+++ radeon_ioctl.c 27 May 2006 10:59:12 -
@@ -118,11 +118,12 @@
static void radeonWaitIrq(radeonContextPtr radeon)
{
int ret;
+ int tries = 5;
do {
ret = drmCommandWrite(radeon->dri.fd, DRM_RADEON_IRQ_WAIT,
&radeon->iw, sizeof(radeon->iw));
- } while (ret && (errno == EINTR || errno == EAGAIN));
+ } while (ret && (errno == EINTR || errno == EAGAIN || (errno == EBUSY
&& --tries)));
if (ret) {
fprintf(stderr, "%s: drmRadeonIrqWait: %d\n", __FUNCTION__,
Re: ANNOUNCE: X Window System X11R7.1 Released by X.Org Foundation
Zoltan Boszormenyi wrote: Rune Petersen írta: Zoltan Boszormenyi wrote: Leon Shiman írta: X.Org Foundation Releases X11R7.1 _ Congratulations to all the hard working X developers! However, would you please release the latest ATI driver CVS tree as 6.6.1? So many fixes went in since the original 6.6.0. Thanks in advance. 5.8.0 is newer than 6.6.0 for some reason... Rune Petersen The reason is that 6.6.0 was released some time ago for the 7.1 RC series. 5.8.0 was released recently for 7.0 with backported fixes from the CVS tree. That's why I asked for 6.6.1 from latest CVS... Best regards, Zoltán Böszörményi Ok, but it leaves me with a question: How is a mortal supposed to know that that driver version 5.8.0 belongs to 7.0 and that 6.6.0 belongs to 7.1? Especially given that the files are located in the same folder.. Rune Petersen --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ANNOUNCE: X Window System X11R7.1 Released by X.Org Foundation
Zoltan Boszormenyi wrote: Leon Shiman írta: X.Org Foundation Releases X11R7.1 _ Congratulations to all the hard working X developers! However, would you please release the latest ATI driver CVS tree as 6.6.1? So many fixes went in since the original 6.6.0. Thanks in advance. 5.8.0 is newer than 6.6.0 for some reason... Rune Petersen --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] texture corruption with copypixrate & subtexrate
Brian Paul wrote: Rune Petersen wrote: Hi, I get texture corruption if copypixrate or subtexrate is run without being the top most window. This is not a new problem, I just just happened to discover recently. When a window is partially covered by another window, or off the edge of the screen, reading pixels from those areas gives undefined results (because there's no backing store). That's within the OpenGL spec. A bit strange to leave it undefined, but O.K. I'm just trying to make sure everything is as it should be. Thank you for the explanation Rune Petersen --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] texture corruption with copypixrate & subtexrate
Hi, I get texture corruption if copypixrate or subtexrate is run without being the top most window. This is not a new problem, I just just happened to discover recently. My system: Radeon X800XT Xorg & ati driver - CVS HEAD (Apr 24 2006) Mesa + DRM (May 13 2006) Rune Petersen --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] problems leaving the game (Quake 3 + Doom 3)
Brian Paul wrote: Rune Petersen wrote: I found the problem: In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h) And there are no sanity-checks done on the values returned by the drivers. Changing the defines to 16 makes everything work. Changing only MAX_TEXTURE_IMAGE_UNITS should be valid according to src/mesa/main/config.h but a sanity-check fails (if commented out it lockups like before). In the future it would be nice to have bounds checks on the Const.* values. I've added a new function that does some sanity checks on the ctx->Const.* values the first time a context is bound. Great I hope it not a silent check... As discussed a few days ago, we're presently limited to 8 texture image and coordinate units in core Mesa. I see in other words the restriction on MAX_TEXTURE_IMAGE_UNITS have to be there until splitting of the 2 units is completed in Mesa. (managed to find a working mesa3d-dev archive) Rune Petersen --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] problems leaving the game (Quake 3 + Doom 3)
Brian Paul wrote: Rune Petersen wrote: Brian Paul wrote: Rune Petersen wrote: I found the problem: In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h) And there are no sanity-checks done on the values returned by the drivers. Changing the defines to 16 makes everything work. Changing only MAX_TEXTURE_IMAGE_UNITS should be valid according to src/mesa/main/config.h but a sanity-check fails (if commented out it lockups like before). In the future it would be nice to have bounds checks on the Const.* values. I've added a new function that does some sanity checks on the ctx->Const.* values the first time a context is bound. Great I hope it not a silent check... That wouldn't be much good, would it? You could just clamp the value in the case of tex units to 8. I just wanted to make sure the user/devel is notified when the limits of Mesa is reached, so the either Mesa or the driver can be fixed. As discussed a few days ago, we're presently limited to 8 texture image and coordinate units in core Mesa. I see in other words the restriction on MAX_TEXTURE_IMAGE_UNITS have to be there until splitting of the 2 units is completed in Mesa. (managed to find a working mesa3d-dev archive) The splitting is largely complete. The larger issue has to do with the allocation and processing of vertex and fragment attributes. Ok, thank you. Rune Petersen --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] problems leaving the game (Quake 3 + Doom 3)
I found the problem: In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h) And there are no sanity-checks done on the values returned by the drivers. Changing the defines to 16 makes everything work. Changing only MAX_TEXTURE_IMAGE_UNITS should be valid according to src/mesa/main/config.h but a sanity-check fails (if commented out it lockups like before). In the future it would be nice to have bounds checks on the Const.* values. Rune Petersen Brian Paul wrote: Rune Petersen wrote: Adam Jackson wrote: On Wednesday 26 April 2006 10:14, Rune Petersen wrote: Hi, Since the 12 of April there has been a change that causes Quake 3 and Doom 3 (demo)not to exit properly. Quake 3 locks up the system, and Doom 3 does a double fault. The suspect as I see it is: "Ensure all GART allocations are freed on context destruction" But I have yet to confirm it. If you are unable to confirm it, I'll try to track it down myself. That patch was admittedly rather brute-force, but I've not had any issues with it locally. Turns out you're off the hook :) (for now) The Quake 3 lockup is caused/triggered by a change done to Mesa (not r300) between 14 and 15 of April. patch: "Replace ctx->Const.MaxTextureUnits w/ ctx->Const.MaxTexture[Coord/Image]Units in various places." looks like I need to join the Mesa mailing-list... Do you have the MESA_DEBUG env var set? That might give a hint. I think the r300 driver is the only one that can have different values for GL_MAX_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_COORD_UNITS. That might have something to do with it. Looks like those values can be set in your .driconf file (though I'm not sure why that's a config option!). Otherwise, here's the CVS check-in log. You could try undoing the changes in one file at a time until you find the trouble: snip... Index: config.h === RCS file: /cvs/mesa/Mesa/src/mesa/main/config.h,v retrieving revision 1.83 diff -u -r1.83 config.h --- config.h13 Apr 2006 19:21:58 - 1.83 +++ config.h14 May 2006 00:55:27 - @@ -113,7 +113,7 @@ * MAX_TEXTURE_IMAGE_UNITS seen below, since MAX_TEXTURE_UNITS is used * to dimension some arrays that store both coord and image data. */ -#define MAX_TEXTURE_UNITS 8 +#define MAX_TEXTURE_UNITS 16 /[EMAIL PROTECTED]/ @@ -126,8 +126,8 @@ * And, GL_MAX_TEXTURE_UNITS <= MAX_TEXTURE_COORD_UNITS. */ /[EMAIL PROTECTED]/ -#define MAX_TEXTURE_COORD_UNITS 8 -#define MAX_TEXTURE_IMAGE_UNITS 8 +#define MAX_TEXTURE_COORD_UNITS 16 +#define MAX_TEXTURE_IMAGE_UNITS 16 /[EMAIL PROTECTED]/ /**
Re: [r300] problems leaving the game (Quake 3 + Doom 3)
Adam Jackson wrote: On Wednesday 26 April 2006 10:14, Rune Petersen wrote: Hi, Since the 12 of April there has been a change that causes Quake 3 and Doom 3 (demo)not to exit properly. Quake 3 locks up the system, and Doom 3 does a double fault. The suspect as I see it is: "Ensure all GART allocations are freed on context destruction" But I have yet to confirm it. If you are unable to confirm it, I'll try to track it down myself. That patch was admittedly rather brute-force, but I've not had any issues with it locally. Turns out you're off the hook :) (for now) The Quake 3 lockup is caused/triggered by a change done to Mesa (not r300) between 14 and 15 of April. patch: "Replace ctx->Const.MaxTextureUnits w/ ctx->Const.MaxTexture[Coord/Image]Units in various places." looks like I need to join the Mesa mailing-list... Rune Petersen --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] problems leaving the game (Quake 3 + Doom 3)
Hi, Since the 12 of April there has been a change that causes Quake 3 and Doom 3 (demo)not to exit properly. Quake 3 locks up the system, and Doom 3 does a double fault. The suspect as I see it is: "Ensure all GART allocations are freed on context destruction" But I have yet to confirm it. If you are unable to confirm it, I'll try to track it down myself. Rune Petersen --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][PATCH] compile error fix
Wrong button
Now the patch
Rune Petersen
Rune Petersen wrote:
Hi,
r300_state.c seams to fail compilation because of a missing union.
Patch attached.
Rune Petersen
? depend
? server
Index: r300_state.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_state.c,v
retrieving revision 1.153
diff -u -r1.153 r300_state.c
--- r300_state.c11 Apr 2006 11:41:11 - 1.153
+++ r300_state.c11 Apr 2006 18:35:16 -
@@ -1275,7 +1275,7 @@
DECLARE_RENDERINPUTS(index_bitset); /* !hw_tcl_on */
};
-static GLboolean r300_outputs_written_test (r300_outputs_written *ow, GLuint
vp_result,
+static GLboolean r300_outputs_written_test (union r300_outputs_written *ow,
GLuint vp_result,
GLuint tnl_attrib)
{
if (hw_tcl_on)
[r300][PATCH] compile error fix
Hi, r300_state.c seams to fail compilation because of a missing union. Patch attached. Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] changing video settings in Q3 based games causes assertion in radeon_mm_free
It works, you are always quick to respond, thank you. Rune Petersen Aapo Tahkola wrote: On Sat, 08 Apr 2006 20:25:37 +0200 Rune Petersen <[EMAIL PROTECTED]> wrote: Hi, When pressing apply in nexuiz i get this assertion: radeon_mm.c:464: radeon_mm_free: Assertion `id <= rmesa->rmm->u_last' failed. Should work now. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] changing video settings in Q3 based games causes assertion in radeon_mm_free
Hi, When pressing apply in nexuiz i get this assertion: radeon_mm.c:464: radeon_mm_free: Assertion `id <= rmesa->rmm->u_last' failed. Rune Petersen P.S. you've made some nice improvements the few weeks (while I've been away). --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Aapo Tahkola wrote: On Sun, 12 Mar 2006 17:51:16 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: Aapo Tahkola wrote: On Sat, 11 Mar 2006 22:48:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: All this is just a symptom of dri tex heap manager. nwn will reload textures but they will be given different locations on vram. You can print out t->offset at around line 506 of r300_texmem.c if you are interested in seeing how it behaves. But if you do keep in mind that you need to do it after UNLOCK_HARDWARE or else bad things will happen. You should check that Ben's fix is kicking in by looking for message saying: "Setting GART location based on new memory map" in dmesg. If you still see problems with it enabled you can confirm GART overlapping by loading drm.ko with DEBUG=1 (AFAIK) and compairing dev_priv->gart_vm_start against dev_priv->fb_location and dev_priv->fb_size . DRM doesnt print these values but you can calculated it based on Xorg log. Find line that says: (II) RADEON(0): Will use x kb for textures at offset x and compaire upper bound of that against dev_priv->gart_vm_start. Me stupid, there is a module-path in xorg.conf and I forgot to change i to the new path. Now nwn looks nice, and all games works (ut2k? still have corruption(?) on some textures). Nice to hear it works now :) I'v checked in a fix that should make nearly all ut2k4 texturing problems disappear. s3tc multitexturing and 8x8 cubic maps are still broken so try to avoid them. Does nwn still lock? No, not with limited amount I've been playing, but it usually crashed on the first or second map. I've something else that locks up :) progs/demos/clearspd it lockups after a few seconds. Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Aapo Tahkola wrote: On Sat, 11 Mar 2006 22:48:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: All this is just a symptom of dri tex heap manager. nwn will reload textures but they will be given different locations on vram. You can print out t->offset at around line 506 of r300_texmem.c if you are interested in seeing how it behaves. But if you do keep in mind that you need to do it after UNLOCK_HARDWARE or else bad things will happen. You should check that Ben's fix is kicking in by looking for message saying: "Setting GART location based on new memory map" in dmesg. If you still see problems with it enabled you can confirm GART overlapping by loading drm.ko with DEBUG=1 (AFAIK) and compairing dev_priv->gart_vm_start against dev_priv->fb_location and dev_priv->fb_size . DRM doesnt print these values but you can calculated it based on Xorg log. Find line that says: (II) RADEON(0): Will use x kb for textures at offset x and compaire upper bound of that against dev_priv->gart_vm_start. Me stupid, there is a module-path in xorg.conf and I forgot to change i to the new path. Now nwn looks nice, and all games works (ut2k? still have corruption(?) on some textures). I really sorry about this. Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Aapo Tahkola wrote: On Fri, 10 Mar 2006 21:58:50 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: The best images this time were in the menu (grows upwards this time): http://megahurts.dk/rune/stuff/nwn_menu_1.png http://megahurts.dk/rune/stuff/nwn_menu_2.png http://megahurts.dk/rune/stuff/nwn_menu_3.png Get xf86-video-ati and drm with Ben's fixes and try again. You might see it go upwards or downwards depending on how they are rending. nwn background image is made up of four textures sized 512x512, 512x88, 288x512, 288x88. I assumed I had a snapshot with all Ben's changes, I was wrong. updating xf86-video-ati cured the corruption then starting nwn the second time. As for the in-game corruption its a little different now. the second map loaded still have corrupted textures (slightly more then before). if I return to the first map and enter the second map again there is no corruption apart for some green on the weapons. all subsequent maps load with no trouble. there might still be trouble with maps that needs textures not already loaded. Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Aapo Tahkola wrote: On Fri, 10 Mar 2006 18:27:51 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: I tried it, it had no effect, I don't think its the temp registers. I suspect there is something broken with the vp code or it triggers a bug somewhere else. Do I recall correctly that you have had this problem with textures before hw vps were enabled too? Yes I did but a different kind, flashing "tiles" of colors on the texture. was fix with clear cache patch ( this was also reported by others). Also I'm am able to see corruption in the nwn loading/splash screen. The corruption seams structured, and it gradually changes from left to right, top to bottom. Is there any way to capture this? (without using a camera) I dont think iv seen anything like that but seeing it on a flat surface might set off some ideas. The best images this time were in the menu (grows upwards this time): http://megahurts.dk/rune/stuff/nwn_menu_1.png http://megahurts.dk/rune/stuff/nwn_menu_2.png http://megahurts.dk/rune/stuff/nwn_menu_3.png Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Aapo Tahkola wrote: On Sat, 04 Mar 2006 20:55:50 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: Update: The "Free temps when possible" patch makes NWN lockup again. It would appear that hw tcl is very fragile on some cards. Sorry, I missed your mail. I just added option that will initialize all temps in vertex programs when enabled. This does not cover initializing outputs so it is still possible that something goes wrong there. You can use it by exporting R300_VP_SAFETY in your env. You should see WARN_ONCE when its enabled but keep in mind that nwn repipes stderr to /dev/null so you wont see it. I tried it, it had no effect, I don't think its the temp registers. I suspect there is something broken with the vp code or it triggers a bug somewhere else. Also I'm am able to see corruption in the nwn loading/splash screen. The corruption seams structured, and it gradually changes from left to right, top to bottom. Is there any way to capture this? (without using a camera) I'm hoping to fix this after GLSL support has been added so I don't have to rewrite it twice. great, I'm just trying to make sure everything is thought of. avoiding another rewrite. Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] CVS HEAD segfaults on r420
Aapo Tahkola wrote: Missed these: *WARN_ONCE* File radeon_mm.c function radeon_mm_alloc line 182 Ran out of GART memory! Please consider adjusting GARTSize option. *** *WARN_ONCE* File r300_ioctl.c function r300RefillCurrentDmaRegion line 629 Whops! Dont know how to evict VBOs yet. *** Put: Option "GARTSize" "64" into "Device" section of xorg.conf and it should run just fine. I admit that r300 driver shouldnt quit like that and I'm working on it. That doesn't change the fact that not adjusting GARTSize will make r300 driver run at lowered performance. You are right, I saw the backtrace and looked no further. ut2004(demo): Texture corruption and eventual lockup. The only hope on tracking down problem with your card is to be able to isolate it somehow. Apps like ut2k4 & q3 are pretty complicated beasts to debug... Good start would be to determine if the textures really get corrupted or if its a symptom of something else. Mesa demos/tests would be good for this sort of thing but anything with less than 1k of code should do. I have been using Mesa demos/tests, NeHe, and some Humus demos. Do you know of any more demos/tests? Also would you be interested in a PASS/FAILED log of these? Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] CVS HEAD segfaults on r420
Aapo Tahkola wrote: On Tue, 07 Mar 2006 21:43:22 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: Hi, Me again. Quite a few games segfault with the CVS HEAD, I tried disabling vbo (//define HW_VBOS ) but didn't change anything. nwn: Quake3: ut2003(demo): ut2004(demo): segfaults. Should work now. It is better, but still problems. nwn: Works without hw tcl, but texture corruption of curtain objects (nothing new..). Quake3: Working ut2003(demo): Menu works, game segfaults. ut2004(demo): Texture corruption and eventual lockup. ut2003 backtrace: [ 1] ./Core.so [0xa750c78a] [ 2] [0xe420] [ 3] ./Core.so(Destroy__7UObject+0x4b) [0xa74dfb5f] [ 4] ./Core.so(Destroy__7UStruct+0x3e) [0xa74924fa] [ 5] ./Core.so(Destroy__6UState+0x1e) [0xa7492ff2] [ 6] ./Core.so(Destroy__6UClass+0x162) [0xa74938a6] [ 7] ./Core.so(ConditionalDestroy__7UObject+0x3e) [0xa74dfdbe] [ 8] ./Core.so [0xa74f8277] [ 9] ./Core.so [0xa74fd4f5] [10] ./Core.so [0xa7487ee4] [11] ./Core.so [0xa752dc29] [12] /lib/ld-linux.so.2 [0xa7f762de] [13] /lib/tls/i686/cmov/libc.so.6(exit+0xc4) [0xa72df384] [14] /usr/X11R6/lib/modules/dri//r300_dri.so(r300RefillCurrentDmaRegion+0x191) [0xa24609d8] [15] /usr/X11R6/lib/modules/dri//r300_dri.so(r300AllocDmaRegion+0xd6) [0xa2460bc2] [16] /usr/X11R6/lib/modules/dri//r300_dri.so [0xa247b5b1] [17] /usr/X11R6/lib/modules/dri//r300_dri.so(r300EmitArraysVtx+0x3fa) [0xa247d08a] [18] /usr/X11R6/lib/modules/dri//r300_dri.so(r300_run_vb_render_vtxfmt_a+0x94) [0xa246d549] [19] /usr/X11R6/lib/modules/dri//r300_dri.so(radeonDrawRangeElements+0x77c) [0xa245c83d] [20] /home/runner/games/ut2003_demo/System/OpenGLDrv.so(DrawPrimitive__22FOpenGLRenderInterface14EPrimitiveType+0x373) [0xa478caeb] [21] ./Engine.so(Render__20FStaticMeshBatchListP10FSceneNodeP16FRenderInterface+0x2b2) [0xa78d0d66] [22] ./Engine.so(RenderLevel__FP15FLevelSceneNodeP16FRenderInterface+0x22df) [0xa78c3f23] [23] ./Engine.so(Render__15FLevelSceneNodeP16FRenderInterface+0x7a2) [0xa78a638a] [24] ./Engine.so(RenderLevel__FP15FLevelSceneNodeP16FRenderInterface+0x1fd3) [0xa78c3c17] [25] ./Engine.so(Render__15FLevelSceneNodeP16FRenderInterface+0x7a2) [0xa78a638a] [26] ./Engine.so(RenderLevel__FP15FLevelSceneNodeP16FRenderInterface+0x1fd3) [0xa78c3c17] [27] ./Engine.so(Render__15FLevelSceneNodeP16FRenderInterface+0x7a2) [0xa78a638a] [28] ./Engine.so(Render__16FPlayerSceneNodeP16FRenderInterface+0x330) [0xa78ab4ec] [29] ./Engine.so(Draw__11UGameEngineP9UViewportiPUcPi+0x3fe) [0xa77e308a] [30] /home/runner/games/ut2003_demo/System/SDLDrv.so(Repaint__12USDLViewporti+0x33) [0xa47b493b] [31] /home/runner/games/ut2003_demo/System/SDLDrv.so(Tick__10USDLClient+0x85) [0xa47b3365] [32] ./Engine.so(Tick__11UGameEnginef+0x31bd) [0xa77ea2e1] [33] ./ut2003-bin(SDL_SetVideoMode+0x969) [0x8051b1d] [34] ./ut2003-bin(main+0x328c) [0x8058b2c] [35] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd0) [0xa72c7eb0] [36] ./ut2003-bin(GetFullName__C7UObjectPw+0x7d) [0x80512d1] Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] CVS HEAD segfaults on r420
Hi, Me again. Quite a few games segfault with the CVS HEAD, I tried disabling vbo (//define HW_VBOS ) but didn't change anything. nwn: Quake3: ut2003(demo): ut2004(demo): segfaults. scorched3d: neverball/putt: x-moto: working. ut2003 gave me this trace: [ 1] ./Core.so [0xa74fa78a] [ 2] [0xe420] [ 3] /home/runner/games/ut2003_demo/System/OpenGLDrv.so(DrawPrimitive__22FOpenGLRenderInterface14EPrimitiveType+0x373) [0xa477aaeb] [ 4] ./Engine.so(DrawSection__FP11UStaticMeshiP9UMaterialP16FRenderInterface+0x6f) [0xa78bf9d3] [ 5] ./Engine.so(RenderStaticMesh__FP13FDynamicActorP15FLevelSceneNodePt5TList1ZP13FDynamicLightPt5TList1ZP20FProjectorRenderInfoP16FRenderInterface+0x1ea2) [0xa78c1fd2] [ 6] ./Engine.so(Render__13FDynamicActorP15FLevelSceneNodePt5TList1ZP13FDynamicLightPt5TList1ZP20FProjectorRenderInfoP16FRenderInterface+0x3a9) [0xa788cd4d] [ 7] ./Engine.so [0xa78acc81] [ 8] ./Engine.so(RenderLevel__FP15FLevelSceneNodeP16FRenderInterface+0x22be) [0xa78b1f02] [ 9] ./Engine.so(Render__15FLevelSceneNodeP16FRenderInterface+0x7a2) [0xa789438a] [10] ./Engine.so(Render__16FPlayerSceneNodeP16FRenderInterface+0x330) [0xa78994ec] [11] ./Engine.so(Draw__11UGameEngineP9UViewportiPUcPi+0x3fe) [0xa77d108a] [12] /home/runner/games/ut2003_demo/System/SDLDrv.so(Repaint__12USDLViewporti+0x33) [0xa47a293b] [13] /home/runner/games/ut2003_demo/System/SDLDrv.so(Tick__10USDLClient+0x85) [0xa47a1365] [14] ./Engine.so(Tick__11UGameEnginef+0x31bd) [0xa77d82e1] [15] ./ut2003-bin(SDL_SetVideoMode+0x969) [0x8051b1d] [16] ./ut2003-bin(main+0x328c) [0x8058b2c] [17] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd0) [0xa72b5eb0] [18] ./ut2003-bin(GetFullName__C7UObjectPw+0x7d) [0x80512d1] Rune Petersen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
Update: The "Free temps when possible" patch makes NWN lockup again. It would appear that hw tcl is very fragile on some cards. Rune Petersen Rune Petersen wrote: I made a mistake, and did not use clean Mesa source. sorry about the noise. with: int future_hw_tcl_on=1; int hw_tcl_on=1; nwn: Texture corruption (random changing garbage) on some items/doors. this corruption will bleed into other games started after nwn is closed (like Quake3). This is an improvement over the lockup I get without the patch.( it did lockup once) Quake3: No corruption. the mirror and teleport is still partly broken, but no corruption. with: int future_hw_tcl_on=0; int hw_tcl_on=0; nwn: No corruption. Quake3: map0: Texture corruption (random changing garbage). this corruption will bleed into other games started after Quake3 is closed. http://megahurts.dk/rune/stuff/shot0003.jpg Rune Petersen Aapo Tahkola wrote: On Tue, 28 Feb 2006 22:04:49 +0100 Rune Petersen <[EMAIL PROTECTED]> wrote: This also fixes the lockup I've been having in Quake3 map0. There is still corruption which spreads to include the menu, and is persistent even when restarting the game. But hay it's an improvement. Can you get a screenshot of it? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: "enable hw vertex programs by default" causes lockups on R420 - was Re: [r300] NWN - one map per reboot on R420
I doubt it since it is triggered by disabling hw tcl in the driver. Rune Petersen Felix Kühling wrote: This looks somewhat familiar. I saw this on a Radeon 7500 where AGP writes from the card to system memory did not work reliably. So uploading textures to AGP memory (through DMA) was corrupting textures. Reducing the AGP speed to 2x solved the problem on that card. The problem only occurred after a while of heavy texture usage, when it started using the AGP texture heap. After that it kept using the AGP heap and I saw texture corruption in other games too. The same card also suffered from soft lockups due to AGP status writeback that was affected by the same unreliability. I solved it locally be disabling status writeback in the kernel module before I figured out that reducing the AGP speed helped as well. YMMV. Regards, Felix Am Donnerstag, den 02.03.2006, 18:48 +0100 schrieb Rune Petersen: I didn't get the best shot, but I didn't want to risk a lockup at the time. Try looking closer at the bot. When I exited to the menu most of the background was corrupted. Rune Petersen Aapo Tahkola wrote: Quake3: map0: Texture corruption (random changing garbage). this corruption will bleed into other games started after Quake3 is closed. http://megahurts.dk/rune/stuff/shot0003.jpg I dont see anything wrong with that shot. Does it change if you look from different angle? If it changes all the time, id say you have gart overlapping with fb. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
