Tommy Schultz Lassen wrote: > Roland Scheidegger skrev: >> Tommy Schultz Lassen wrote: >> >>> Oliver McFadden skrev: >>> >>>> Hi, >>>> >>>> I need to understand and extend these functions because >>>> r300_ioctl.c:r300EmitClearState writes hard-coded values to >>>> these registers, and this should be replaced with calls to >>>> (extended) t_vir0 and t_vir1. These probably need to be >>>> renamed, too. >>>> >>>> >>>> >>> Hi, >>> >>> I have for some time been playing with the R300 driver to fix a >>> problem wit Newervinter Nights. >>> >>> While looking at that problem i made a patch to remove "struct >>> radeon_vertex_buffer". The problem with Newervinter is that it >>> uses VERT_ATTRIB_WEIGHT when i enable that. Colors in the regions >>> where VERT_ATTRIB_WEIGHT is used gets way of. Anyone have any >>> insights on that? >>> >>> In the attached patch there is also a cleanup of t_vir0. I hop >>> that helps a bit. >>> >> Not sure what nwn is doing, it works fine with other chips, and >> chances are it wouldn't if it would really use VERT_ATTRIB_WEIGHT. >> Anything special about the areas where that's happening? There are >> workarounds in mesa core (and r200 driver) to make World of >> Warcraft work better, which also (errorneously) uses that, but that >> workaround is limited to fixing up vertex programs (which nwn >> usually doesn't use, except if some nv extensions are present >> IIRC), if an app tries to submit for instance a vertex weight >> array, it will not work. I don't quite understand where that attrib >> shows up in your case, but something seems fishy here... >> >> Roland >> > Yes something seems fishy. The "InputsRead" for the Vertex Shader is > (VERT_ATTRIB_POS, VERT_ATTRIB_WEIGHT, VERT_ATTRIB_NORMAL, > VERT_ATTRIB_COLOR1, VERT_RESULT_TEX0). > > I have been looking at what the r200 driver dos. It uses fixed values > for vp->inputs (12 for VART_ATTRIB_WEIGHT). It uses fixed mapping for "traditional" attributes (while non-fixed for generic ones). Part of the reason is that this is the same what's used for non-shader mode, the other part of the reason is that you can't do arbitrary input routing on that chip (restrictions wrt number of components / data type depending on the input) - though actually it may be possible similar to r300 (someone hinted the chip may feature the same VAP_INPUT_ROUTE regs as r300).
> In the r300 inputs are set dynamically. from 0 and up. I tried to set > it differently. It gave me some interesting results. > > 0,1,2,13,14,15,26,27,28 Gives the result as i see now. 3,4 > Gives some more dynamic light effects. > 6,7,8,9,10,11,18,19,20,21,22,23,24 All vertex'es with WEIGHT > disaperes. 16,17 I see the wrong colors and no details. > > I don't quiet know what that means. I don't know much about that driver, but I think it shouldn't matter what inputs you use, as long as you set up routing information (and the access in the vertex program) correctly. > I have tried to disable all extensions from: const struct > dri_extension card_extensions[] but that docent change anything. Strange. Maybe it would be worth figuring out where that InputsRead is coming from, if it's a mesa-generated vertex program it should be impossible, otherwise might be worth to dump the program and have a look at it. Roland ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
