Whoops, sent to the wrong list... >>I think we're in complete agreement on the two big things needed: >> >>1. Don't require Mesa core to store a copy of the texture. >> >>2. Implement glTexSubImage functions in the device driver. >> >> >>One question is this: how early in the glTexImage (or glTexSubImage) >>function should the corresponding device driver function be called? >> >>If it's called early, then the driver will have to check quite a bit >>of state and perhaps do a lot of work (pixel scale, bias, lookup, >>conversion from all possible formats and types, pixel unpacking ,etc) >> >>That's a lot of state examination but in most cases the image is in >>a simple format and pixel transfer ops aren't enabled. >> >>If the driver function is called later (after pixel transfer, type >>conversion and unpacking), then the driver's function can be much >>simpler. >> >>Here's one idea: have a TexImage2D() driver function which is called >>early and a SimpleTexImage2D() function which is called later and >>passes data in a simplified format. The driver could implement >>either function, depending on how much the driver writer wanted to do. >> >>Or, if a single TexImage2D() function existed that returned true/false >>to indicate success/failure, it could be called at several points >>inside glTexImage2D() until it finally worked or we fell all the way >>onto the software path. > >That would be fine, because all drivers would be required to handle the >canonical mesa internal formats, so there would only be two possible calls: > as the user presented it, or canonical form after mesa internalizes it. > >You would probably want to provide some convenience flags to show all the >weird scale/bias/etc options if a driver really wanted to implement those >(or had hardware to do it), but I expect drivers would only support >in-place downloads when the user presented it in canonical (or nearly so -- >rgb in 32 bits) form anyway. > >John Carmack > > > >_______________________________________________ >glx-dev mailing list - [EMAIL PROTECTED] >http://lists.openprojects.net/mailman/listinfo/glx-dev > _______________________________________________ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
