On 11/2/06, Keith Whitwell <[EMAIL PROTECTED]> wrote: > Jerome Glisse 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 ? > > I've fixed the initial problem, but hit another one related to the above > -- namely that the tnl/ module currently *does* have size limits... > > I'd like to lift those limits by just reallocating memory as required, > but it may be more cache friendly to chop large render requests into chunks. > > Keith >
I still see the segfault here, (line 129 this time). I also think it would be better to split big request into smaller chunk but that might be time consuming as you would have to go throught indices array to see how you can split. For the radeon driver, it seems the limit was introduced with no reason at least from what i did understand on irc :). I guess that moving to ttm would provide us with a better and cleaner memory handling. best, Jerome Glisse ------------------------------------------------------------------------- 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 _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
