Hi Dnia 20-01-2005, czw o godzinie 16:50 -0800, Mike Mestnik napisał(a): > --- Jacek Rosik <[EMAIL PROTECTED]> wrote: > > > Dnia 20-01-2005, czw o godzinie 13:59 -0500, Michel Dnzer napisa(a): > > > On Thu, 2005-01-20 at 12:49 +0100, Jacek Rosik wrote: > > > > > > > > Radeon and R200 drivers report GL_MAX_VIEWPORT_DIMS=<4096, 4096>, > > but I > > > > think that hardware can maximally suport <2048, 2048>. Anyway I > > don't > > > > think current drivers don't even support <1, 1> if window will be > > placed > > > > further from top left corner than 2048 in any direction. > > > > > > Yes, this has been discussed a couple of times before. > > > > > > > So, I was trying to fix this problem by changing offset used by > > > > accelerator to point to top left corner of the viewport. > > > > > > This will likely be a useful optimization, but the general solution is > > > probably needed as well: Split cliprects on boundaries of multiples of > > > 2048 and iterate over the resulting 'cliprect regions' with the > > viewport > > > state changing as necessary for every iteration. > > > > That's exactly what I'm trying to achieve as my end result :). Changing > > offset if first point of my plan, when I have this working I can move on > > to splitting cliprects and iterating over the resulting groups. As I > > understand it now i need to change offset for each such group. > > > I was able to change the offset, but I got stuck with then having to > translate all the drawing back into place. What would happen was the > gears would be moved right and no longer be centered. I'd love to > continue once I see a solution to this problem.
I think I got that. I generally use two sets of cliprects and two offsets. One of them is translated used by 3d and everything except 3d uses old offset and cliprects ( at least i hope so ;). Next step would be to split those 3d cliprects into groups and multiplex, and that will require a lot more effort. > > Anyway I don't think that these groups would be multiple of 2048. I > > can't set offset to any value, it must be aligned as i wrote before. So > > this would be something around 2040. Or, am I missing something? > > > 1024 would be good(1/2) but 2/3 will sometimes get better results. 3/4 > since it's (1536)11000000000b or 0x600 would probly be the best. Trying > to break it up into larger/smaller fractions will result in a sliver(5 x > Y) being rendered too, I don't see why this would be good. Keep in mind > that triangles that cross these lines might need to be emited twice. Actually I was thinking about always emitting everything, at least in first version. When we have that working we can move on and try to emit only those triangles which intersect with given group. But this may get quite complicated, and I'm not quite sure it's worth trying. > Only testing can tell thought, I'd be happy to help here. I'm hoping to resolve remaining issues and clean it a little bit by Monday. Best, -- Jacek Rosik <[EMAIL PROTECTED]> ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
