Dave Airlie wrote: > On 5/9/07, Thomas Hellström <[EMAIL PROTECTED]> wrote: >> Dave Airlie wrote: >>>> I'll try it out as soon as there is time. >>> I've just tested glxgears and a few mesa tests on it and it seems to >>> be working fine.... >>> >>> We should probably think about pulling this over into the DRM sooner >>> rather than later, there are also some changes to the DDX >>> i830_driver.c compat code to deal with... >>> >>> >> Yup. I've attached a patch (against the cleanup branch) with things I >> think may be needed. >> >> 1) 64-bit reordering. 64-bit scalars, structs and unions should probably >> be 64-bit aligned in parent structs. I had to insert padding in two >> cases, but this probably needs to be double-checked. >> 2) A "magic" member in the init ioctl. Checking this allows for verbose >> and friendly failure of code that uses the old interface. >> 3) Init major / minor versioning of the memory manager interface in case >> we need changes in the future. >> 4) expand_pads are 64-bit following Jesse Barnes recommendations. >> 5) The info_req carries a fence class for validation for a particular >> command submission mechanism. >> 6) The info_rep arg carries tile_strides and tile_info. >> The argument tile_strides is ((actual_tile_stride) << 16) | >> (desired_tile_stride)) > > Any reason you don't just separate actual_tile_stride and > desired_tile_stride to 2xunsigned int? not sure why merging them > really gives us anything... > >> The argument tile_info is driver-specific. (Could be tile width, >> x-major, y-major etc.) >> >> Finally, should we perhaps allow for 64-bit buffer object flags / mask >> at this point? >> > > Possibly, the rest all seems like good ideas, I know we hit the 64-bit > alignment on nouveau so good to get it fixed early.... > >> I haven't done any user-space or kernel coding for this yet. >> Just want to know what you think. > > Well I'll be "offline" for a few weeks so I'll get the odd chance to > read mail but no development...
If kernel-space relocations are on the agenda, I should flag up one issue that we are currently pretending doesn't really exist, namely that not all relocations apply to the main dma/batch buffer. More precisely, state structures stored for use and reuse outside of the command stream can contain pointers to things like draw surfaces and textures. Having pointers in those structs limits their ability to be reused as intended, but there's not much to do about that. The important thing to note is that they *do* need to fixed up with relocation information at the same time as the batchbuffer. Or in other words, that while the batch buffer may be special, it is not unique - there are a (small) number of buffers that will require the same treatment. Keith ------------------------------------------------------------------------- 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/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
