(Pardon my top-posting) Gary,
Re-unification isn't that hard, but there are some involved steps and a moderate amount of work. - Firstly, note that i915tex is based on the new texture memory manager. i965 is coded to a similar interface (bufmgr_fake.c) that we created as a stepping stone during development of the memory manager. As a very first step, the i965 code will have to be ported to the new memory manager. - While it would be possible to port i965 to the memory manager and then combine the code bases, it might actually be easier to do it in a single step - pull the brw_*.[ch] files into i915tex and convert them as you go. - Note however that there is some code in the i915tex/intel*.[ch] files that is inapplicable to i965 - specifically all the stuff relating to triangles and vertices. This should be pushed down into some lower level that abstracts i830 and i915 but isn't included in i965. - Also note that the driver would become massive once this is completed. Having unified it it may be tempting to split it up again, at least into a few directories under i915tex/. - Some changes to the intel_* files in i965 would have to be pulled back into i915 - specifically dealing with tiling support in the 2d engine - the blit command packets changed slightly to accomodate this. - The i965-style state upload mechanism (upload whole structs, not a bunch of #defined DWORDS) may not play so nicely with the syntax used in i915tex to mark up buffer relocations for the kernel module to patch. This will probably require a little head scratching to come up with a non-ugly syntax. - There will probably be a need to modify the brw_* files to accomodate the new functionality in i915tex/, especially FBOs seem to reach deeply into the driver. - There is some code and specific optimizations in the brw* files to make the faked memory manager work well that will not apply to the real ttm manager. These need to be identified and removed. - It may make sense to wait until the VBO rework is done and merged. But then, there will always be something going on, so maybe not. Keith ----- Original Message ---- From: Gary Wong <[EMAIL PROTECTED]> To: Keith Whitwell <[EMAIL PROTECTED]> Cc: [email protected]; [EMAIL PROTECTED] Sent: Wednesday, November 29, 2006 1:57:11 PM Subject: Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk) On Wed, Nov 29, 2006 at 01:57:00AM -0800, Keith Whitwell wrote: > This code looks like a re-implementation of the existing > do_texture_copypixels() from the i915 driver. It seems to do a > similiar but not-quite-the-same operation but by a divergent set of > code changes. Oops. > Is there any reason not to have just ported the changes over from > i915tex? No (except that I wasn't aware of the capability in that driver). It seemed to me that the closest thing to CopyPixels through the i965 3D pipeline was the i965 meta_ops Clear, so I used a similar approach to that (except applying the per-fragment operations from the GL state, and doing the texture-from-frame-buffer stuff). > I'd strongly prefer to keep the two codebases as similar > as possible - as you can see in i915tex/ there is an increasing > amount of non-chipset dependent code (all the intel_* files) as we > add more advanced features like FBO's etc. It would be good to keep > open the possibility of reunifying the codebases once i965 has > caught up with the memory manager changes, etc. I agree. How much work is involved in reunification, and which parts need to be reconciled? And what should I do -- I presume the best short-term approach is for me to submit patches aligning my previous CopyPixels with the i915tex version (i.e. expressed in terms of meta_import_pixel_state, meta_tex_rect_source, etc.)? Cheers, Gary. -- Gary Wong [EMAIL PROTECTED] http://cs-people.bu.edu/gtw/ ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
