Re: [Mesa-dev] Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)
On Tue, Feb 4, 2020 at 9:42 PM Eric Anholt wrote: > > On Tue, Feb 4, 2020 at 7:54 PM Rob Clark wrote: > > > > it seems like BE vs formats (vs llvm) is a constant nightmare, because > > there are essentially no mesa dev's working on BE devices (ie. issues > > are generally discovered long after the fact when mesa changes finally > > propagate into into enterprise distros).. but with gitlab we have now > > a sane scheme to plug in more decentralized CI runners if someone > > wants to step up and figure out how get some BE test coverage into > > CI.. just saying.. ;-) > > We don't even need runners: > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3643 oh, very nice! BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)
On Tue, Feb 4, 2020 at 7:54 PM Rob Clark wrote: > > it seems like BE vs formats (vs llvm) is a constant nightmare, because > there are essentially no mesa dev's working on BE devices (ie. issues > are generally discovered long after the fact when mesa changes finally > propagate into into enterprise distros).. but with gitlab we have now > a sane scheme to plug in more decentralized CI runners if someone > wants to step up and figure out how get some BE test coverage into > CI.. just saying.. ;-) We don't even need runners: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3643 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)
it seems like BE vs formats (vs llvm) is a constant nightmare, because there are essentially no mesa dev's working on BE devices (ie. issues are generally discovered long after the fact when mesa changes finally propagate into into enterprise distros).. but with gitlab we have now a sane scheme to plug in more decentralized CI runners if someone wants to step up and figure out how get some BE test coverage into CI.. just saying.. ;-) BR, -R On Tue, Feb 4, 2020 at 4:14 PM Stefan Dirsch wrote: > > Hi > > Unfortunately rendering of glxgears on S/390 architecture (64bit, BigEndian) > is broken on Mesa 19.3.3. I bisected the issue and the git commit id d17ff2f7, > which came in between 19.2 and 19.3, caused the issue. After reverting this > commit, glxgears rendering is working again. I openend issu#2472 for this. > > https://gitlab.freedesktop.org/mesa/mesa/issues/2472 > > Thanks, > Stefan > > Public Key available > -- > Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH > Tel: 0911-740 53 0Maxfeldstraße 5 > FAX: 0911-740 53 479 D-90409 Nürnberg > http://www.suse.deGermany > > (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Broken rendering of glxgears on S/390 architecture (64bit, BigEndian)
Hi Unfortunately rendering of glxgears on S/390 architecture (64bit, BigEndian) is broken on Mesa 19.3.3. I bisected the issue and the git commit id d17ff2f7, which came in between 19.2 and 19.3, caused the issue. After reverting this commit, glxgears rendering is working again. I openend issu#2472 for this. https://gitlab.freedesktop.org/mesa/mesa/issues/2472 Thanks, Stefan Public Key available -- Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.deGermany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
Michel Dänzer writes: >> actual_period = n * r - ε > > Is that still an issue if the (minimal) length of a vertical blanking > period is subtracted from the computed period? What you're doing is defining a 'window' of times which match the desired frame -- any time within 'length of vertical blanking period' of the actual top of frame matches that frame. I'm simply making that window as large as possible by using 'half the frame time' instead of 'length of vertical blanking period'. > FWIW, one thing making "not before" semantics attractive is that > they're easy to achieve in the kernel: It can just make sure the page > flip isn't programmed to hardware before the target time. Yup, offering only 'not before' makes it easy to implement in the kernel, but very difficult for the application to get the right result. For fixed refresh rate monitors, converting from 'nearest to time T' to 'not before frame count F' conversion can be done by rounding T/rate to F and then using that to program the hardware using 'not before' semantics. For variable refresh rate monitors, the computation will be slightly more complicated as it may involve some multiple of a nominal frame rate plus some stretching of the final frame. > PresentOptionUST has never been functional, so there can't be any > clients relying on specific semantics (other than being a no-op :) for > it. Therefore, we could still change its semantics before making it > functional, FWIW. Oops. Someone should fix that :-) -- -keith signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
Michel Dänzer writes: > Hmm, I didn't fully realize this in my reading of the draft, thanks > Matias for pointing it out! > > That the timing of frame N+1 has to be specified when submitting frame > N for presentation is odd to me TBH. While I can imagine this might be > suitable for some apps such as video players, I'm skeptical about game > engines. They would need to calculate frame time budget and choose > simulation time for frame N+1 before submitting frame N for > presentation. Is that really how game engines (want to) work? It's not asking the application to figure this out much earlier -- the application needs to know the target time for the next frame before starting any of the frame computations, and that happens right after submitting the previous frame. The goal here is to provide the display system the timing information as soon as the application knows it, in case that helps the backend work better. > Instead, have you considered allowing the GOOGLE_display_timing > desiredPresentTime to be specified as a relative time, measured from > when the previous image of the swapchain was actually presented, > instead of as an absolute time? Could something like that also address > the motivation for VK_MESA_present_period? Yes, that would avoid the display problem. -- -keith signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2020-02-03 8:48 p.m., Keith Packard wrote: > Michel Dänzer writes: > >> Instead of rounding to the nearest upcoming frame, should it >> round to the earliest frame after the specified period has >> passed? As written, it seems to contradict the next paragraph >> below: > > Sorry for the poor wording; let me describe what I want informally > here. > > For nanosecond periods to be easy to use on fixed-refresh-rate > monitors, I want the näive computation to "just work". For a given > refresh period, 'r', I want to select a period of 'n' frames > using: > > computed_period = n * r > > Because of clock skew and rounding problems, it's quite possible > that the period could easily end up being just slightly smaller > than that: > > actual_period = n * r - ε Is that still an issue if the (minimal) length of a vertical blanking period is subtracted from the computed period? >> (I'm not ruling out that rounding to nearest might be better, but >> there should be a rationale for it, which also justifies being >> inconsistent with GOOGLE_display_timing) > > Yes, this is intentionally inconsistent with > GOOGLE_display_timing, which I believe is hard to use correctly. > > By specifying not before semantics, GOOGLE_display_timing requires > applications compute a fake time guaranteed to be not after the > actual target frame time. This really messes things up when you > might have variable refresh rate monitors. I see. Same question as above. FWIW, one thing making "not before" semantics attractive is that they're easy to achieve in the kernel: It can just make sure the page flip isn't programmed to hardware before the target time. > I just went and read the time-based stuff from the X Present > extension. That uses 'nearest' semantics too, when supported by > the driver. When not supported, the server gets to do whatever it > likes (oops!). PresentOptionUST has never been functional, so there can't be any clients relying on specific semantics (other than being a no-op :) for it. Therefore, we could still change its semantics before making it functional, FWIW. >> P.S. It would be good to create a WIP merge request for this in >> the main Mesa project, to have a central place for gathering >> feedback and tracking progress. > > Done, thanks for the suggestion. Thanks. For the record, that's https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3682 . - -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -BEGIN PGP SIGNATURE- iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXjlKiwAKCRBaga+Oatuy ALsMAKCRxgfQa1zDXrLZ6iUnkl1+PtHqIQCgrFiNxQmRMye9B0t3RRXtr3dGjiY= =lLMw -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Playing with display timing -- VK_MESA_present_period
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2020-02-03 9:16 p.m., Keith Packard wrote: > "Matias N. Goldberg" writes: > >> I read your article. > > Thanks! > >> What I feel are missing are just minor pesky details: > > Yes, it's definitely a rough draft at best. Figuring out the right > words to make it do precisely what we want is hard, and I'm hoping > we can first figure out what we want, then figure out how to say > that precisely. > >> 1. Written as is, the frame being submitted is rounded up to >> display timing, delaying *future* frames.But there is no way to >> delay the *currently displaying frame* (i.e. the 'previous' >> frame). > > Correct. The period provided controls how long the specified frame > will be shown to the user (at a minimum). Future frames will be > delayed by at least that long. > >> Right now if frame N was submitted without VkPresentTimeMESA but >> frame N+1 is, then frame N+1 will be presented to screen ASAP. > > Correct. > >> What I'm saying is that if frame N was submitted without >> VkPresentTimeMESA, then at frame N+1 I should be able to tell >> 'keep frame N displayed for at least P nanoseconds since it was >> displayed, and *then* present frame N+1, which is the frame I am >> now submitting' > > That's not what this extension does; if you wanted frame 'N' to be > displayed for 'P' nanoseconds, then you would specify 'P' when > queuing frame 'N'. Hmm, I didn't fully realize this in my reading of the draft, thanks Matias for pointing it out! That the timing of frame N+1 has to be specified when submitting frame N for presentation is odd to me TBH. While I can imagine this might be suitable for some apps such as video players, I'm skeptical about game engines. They would need to calculate frame time budget and choose simulation time for frame N+1 before submitting frame N for presentation. Is that really how game engines (want to) work? Instead, have you considered allowing the GOOGLE_display_timing desiredPresentTime to be specified as a relative time, measured from when the previous image of the swapchain was actually presented, instead of as an absolute time? Could something like that also address the motivation for VK_MESA_present_period? - -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer -BEGIN PGP SIGNATURE- iF0EARECAB0WIQSwn681vpFFIZgJURRaga+OatuyAAUCXjlKBwAKCRBaga+Oatuy ADDxAJ49XUxG6tnAWuC/br12sORqQSBUyACgk7h1jf9fjjtMYvrkIfUnkcHwkqg= =m2sK -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
