Created attachment 15739 [details] progs/vp-tris patch, to get examples working Looks like vertex program has some problems with more than 7 inputs. The following vp gives just some random garbage (with patched vp-tris, see attachment) !!ARBvp1.0 MOV result.position, vertex.position; MOV result.color.primary, vertex.color.primary; MOV result.color.secondary, vertex.color.secondary; MOV result.texcoord[0], vertex.texcoord[0]; MOV result.texcoord[1], vertex.texcoord[1]; MOV result.texcoord[2], vertex.texcoord[2]; MOV result.texcoord[3], vertex.texcoord[3]; MOV result.color, vertex.texcoord[4]; END But this one works fine (one big yellow triangle) !!ARBvp1.0 MOV result.position, vertex.position; MOV result.color.primary, vertex.color.primary; MOV result.color.secondary, vertex.color.secondary; MOV result.texcoord[0], vertex.texcoord[1]; MOV result.texcoord[1], vertex.texcoord[1]; MOV result.texcoord[2], vertex.texcoord[2]; MOV result.texcoord[3], vertex.texcoord[3]; MOV result.color, vertex.texcoord[4]; END I looked at the aos stuff, input route, input cntl but everything looks fine. According to the r500 doc (5.2.3.9) 3D_LOAD_VBPNTR, accepts 12 inputs, so it doesn't look like a hw limitation. Strange is VAP_VTX_AOS_ADDR has a limit of 16 inputs?
I suspect we may need to set up VAP_CNTL differently for more than 7 inputs. See sections 6.4.2 and 6.4.7
You're right. Setting PVS_NUM_SLOTS to 9 (currently 10) fixes the problem. Currently we're setting VAP_CNTL globally, looks like we should do it per vertex program. 6.4.2 nicely describes how to set up VAP_CNTL, but I'm having some trouble understanding it. I'm not sure what POR means or 'vertex data has been packed'. I'm also not sure about {INPUT|OUTPUT|TEMP}_VTX_MEM_SIZE.
(In reply to comment #2) > You're right. > Setting PVS_NUM_SLOTS to 9 (currently 10) fixes the problem. > Currently we're setting VAP_CNTL globally, looks like we should do it per > vertex program. > 6.4.2 nicely describes how to set up VAP_CNTL, but I'm having some trouble > understanding it. I'm not sure what POR means or 'vertex data has been packed'. > I'm also not sure about {INPUT|OUTPUT|TEMP}_VTX_MEM_SIZE. > 6.4.7, 6.5.1 and 6.5.2 have some additional information. {INPUT|OUTPUT|TEMP}_VTX_MEM_SIZE refers to the size of your vertex stream(s) (DWORDs IIRC). VAP_PROG_STREAM_CNTL_0-7 and VAP_PROG_STREAM_CNTL_EXT_0-7 describe how the elements are treated. Unfortunately, I'm not sure what POR stands for.
> 6.4.7, 6.5.1 and 6.5.2 have some additional information. > {INPUT|OUTPUT|TEMP}_VTX_MEM_SIZE refers to the size of your vertex stream(s) > (DWORDs IIRC). VAP_PROG_STREAM_CNTL_0-7 and VAP_PROG_STREAM_CNTL_EXT_0-7 > describe how the elements are treated. Unfortunately, I'm not sure what POR > stands for. The doc is a bit misleading, but I think I got it. according to 6.5.2 {INPUT|OUTPUT|TEMP}_VTX_MEM_SIZE = 72 (for r300) {INPUT|OUTPUT|TEMP}_VTX_MEM_SIZE = 128 (for r500) In this case here 8 inputs => 72/8 => PVS_NUM_SLOTS = 9. qed :) According to 6.4.2 MAX_CNTRLS is 6, but 6.5.2 says 5. fglrx usess 6, so it looks like there's a typo in 6.5.2. The docs (both r500v1.3 and r300) also say to set VF_MAX_VTF_NUM in VAP_CNTL to 12=0xc. But this value crashes my card. fglrx sets it to 0xb, without crash. So for this value the doc is wrong. I'll try an implementation.
(In reply to comment #4) > > The docs (both r500v1.3 and r300) also say to set VF_MAX_VTF_NUM in VAP_CNTL to > 12=0xc. But this value crashes my card. fglrx sets it to 0xb, without crash. So > for this value the doc is wrong. looks like that field is (vertices - 1), so 11 (0xb) would mean 12 vertices would be used. Still it's not real clear.
(In reply to comment #5) > (In reply to comment #4) > > > > The docs (both r500v1.3 and r300) also say to set VF_MAX_VTF_NUM in VAP_CNTL to > > 12=0xc. But this value crashes my card. fglrx sets it to 0xb, without crash. So > > for this value the doc is wrong. > > looks like that field is (vertices - 1), so 11 (0xb) would mean 12 vertices > would be used. Still it's not real clear. > My fault, doc is correct. 12 works fine, I mixed up some bits.
Created attachment 15793 [details] [review] Set correct VAP_CNTL per vertex program. not sure about: - correct implemented state flush before VAP_CNTL - naming convention in r300_reg.h - delete VAP_CNTL in r300ResetHwState - whether VAP_CNTL is needed in r300EmitClearState
I've pushed the patch to master, with a couple of minor clean ups. Thanks for writing this, VAP_CNTL was always one of the things that looked really nasty. It's a lot better now. :-)
I've pushed an updated version of this patch with updates for r5xx to the r500-support branch as well.
Mass version move, cvs -> git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.