Re: Texture mip streaming prioritization
Sebastian Sylvan <[email protected]> Mon, 22 Jul 2013 19:34:56 -0700
| Newsgroups | gmane.games.devel.algorithms |
|---|---|
| Message-ID | <CAGZgfT6R0pY0sw3HKF=KSf2q0tqyF9LsmgH5yHvGu6LAju=TVw@mail.gmail.com> |
--===============2157280624468021651== Content-Type: multipart/alternative; boundary=f46d043be1ba80446804e224a328 --f46d043be1ba80446804e224a328 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 22, 2013 at 7:24 PM, Sebastian Sylvan < [email protected]> wrote: > > > On Mon, Jul 22, 2013 at 5:21 PM, Josh Green <[email protected]> wrote: > >> >> Unfortunately the above algorithm looks like it'd be very serial, and >> involve a bunch of sorts... But I think it might acheive good results? >> > > Seems reasonable. You should of course try to keep your texture requests > in a priority queue instead of re-sorting in each iteration, and use > "adjust key"/"decrease key" whenever you decide to drop a MIP level for a > key. There are heap implementation where this operation is O(1) (e.g. > Fibonacci heap), so it's at least possible to be efficient (in practice, > depending on the number of textures, a straight binary heap a la STL may be > faster due to being less complicated). > > Also, it's worth considering your expectation here. If you intend to keep enough memory for textures that you'll "almost never" have to turn down a MIP-loading request, you don't really have to over-think this too much. Simply loading the lowest-resolution MIP always (taking object visibility into account) will do a decent job - it's sort of like having a global resolution clamp and just lowering it until stuff fits in memory, which won't be optimal, but tends to behave consistently and predictably. > -- > Sebastian Sylvan > --f46d043be1ba80446804e224a328 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quo= te">On Mon, Jul 22, 2013 at 7:24 PM, Sebastian Sylvan <span dir=3D"ltr"><= ;<a href=3D"mailto:[email protected]" target=3D"_blank">sebastian.= [email protected]</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding= -left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l= eft-style:solid"><div dir=3D"ltr"><div class=3D"gmail_extra"><br><br></div>= <div class=3D"gmail_quote"> <div class=3D"im">On Mon, Jul 22, 2013 at 5:21 PM, Josh Green <span dir=3D"= ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">inbilla@gma= il.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding= -left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l= eft-style:solid"><div dir=3D"ltr"><div class=3D"gmail_extra"><br>Unfortunat= ely the above algorithm looks like it'd be very serial, and involve a b= unch of sorts... But I think it might acheive good results?<br> </div></div></blockquote><div>=A0</div></div><div>Seems reasonable. You sho= uld of course try to keep your texture requests in a priority queue instead= of re-sorting in each iteration, and use "adjust key"/"decr= ease key"=A0whenever you decide to drop a MIP level for a key. There a= re heap implementation where this operation is O(1) (e.g. Fibonacci heap), = so it's at least possible to be efficient (in practice, depending on th= e number of textures, a straight binary heap a la STL may be faster due to = being less complicated).</div> <div>=A0<br></div></div></div></blockquote><div>=A0</div><div>Also, it'= s worth considering your expectation here. If you intend to keep enough mem= ory for textures that you'll "almost never" have to turn down= a MIP-loading request, you don't really have to over-think this too mu= ch. Simply loading the lowest-resolution MIP always (taking object visibili= ty into account) will do a decent job=A0- it's sort of like having a gl= obal resolution clamp and just lowering it until stuff fits in memory, whic= h won't be optimal, but tends to behave consistently and predictably.</= div> <div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-widt= h:1px;border-left-style:solid"><div dir=3D"ltr"><div class=3D"gmail_quote">= <div>-- <br> Sebastian Sylvan </div></div></div></blockquote></div></div></div> --f46d043be1ba80446804e224a328-- --===============2157280624468021651== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk --===============2157280624468021651== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ GDAlgorithms-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list --===============2157280624468021651==--