On 11/18/06, Aapo Tahkola <[EMAIL PROTECTED]> wrote: > >On 11/2/06, Keith Whitwell <[EMAIL PROTECTED]> wrote: > >> Jerome Glisse wrote: > >> > On 11/2/06, Keith Whitwell <[EMAIL PROTECTED]> wrote: > >> >> Keith Whitwell wrote: > >> >>> OK, the first round of work on the VBO branch seems to have gone > >> >>> quite smoothly. It'd be great if a couple of the key r200/r300 > >> >>> people could check the branch out and verify whether I've broken > >> >>> those drivers or not. > >> >>> > >> >>> It'd be particularly interesting to see if someone (Aapo?) can > >> >>> take a look at the disabled vtxfmt_a code and see if it is easy > >> >>> to port that over to the new archiecture. I've got a feeling it > >> >>> should be fairly straight-forward, as it's simple to fallback to > >> >>> the tnl/ module for any unexpected or non-handled situations. > >> >> I took a quick look at this and it seems doable. I sketched out a > >> >> simplified approach that just attempts to hook the existing code > >> >> into a _radeon_draw_prims() callback. It looks like it might > >> >> work, but it would be better to try for a deeper integration. > >> >> > >> >> I'm pretty bullish about the vbo code & would like to see an early > >> >> merge, so please take a look at this. > >> >> > >> >> Keith > >> >> > >> >> > >> > > >> > I investigated recently a bug (8348) and we don't check if in > >> > DrawRangeElement max - min won't requiert a memory area > >> > bigger than what we can have with DMA (which if i am right > >> > can't be bigger than RADEON_BUFFER_SIZE * 16). Do you see > >> > any easy they to work around this. I will try to test VBO branch > >> > today and complete your change. > >> > >> OK. I've got a couple of bugs to fix yet, and I've still got to try > >> running glean, etc, so it'll be a couple of days before anything > >> happens. But it would be good to have the r200/r300 drivers up to > >> speed prior to a merge. > >> > >> Keith > >> > > > >I have tried to play a bit with that but i segfault in vbo_exec_array.c > >line 127 with varray in progs/redbook know bug or something from my > >side ? > > > >Btw i have thinked a bit more about the need to update max-min vertices > >in drawelements and drawrangeelements and i don't see an easy way to > >split the rendering as we have to go throught all indices and make sure > >that (max-min)*primsize never need more memory than what dma alloc > >can give us. Don't you have similar problem with intel ? > > You cannot split the commands nor remove copying of elts. > r300 vertex cache is incorrectly configured and as a result of that, > accessing elts twice (by the gpu) will cause r300 to crash immediately. > You must upload new indices for every IDX packet. > > While this sucks it would suck even more if IDX packets wouldn't work > at all. >
I was thinking of accumulating vertex in a buffer and submit then so we wouldn't exactly split the IDX packet but send a stream of vertex. Anyway i think this should be handled somewhere in mesa because all driver might suffer from that, even with new memory handler if your gart size doesn't fit the vertex and index buffer you end up in bad situation. best, Jerome Glisse ------------------------------------------------------------------------- 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 _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
