Re: XDC 2023: Registration & Call for Proposals now open!
On 4/17/23 13:41, Samuel Iglesias Gonsálvez wrote: Hello! Registration & Call for Proposals are now open for XDC 2023, which will take place on October 17-19, 2023. Forgot to mention, it will be in A Coruña, Spain :) https://xdc2023.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to register via the XDC website. https://indico.freedesktop.org/event/4/registrations/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2023. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/4/abstracts/ The deadline for submissions is Monday, 17 July 2023 (23:59 CEST) Check out our Reimbursement Policy to accept speaker expenses: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to siglesias AT igalia.com, adding on Cc the X.org board (board at foundation.x.org). And please keep in mind, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best, Sam OpenPGP_0x7FF4BA32F17DC343.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
XDC 2023: Registration & Call for Proposals now open!
Hello! Registration & Call for Proposals are now open for XDC 2023, which will take place on October 17-19, 2023. https://xdc2023.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to register via the XDC website. https://indico.freedesktop.org/event/4/registrations/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2023. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/4/abstracts/ The deadline for submissions is Monday, 17 July 2023 (23:59 CEST) Check out our Reimbursement Policy to accept speaker expenses: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to siglesias AT igalia.com, adding on Cc the X.org board (board at foundation.x.org). And please keep in mind, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best, Sam OpenPGP_0x7FF4BA32F17DC343.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[Mesa-dev] Have you attended XDC 2021? Give us your feedback!
Hi, First of all, thanks organizers for such a great conference. It was smooth and, although there were some issues as it is usual in any conference, they were fixed promptly :-) I would like also to thank all of you for attending and participating either via submitting talks, watching them or joining the hallway track in IRC :-D Without you this conference won't make sense. Now it is time to gather feedback from you :-D * Do you have any comment on how was XDC 2021? - For example, have you tried the new streaming service (https://streaming.media.ccc.de/xdc2021)? Was it fine? * Do you think we can improve on something for future events? * What did you like most/least about the conference? You can reply privately to me if you wish. We will share all the gathered feedback among organizers and the X.Org Foundation board. Now that I got your attention... Did you like XDC 2021? What about organizing XDC 2023 (likely in Europe)? We know this is a decision that takes time (trigger internal discussion, looking for volunteers, budget, and a venue suitable for the event, etc). Therefore, we encourage potential interested parties to start the internal discussions now, so any question they have can be answered before we open the call for proposals for XDC 2023 next year. Please read [0] and feel free to contact me or the board for more info if needed. Thanks, Sam [0] https://www.x.org/wiki/Events/RFP/ signature.asc Description: This is a digitally signed message part
Re: [Mesa-dev] Requests For Proposals for hosting XDC 2022 are now open
Deadline is at the end of this month. Do not forget to submit your XDC 2022 hosting proposal! Sam On Thu, 2021-07-29 at 21:01 +0200, Samuel Iglesias Gonsálvez wrote: > Remember before enjoying your holiday that the deadline for XDC 2022 > proposals is *September 1st, 2021* :-) > > Feel free to submit your proposal before, so we can give you early > feedback on it! > > Sam > > On Thu, 2021-07-01 at 18:14 +0200, Samuel Iglesias Gonsálvez wrote: > > This is a reminder that the call for proposals for hosting XDC 2022 > > period finishes in two months. > > > > Be sure to prepare your submission before you leave on holiday! > > > > Sam > > > > On Thu, 2021-05-20 at 12:15 +0200, Samuel Iglesias Gonsálvez wrote: > > > Hello everyone! > > > > > > The X.org board is soliciting proposals to host XDC in 2022. > > > Since > > > XDC 2021 is being held in Europe this year (although virtually), > > > we've > > > decided to host in North America. However, the board is open to > > > other > > > locations, especially if there's an interesting co-location with > > > another conference. > > > > > > Of course though, due to the ongoing COVID-19 pandemic it's not > > > yet > > > clear whether or not it will be possible to host XDC 2022 in > > > person, > > > although is seems very likely. Because of this, we would like to > > > make it clear that sponsors should prepare for both the > > > possibility > > > of an in person conference, and the possibility of a virtual > > > conference. We will work with organizers on coming up with a > > > deadline for deciding whether or not we'll be going virtual, > > > likely > > > sometime around July 2022. > > > > > > If you're considering hosting XDC, we've assembled a wiki page > > > with > > > what's generally expected and needed: > > > > > > https://www.x.org/wiki/Events/RFP/ > > > > > > When submitting your proposal, please make sure to include at > > > least > > > the > > > key information about the potential location in question, > > > possible > > > dates along with estimated costs. Proposals can be submitted to > > > board > > > at foundation.x.org until the deadline of *September 1st, 2021*. > > > > > > Additionally, an quirk early heads-up to the board if you're > > > considering hosting would be appreciated, in case we need to > > > adjust > > > the > > > schedule a bit. Also, earlier is better since there generally > > > will > > > be > > > a > > > bit of Q with organizers. > > > > > > And if you just have some questions about what organizing XDC > > > entails, > > > please feel free to chat with previous organizers, or someone > > > from > > > the > > > board. > > > > > > Thanks, > > > > > > Sam > > > > > > ___ > > > 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 mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: This is a digitally signed message part
Re: [Mesa-dev] Requests For Proposals for hosting XDC 2022 are now open
Remember before enjoying your holiday that the deadline for XDC 2022 proposals is *September 1st, 2021* :-) Feel free to submit your proposal before, so we can give you early feedback on it! Sam On Thu, 2021-07-01 at 18:14 +0200, Samuel Iglesias Gonsálvez wrote: > This is a reminder that the call for proposals for hosting XDC 2022 > period finishes in two months. > > Be sure to prepare your submission before you leave on holiday! > > Sam > > On Thu, 2021-05-20 at 12:15 +0200, Samuel Iglesias Gonsálvez wrote: > > Hello everyone! > > > > The X.org board is soliciting proposals to host XDC in 2022. Since > > XDC 2021 is being held in Europe this year (although virtually), > > we've > > decided to host in North America. However, the board is open to > > other > > locations, especially if there's an interesting co-location with > > another conference. > > > > Of course though, due to the ongoing COVID-19 pandemic it's not yet > > clear whether or not it will be possible to host XDC 2022 in > > person, > > although is seems very likely. Because of this, we would like to > > make it clear that sponsors should prepare for both the possibility > > of an in person conference, and the possibility of a virtual > > conference. We will work with organizers on coming up with a > > deadline for deciding whether or not we'll be going virtual, likely > > sometime around July 2022. > > > > If you're considering hosting XDC, we've assembled a wiki page with > > what's generally expected and needed: > > > > https://www.x.org/wiki/Events/RFP/ > > > > When submitting your proposal, please make sure to include at least > > the > > key information about the potential location in question, possible > > dates along with estimated costs. Proposals can be submitted to > > board > > at foundation.x.org until the deadline of *September 1st, 2021*. > > > > Additionally, an quirk early heads-up to the board if you're > > considering hosting would be appreciated, in case we need to adjust > > the > > schedule a bit. Also, earlier is better since there generally will > > be > > a > > bit of Q with organizers. > > > > And if you just have some questions about what organizing XDC > > entails, > > please feel free to chat with previous organizers, or someone from > > the > > board. > > > > Thanks, > > > > Sam > > > > ___ > > 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 signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XDC 2021: Registration & Call for Proposals now open!
On Tue, 2021-07-06 at 09:38 +0200, Samuel Iglesias Gonsálvez wrote: > Hi! > > We have decided to extend the Call for Proposals until September 1st > or > until we will all the available talk slots, whichever occurs first. > > Remember that talks will get accepted by order of submission. If you > are thinking on proposing a talk for XDC, do it as soon as possible. > Due to the overwhelming last minute response, we have filled all the pending slots for full and half-slot talks. Thanks a lot! Therefore, we close the CfP for full and half-slot talks. However, we stil welcome proposals for workshops, demos and lightning talks... Don't forget to submit yours! Sam > Thanks, > > Sam > > On Sat, 2021-06-26 at 08:35 +0200, Samuel Iglesias Gonsálvez wrote: > > One week! > > > > Don't forget to submit your proposals! > > > > Sam > > > > On Tue, 2021-06-08 at 12:38 +0200, Samuel Iglesias Gonsálvez wrote: > > > Kind reminder. Deadline is Sunday, 4 July 2021 :-) > > > > > > Sam > > > > > > On Thu, 2021-05-20 at 10:01 +, Szwichtenberg, Radoslaw wrote: > > > > Hello! > > > > > > > > Registration & Call for Proposals are now open for XDC 2021, > > > > which > > > > will > > > > take place on September 15-17, 2021. This year we will repeat > > > > as > > > > virtual event. > > > > > > > > https://indico.freedesktop.org/event/1/ > > > > > > > > As usual, the conference is free of charge and open to the > > > > general > > > > public. If you plan on attending, please make sure to register > > > > as > > > > early > > > > as possible! > > > > > > > > In order to register as attendee, you will therefore need to > > > > register > > > > via the XDC website. As XDC moved to a new Indico > > > > infrastructure, > > > > if > > > > you previously registered on the XDC website, you need to > > > > create > > > > a > > > > new > > > > account again. > > > > > > > > https://indico.freedesktop.org/event/1/registrations/1/ > > > > > > > > In addition to registration, the CfP is now open for talks, > > > > workshops > > > > and demos at XDC 2021. While any serious proposal will be > > > > gratefully > > > > considered, topics of interest to X.Org and freedesktop.org > > > > developers > > > > are encouraged. The program focus is on new development, > > > > ongoing > > > > challenges and anything else that will spark discussions among > > > > attendees in the hallway track. > > > > > > > > We are open to talks across all layers of the graphics stack, > > > > from > > > > the > > > > kernel to desktop environments / graphical applications and > > > > about > > > > how > > > > to make things better for the developers who build them. Head > > > > to > > > > the > > > > CfP page to learn more: > > > > > > > > https://indico.freedesktop.org/event/1/abstracts/ > > > > > > > > The deadline for submissions is Sunday, 4 July 2021. > > > > > > > > Last year we modified our Reimbursement Policy to accept > > > > speaker > > > > expenses for X.Org virtual events like XDC 2021. Check it out > > > > here: > > > > > > > > https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ > > > > > > > > If you have any questions, please send me an email to > > > > radoslaw.szwichtenb...@intel.com, adding on CC the X.org board > > > > (board > > > > at foundation.x.org). > > > > > > > > And don't forget, you can follow us on Twitter for all the > > > > latest > > > > updates and to stay connected: > > > > > > > > > > > > https://twitter.com/XOrgDevConf > > > > > > > > Best, > > > > > > > > Radek > > > > > > > > P.S: a DNS redirection (xdc2021.x.org) is work in progress. > > > > Please > > > > use > > > > the mentioned links for the moment. > > > > > > > > > > > > Radosław Szwichtenberg > > > > - > > > > Intel Technology Poland sp. z o.o. > > > > ul. Slowackiego 173, 80-298 Gdansk > > > > KRS 101882 - NIP 957-07-52-316 > > > > > > > > ___ > > > > 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 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 signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XDC 2021: Registration & Call for Proposals now open!
Hi! We have decided to extend the Call for Proposals until September 1st or until we will all the available talk slots, whichever occurs first. Remember that talks will get accepted by order of submission. If you are thinking on proposing a talk for XDC, do it as soon as possible. Thanks, Sam On Sat, 2021-06-26 at 08:35 +0200, Samuel Iglesias Gonsálvez wrote: > One week! > > Don't forget to submit your proposals! > > Sam > > On Tue, 2021-06-08 at 12:38 +0200, Samuel Iglesias Gonsálvez wrote: > > Kind reminder. Deadline is Sunday, 4 July 2021 :-) > > > > Sam > > > > On Thu, 2021-05-20 at 10:01 +, Szwichtenberg, Radoslaw wrote: > > > Hello! > > > > > > Registration & Call for Proposals are now open for XDC 2021, > > > which > > > will > > > take place on September 15-17, 2021. This year we will repeat as > > > virtual event. > > > > > > https://indico.freedesktop.org/event/1/ > > > > > > As usual, the conference is free of charge and open to the > > > general > > > public. If you plan on attending, please make sure to register as > > > early > > > as possible! > > > > > > In order to register as attendee, you will therefore need to > > > register > > > via the XDC website. As XDC moved to a new Indico infrastructure, > > > if > > > you previously registered on the XDC website, you need to create > > > a > > > new > > > account again. > > > > > > https://indico.freedesktop.org/event/1/registrations/1/ > > > > > > In addition to registration, the CfP is now open for talks, > > > workshops > > > and demos at XDC 2021. While any serious proposal will be > > > gratefully > > > considered, topics of interest to X.Org and freedesktop.org > > > developers > > > are encouraged. The program focus is on new development, ongoing > > > challenges and anything else that will spark discussions among > > > attendees in the hallway track. > > > > > > We are open to talks across all layers of the graphics stack, > > > from > > > the > > > kernel to desktop environments / graphical applications and about > > > how > > > to make things better for the developers who build them. Head to > > > the > > > CfP page to learn more: > > > > > > https://indico.freedesktop.org/event/1/abstracts/ > > > > > > The deadline for submissions is Sunday, 4 July 2021. > > > > > > Last year we modified our Reimbursement Policy to accept speaker > > > expenses for X.Org virtual events like XDC 2021. Check it out > > > here: > > > > > > https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ > > > > > > If you have any questions, please send me an email to > > > radoslaw.szwichtenb...@intel.com, adding on CC the X.org board > > > (board > > > at foundation.x.org). > > > > > > And don't forget, you can follow us on Twitter for all the latest > > > updates and to stay connected: > > > > > > > > > https://twitter.com/XOrgDevConf > > > > > > Best, > > > > > > Radek > > > > > > P.S: a DNS redirection (xdc2021.x.org) is work in progress. > > > Please > > > use > > > the mentioned links for the moment. > > > > > > > > > Radosław Szwichtenberg > > > - > > > Intel Technology Poland sp. z o.o. > > > ul. Slowackiego 173, 80-298 Gdansk > > > KRS 101882 - NIP 957-07-52-316 > > > > > > ___ > > > 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 mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Requests For Proposals for hosting XDC 2022 are now open
This is a reminder that the call for proposals for hosting XDC 2022 period finishes in two months. Be sure to prepare your submission before you leave on holiday! Sam On Thu, 2021-05-20 at 12:15 +0200, Samuel Iglesias Gonsálvez wrote: > Hello everyone! > > The X.org board is soliciting proposals to host XDC in 2022. Since > XDC 2021 is being held in Europe this year (although virtually), > we've > decided to host in North America. However, the board is open to other > locations, especially if there's an interesting co-location with > another conference. > > Of course though, due to the ongoing COVID-19 pandemic it's not yet > clear whether or not it will be possible to host XDC 2022 in person, > although is seems very likely. Because of this, we would like to > make it clear that sponsors should prepare for both the possibility > of an in person conference, and the possibility of a virtual > conference. We will work with organizers on coming up with a > deadline for deciding whether or not we'll be going virtual, likely > sometime around July 2022. > > If you're considering hosting XDC, we've assembled a wiki page with > what's generally expected and needed: > > https://www.x.org/wiki/Events/RFP/ > > When submitting your proposal, please make sure to include at least > the > key information about the potential location in question, possible > dates along with estimated costs. Proposals can be submitted to board > at foundation.x.org until the deadline of *September 1st, 2021*. > > Additionally, an quirk early heads-up to the board if you're > considering hosting would be appreciated, in case we need to adjust > the > schedule a bit. Also, earlier is better since there generally will be > a > bit of Q with organizers. > > And if you just have some questions about what organizing XDC > entails, > please feel free to chat with previous organizers, or someone from > the > board. > > Thanks, > > Sam > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XDC 2021: Registration & Call for Proposals now open!
One week! Don't forget to submit your proposals! Sam On Tue, 2021-06-08 at 12:38 +0200, Samuel Iglesias Gonsálvez wrote: > Kind reminder. Deadline is Sunday, 4 July 2021 :-) > > Sam > > On Thu, 2021-05-20 at 10:01 +, Szwichtenberg, Radoslaw wrote: > > Hello! > > > > Registration & Call for Proposals are now open for XDC 2021, which > > will > > take place on September 15-17, 2021. This year we will repeat as > > virtual event. > > > > https://indico.freedesktop.org/event/1/ > > > > As usual, the conference is free of charge and open to the general > > public. If you plan on attending, please make sure to register as > > early > > as possible! > > > > In order to register as attendee, you will therefore need to > > register > > via the XDC website. As XDC moved to a new Indico infrastructure, > > if > > you previously registered on the XDC website, you need to create a > > new > > account again. > > > > https://indico.freedesktop.org/event/1/registrations/1/ > > > > In addition to registration, the CfP is now open for talks, > > workshops > > and demos at XDC 2021. While any serious proposal will be > > gratefully > > considered, topics of interest to X.Org and freedesktop.org > > developers > > are encouraged. The program focus is on new development, ongoing > > challenges and anything else that will spark discussions among > > attendees in the hallway track. > > > > We are open to talks across all layers of the graphics stack, from > > the > > kernel to desktop environments / graphical applications and about > > how > > to make things better for the developers who build them. Head to > > the > > CfP page to learn more: > > > > https://indico.freedesktop.org/event/1/abstracts/ > > > > The deadline for submissions is Sunday, 4 July 2021. > > > > Last year we modified our Reimbursement Policy to accept speaker > > expenses for X.Org virtual events like XDC 2021. Check it out here: > > > > https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ > > > > If you have any questions, please send me an email to > > radoslaw.szwichtenb...@intel.com, adding on CC the X.org board > > (board > > at foundation.x.org). > > > > And don't forget, you can follow us on Twitter for all the latest > > updates and to stay connected: > > > > > > https://twitter.com/XOrgDevConf > > > > Best, > > > > Radek > > > > P.S: a DNS redirection (xdc2021.x.org) is work in progress. Please > > use > > the mentioned links for the moment. > > > > > > Radosław Szwichtenberg > > - > > Intel Technology Poland sp. z o.o. > > ul. Slowackiego 173, 80-298 Gdansk > > KRS 101882 - NIP 957-07-52-316 > > > > ___ > > 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 signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XDC 2021: Registration & Call for Proposals now open!
Kind reminder. Deadline is Sunday, 4 July 2021 :-) Sam On Thu, 2021-05-20 at 10:01 +, Szwichtenberg, Radoslaw wrote: > Hello! > > Registration & Call for Proposals are now open for XDC 2021, which > will > take place on September 15-17, 2021. This year we will repeat as > virtual event. > > https://indico.freedesktop.org/event/1/ > > As usual, the conference is free of charge and open to the general > public. If you plan on attending, please make sure to register as > early > as possible! > > In order to register as attendee, you will therefore need to register > via the XDC website. As XDC moved to a new Indico infrastructure, if > you previously registered on the XDC website, you need to create a > new > account again. > > https://indico.freedesktop.org/event/1/registrations/1/ > > In addition to registration, the CfP is now open for talks, workshops > and demos at XDC 2021. While any serious proposal will be gratefully > considered, topics of interest to X.Org and freedesktop.org > developers > are encouraged. The program focus is on new development, ongoing > challenges and anything else that will spark discussions among > attendees in the hallway track. > > We are open to talks across all layers of the graphics stack, from > the > kernel to desktop environments / graphical applications and about how > to make things better for the developers who build them. Head to the > CfP page to learn more: > > https://indico.freedesktop.org/event/1/abstracts/ > > The deadline for submissions is Sunday, 4 July 2021. > > Last year we modified our Reimbursement Policy to accept speaker > expenses for X.Org virtual events like XDC 2021. Check it out here: > > https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ > > If you have any questions, please send me an email to > radoslaw.szwichtenb...@intel.com, adding on CC the X.org board > (board > at foundation.x.org). > > And don't forget, you can follow us on Twitter for all the latest > updates and to stay connected: > > > https://twitter.com/XOrgDevConf > > Best, > > Radek > > P.S: a DNS redirection (xdc2021.x.org) is work in progress. Please > use > the mentioned links for the moment. > > > Radosław Szwichtenberg > - > Intel Technology Poland sp. z o.o. > ul. Slowackiego 173, 80-298 Gdansk > KRS 101882 - NIP 957-07-52-316 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Requests For Proposals for hosting XDC 2022 are now open
Hello everyone! The X.org board is soliciting proposals to host XDC in 2022. Since XDC 2021 is being held in Europe this year (although virtually), we've decided to host in North America. However, the board is open to other locations, especially if there's an interesting co-location with another conference. Of course though, due to the ongoing COVID-19 pandemic it's not yet clear whether or not it will be possible to host XDC 2022 in person, although is seems very likely. Because of this, we would like to make it clear that sponsors should prepare for both the possibility of an in person conference, and the possibility of a virtual conference. We will work with organizers on coming up with a deadline for deciding whether or not we'll be going virtual, likely sometime around July 2022. If you're considering hosting XDC, we've assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ When submitting your proposal, please make sure to include at least the key information about the potential location in question, possible dates along with estimated costs. Proposals can be submitted to board at foundation.x.org until the deadline of *September 1st, 2021*. Additionally, an quirk early heads-up to the board if you're considering hosting would be appreciated, in case we need to adjust the schedule a bit. Also, earlier is better since there generally will be a bit of Q with organizers. And if you just have some questions about what organizing XDC entails, please feel free to chat with previous organizers, or someone from the board. Thanks, Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Outstanding Mesa 21.0 patches
For turnip: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10205 Sam On Fri, 2021-04-09 at 09:39 -0700, Dylan Baker wrote: > Hi all, > > I've been a little behind on release work recently, and I'm tryinng to > cleanup the backlog of patches against the 21.0 branch that haven't > been > applied but have been nominated. Below is the list of outstanding > patches that either don't apply, or cause regressions. If you'd like to > have these applied please provide a backport, otherwise I'm going to > mark all of these as "denominated". > > Cheers, > Dylan > > > 6a29632dd2 Revert "glcpp: disable 'windows' > tests" > > > > bd1705a480 vulkan: Make vk_debug_report_callback derive from > vk_object_base > > > > 366fb28dac ci: Fix MESA_TEMPLATES_COMMIT > value > > > > 0464117ad9 ci: remove nouveau from shader-db > runs > > > > 0f7379e308 ci: tracie dashboard URLs only in the failure after the > testcase > > > > cff5c40fc3 pan/bi: Fix blend shaders using LD_TILE with > MRT > > > > c0c03f29e0 lavapipe: implement physical device group > enumeration > > > > b6b3b38434 turnip: consider HW limit on number of views when apply > multipos > opt > > > > 5a340c0929 vulkan/util: add api to reset object magic + private > data. > > > > 226c7ae2a8 lavapipe: reset object base on recycled command > buffers > > > > 8b44e45347 intel/perf: fix roll over PERF_CNT counter > accumulation > > > > 3d3f21f0be ci: add libdrm to the x86_test-vk > container > > > > 0a939e788f lavapipe: reorder descriptor set stages to get correct > binding > > > > abc724e440 lavapipe: sort bindings before creating descriptor > set
Re: [Mesa-dev] [Freedreno] [RESEND] Requests For Proposals for hosting XDC2021 are now open
Deadline is November 1st, just in a few weeks! Don't forget to submit your XDC 2021 proposal to bo...@foundation.x.org . Sam On Thu, 2020-09-03 at 12:16 -0400, Lyude Paul wrote: > (Including a bunch more emails in the To: that got missed the first > time) > > Hello everyone! > > The X.org board is soliciting proposals to host XDC in 2021. Since > XDC2020 is being held virtually this year, we've decided to host in > either North America or Europe. However, the board is open to other > locations, especially if there's an interesting co-location with > another > conference. > > Of course though, due to the ongoing COVID-19 pandemic it's not yet > clear whether or not it will be possible to host XDC2021 in person. > Because of this, we would like to make it clear that sponsors should > prepare for both the possibility of an in person conference, and the > possibility of a virtual conference. We will work with organizers on > coming up with a deadline for deciding whether or not we'll be going > virtual, likely sometime around July. > > If you're considering hosting XDC, we've assembled a wiki page with > what's generally expected and needed: > > https://www.x.org/wiki/Events/RFP/ > > When submitting your proposal, please make sure to include at least > the > key information about the potential location in question, possible > dates > along with estimated costs. Proposals can be submitted to board at > foundation.x.org until the deadline of November 1st. Additionally, an > quirk early heads-up to the board if you're considering hosting would > be > appreciated, in case we need to adjust the schedule a bit. Also, > earlier > is better since there generally will be a bit of Q with organizers. > > And if you just have some questions about what organizing XDC > entails, > please feel free to chat with previous organizers, or someone from > the > board. signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] XDC 2020 feedback and comments
Hi all, Huge thanks again to the entire team from Intel, for their great work organizing XDC 2020, our first virtual conference! As usual we're looking for feedback on both XDC itself, and the CFP process and program selection. Both about what was great and should be kept for next year's edition, and where there's room for improvement. The board does keep some notes, for those interested in what we have already: - XDC notes for prospective organizers: https://www.x.org/wiki/Events/RFP/ - CFP notes: https://www.x.org/wiki/Events/PapersCommittee/ If you want to send in your comments in private, please send them to the X.org Foundation board: bo...@foundation.x.org Cheers, Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [XDC 2020] Virtual conference + Call for Proposals extended 2 weeks more
On 7/3/20 4:41 PM, Samuel Iglesias Gonsálvez wrote: > Hi, > > In the last meeting, X.Org Foundation board has decided that XDC 2020 > will be a virtual conference, given the uncertain COVID-19 situation in > Europe by September, including the possibility of a second wave, > outbreaks and travel restrictions, either in Poland or in other > countries. > > XDC 2020 organization team agrees on this decision and it volunteered > to organize our first virtual XDC! > > We would like to announce as well that the new CFP deadline is Sunday > July 19th 2020. Don't forget to submit your talk, demo and workshop > proposals! > As approved in last board's meeting [0], CfP is extended until two weeks before the conference, or until we fill all the slots (whichever happens first). Please submit your talk proposals early! Last two years we had lots of talks about new and fresh development and we prioritized those over other kind of talks, as they had more potential for discussions and hallway track. However, this year that doesn't make too much sense, so we encourage our community to submit any talk related to open-source graphics stack, including those that focus on project status updates. Sam [0] https://www.x.org/wiki/BoardOfDirectors/MeetingSummaries/2020/07-16/ > Thanks, > > Sam > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [XDC 2020] Virtual conference + Call for Proposals extended 2 weeks more
On 7/3/20 4:41 PM, Samuel Iglesias Gonsálvez wrote: > Hi, > > In the last meeting, X.Org Foundation board has decided that XDC 2020 > will be a virtual conference, given the uncertain COVID-19 situation in > Europe by September, including the possibility of a second wave, > outbreaks and travel restrictions, either in Poland or in other > countries. > > XDC 2020 organization team agrees on this decision and it volunteered > to organize our first virtual XDC! > > We would like to announce as well that the new CFP deadline is Sunday > July 19th 2020. Don't forget to submit your talk, demo and workshop > proposals! Last week to submit your proposals! ;-) Sam > Thanks, > > Sam > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [XDC 2020] Virtual conference + Call for Proposals extended 2 weeks more
Hi, In the last meeting, X.Org Foundation board has decided that XDC 2020 will be a virtual conference, given the uncertain COVID-19 situation in Europe by September, including the possibility of a second wave, outbreaks and travel restrictions, either in Poland or in other countries. XDC 2020 organization team agrees on this decision and it volunteered to organize our first virtual XDC! We would like to announce as well that the new CFP deadline is Sunday July 19th 2020. Don't forget to submit your talk, demo and workshop proposals! Thanks, Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XDC 2020: Registration & Call for Proposals now open!
Hi, This is a kindly reminder that the CFP deadline is in less than two weeks :) On Fri, 2020-05-15 at 14:15 +, Szwichtenberg, Radoslaw wrote: > Hello! > > Registration & Call for Proposals are now open for XDC 2020, which > will > take place at the Gdańsk University of Technology in Gdańsk, Poland > on September 16-18, 2020. > > Thanks to LWN.net for hosting the website again this year! > > https://xdc2020.x.org > > As usual, the conference is free of charge and open to the general > public. If you plan on attending, please make sure to register as > early as possible! However, don't book any travel or hotel until the > organization decides if we keep the conference as it is or there is > any change. Please read this message on the website for more > information: > > https://xdc2020.x.org/event/9/page/78-covid-19 > > In order to register as attendee, you will therefore need to register > via the XDC > website. However, as XDC is sharing the same Indico infrastructure as > LPC, if you previously registered on the LPC website > (linuxplumbersconference.org) or on the XDC 2019 website > (xdc2019.x.org), then you already have an active account > and can use the same username & password to login! > > https://xdc2020.x.org/event/9/registrations/7/ > > In addition to registration, the CfP is now open for talks, workshops > and demos at XDC 2020. While any serious proposal will be gratefully > considered, topics of interest to X.Org and freedesktop.org > developers > are encouraged. The program focus is on new development, ongoing > challenges and anything else that will spark discussions among > attendees in the hallway track. > > We are open to talks across all layers of the graphics stack, from > the > kernel to desktop environments / graphical applications and about how > to make things better for the developers who build them. Head to the > CfP page to learn more: > > https://xdc2020.x.org/event/9/abstracts/ > > The deadline for submissions is Sunday, 5 July 2020. > > Notice that the event may end up being postponed, converted to a > fully online conference, or even a hybrid one (physical event + some > remote talks). It depends on how COVID-19 situation evolves in the > different countries and the restrictions we will have at that time. > Also, some people may decide to skip the physical conference to avoid > any risk of infection. Because of that, please indicate in your talk > submission if you prefer to give a remote talk in the case that XDC > keeps being a physical event this year. Similarly, if you think that > your talk makes no sense if XDC ends up being a fully-virtual > conference, please indicate that in the notes of the talk submission. > We are gathering all the information in order to make a decision at the beginning of July. Stay tuned [0]! Sam [0] https://xdc2020.x.org/event/9/page/78-covid-19 > If COVID-19 situation allows it, we are looking forward to seeing you > in Gdańsk! If you have any questions, please send me an email to > radoslaw.szwichtenb...@intel.com, adding on CC the X.org board > (board at foundation.x.org). > > And don't forget, you can follow us on Twitter for all the latest > updates and to stay connected: > > https://twitter.com/xdc2020 > > Best, > > Radek > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] XDC 2019 feedback and comments
Hi all, Once more huge thanks to the entire team from Collabora, for their great work organizing XDC 2019! As usual we're looking for feedback on both XDC itself, and the CFP process and program selection. Both about what was great and should be kept for next year's edition, and where there's room for improvement. The board does keep some notes, for those interested in what we have already: - XDC notes for prospective organizers: https://www.x.org/wiki/Events/RFP/ - CFP notes: https://www.x.org/wiki/Events/PapersCommittee/ If you want to send in your comments in private, please send them to the x.org board. Cheers, Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XDC 2019 feedback and comments
On Tue, 2019-10-08 at 17:27 +0200, Samuel Iglesias Gonsálvez wrote: > Hi all, > > Once more huge thanks to the entire team from Collabora, > for their great work organizing XDC 2019! > > As usual we're looking for feedback on both XDC itself, and the CFP > process and program selection. Both about what was great and should > be > kept for next year's edition, and where there's room for improvement. > The board does keep some notes, for those interested in what we have > already: > > - XDC notes for prospective organizers: > https://www.x.org/wiki/Events/RFP/ > > - CFP notes: https://www.x.org/wiki/Events/PapersCommittee/ > > If you want to send in your comments in private, please send them to > the x.org board. Forgot to mention its email address: X.Org Foundation Board < bo...@foundation.x.org> Sam > > Cheers, > > Sam signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] radv: assert on inline uniform blocks in radv_CmdPushDescriptorSetKHR()
According to the Vulkan spec, inline uniform blocks are not allowed
to be updated through vkCmdPushDescriptorSetKHR().
There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:
"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
that descriptor sets must not be allocated using this layout, and
descriptors are instead pushed by vkCmdPushDescriptorSetKHR."
"If flags contains
VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
elements of pBindings must not have a descriptorType of
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".
There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
this case but it is implied in the creation of the descriptor set
layout as aforementioned.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/amd/vulkan/radv_cmd_buffer.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 3faaf94eb99..d69bec60bb8 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3245,6 +3245,14 @@ void radv_CmdPushDescriptorSetKHR(
pipelineBindPoint))
return;
+ /* Check that there are no inline uniform block updates when calling
vkCmdPushDescriptorSetKHR()
+* because it is invalid, according to Vulkan spec.
+*/
+ for (int i = 0; i < descriptorWriteCount; i++) {
+ const VkWriteDescriptorSet *writeset = [i];
+ assert(writeset->descriptorType !=
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT);
+ }
+
radv_update_descriptor_sets(cmd_buffer->device, cmd_buffer,
radv_descriptor_set_to_handle(push_set),
descriptorWriteCount, pDescriptorWrites, 0,
NULL);
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radv: ignore inline uniform blocks in radv_CmdPushDescriptorSetKHR()
On 6/11/19 12:05 PM, Józef Kucia wrote: > On Tue, Jun 11, 2019 at 11:57 AM Samuel Iglesias Gonsálvez > wrote: >> According to the Vulkan spec, uniform blocks are not allowed to be >> updated through vkCmdPushDescriptorSetKHR(). >> >> There are these spec quotes from "13.2.1. Descriptor Set Layout" >> that are relevant for this case: >> >> "VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies >> that descriptor sets must not be allocated using this layout, and >> descriptors are instead pushed by vkCmdPushDescriptorSetKHR." >> >> "If flags contains >> VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all >> elements of pBindings must not have a descriptorType of >> VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT". >> >> There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid >> this case but it is implied in the creation of the descriptor set >> layout as aforementioned. >> >> Signed-off-by: Samuel Iglesias Gonsálvez >> --- >> >> My only doubt is I did well in the case of >> radv_meta_push_descriptor_set(), let me know if you prefer to change >> it to false. >> > Perhaps I'm missing something, but what is the point to add the > additional checks for invalid usage? A correct program must not use > inline uniform blocks with push descriptors. > Right, it should be detected by the Validation Layers. However it is arguable what to do in the driver's side. We can just keep it as it is now, ignore inline uniform block updates (this patch) or even add an assert if it affects stability of the HW (it is not the case here, we tested it). I think ignoring the updates it's the best option, but I am OK with what RADV developers prefer to do. Sam signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radv: ignore inline uniform blocks in radv_CmdPushDescriptorSetKHR()
According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().
There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:
"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
that descriptor sets must not be allocated using this layout, and
descriptors are instead pushed by vkCmdPushDescriptorSetKHR."
"If flags contains
VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
elements of pBindings must not have a descriptorType of
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".
There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
this case but it is implied in the creation of the descriptor set
layout as aforementioned.
Signed-off-by: Samuel Iglesias Gonsálvez
---
My only doubt is I did well in the case of
radv_meta_push_descriptor_set(), let me know if you prefer to change
it to false.
src/amd/vulkan/radv_cmd_buffer.c | 4 ++--
src/amd/vulkan/radv_descriptor_set.c | 11 ---
src/amd/vulkan/radv_private.h| 3 ++-
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/src/amd/vulkan/radv_cmd_buffer.c b/src/amd/vulkan/radv_cmd_buffer.c
index 3faaf94eb99..38a2d0d0efe 100644
--- a/src/amd/vulkan/radv_cmd_buffer.c
+++ b/src/amd/vulkan/radv_cmd_buffer.c
@@ -3219,7 +3219,7 @@ void radv_meta_push_descriptor_set(
radv_update_descriptor_sets(cmd_buffer->device, cmd_buffer,
radv_descriptor_set_to_handle(push_set),
- descriptorWriteCount, pDescriptorWrites, 0,
NULL);
+ descriptorWriteCount, pDescriptorWrites, 0,
NULL, true);
radv_set_descriptor_set(cmd_buffer, pipelineBindPoint, push_set, set);
}
@@ -3247,7 +3247,7 @@ void radv_CmdPushDescriptorSetKHR(
radv_update_descriptor_sets(cmd_buffer->device, cmd_buffer,
radv_descriptor_set_to_handle(push_set),
- descriptorWriteCount, pDescriptorWrites, 0,
NULL);
+ descriptorWriteCount, pDescriptorWrites, 0,
NULL, true);
radv_set_descriptor_set(cmd_buffer, pipelineBindPoint, push_set, set);
descriptors_state->push_dirty = true;
diff --git a/src/amd/vulkan/radv_descriptor_set.c
b/src/amd/vulkan/radv_descriptor_set.c
index bd00f68a3cb..04bbafb1ed5 100644
--- a/src/amd/vulkan/radv_descriptor_set.c
+++ b/src/amd/vulkan/radv_descriptor_set.c
@@ -939,7 +939,8 @@ void radv_update_descriptor_sets(
uint32_tdescriptorWriteCount,
const VkWriteDescriptorSet* pDescriptorWrites,
uint32_tdescriptorCopyCount,
- const VkCopyDescriptorSet* pDescriptorCopies)
+ const VkCopyDescriptorSet* pDescriptorCopies,
+ const bool isPushDescriptorSet)
{
uint32_t i, j;
for (i = 0; i < descriptorWriteCount; i++) {
@@ -961,7 +962,11 @@ void radv_update_descriptor_sets(
ptr += binding_layout->offset / 4;
if (writeset->descriptorType ==
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT) {
- write_block_descriptor(device, cmd_buffer,
(uint8_t*)ptr + writeset->dstArrayElement, writeset);
+ /* Ignore inline uniform block updates when called from
vkCmdPushDescriptorSetKHR()
+* because it is invalid, according to Vulkan spec.
+*/
+ if (!isPushDescriptorSet)
+ write_block_descriptor(device, cmd_buffer,
(uint8_t*)ptr + writeset->dstArrayElement, writeset);
continue;
}
@@ -1094,7 +1099,7 @@ void radv_UpdateDescriptorSets(
RADV_FROM_HANDLE(radv_device, device, _device);
radv_update_descriptor_sets(device, NULL, VK_NULL_HANDLE,
descriptorWriteCount, pDescriptorWrites,
- descriptorCopyCount, pDescriptorCopies);
+ descriptorCopyCount, pDescriptorCopies,
false);
}
VkResult radv_CreateDescriptorUpdateTemplate(VkDevice _device,
diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
index 8f2e80b3017..bead0867119 100644
--- a/src/amd/vulkan/radv_private.h
+++ b/src/amd/vulkan/radv_private.h
@@ -1976,7 +1976,8 @@ radv_update_descriptor_sets(struct radv_device *device,
uint32_t descriptorWriteCount,
const VkWriteDescriptorSet *pDescriptorWrites,
uint32_t descriptorCopyCount,
-const VkCopyDescriptorSet *pDescriptorCopies);
+const VkCopyDescriptorSet *pDescriptorCopies,
+
[Mesa-dev] [PATCH 1/2] anv: ignore inline uniform blocks in anv_CmdPushDescriptorSetKHR()
According to the Vulkan spec, uniform blocks are not allowed to be
updated through vkCmdPushDescriptorSetKHR().
There are these spec quotes from "13.2.1. Descriptor Set Layout"
that are relevant for this case:
"VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR specifies
that descriptor sets must not be allocated using this layout, and
descriptors are instead pushed by vkCmdPushDescriptorSetKHR."
"If flags contains
VK_DESCRIPTOR_SET_LAYOUT_CREATE_PUSH_DESCRIPTOR_BIT_KHR, then all
elements of pBindings must not have a descriptorType of
VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT".
There is no explicit mention in vkCmdPushDescriptorSetKHR() to forbid
this case but it is implied in the creation of the descriptor set
layout as aforementioned.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/vulkan/anv_cmd_buffer.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/src/intel/vulkan/anv_cmd_buffer.c
b/src/intel/vulkan/anv_cmd_buffer.c
index b0ce00f6daf..3c020a1d5b2 100644
--- a/src/intel/vulkan/anv_cmd_buffer.c
+++ b/src/intel/vulkan/anv_cmd_buffer.c
@@ -1081,19 +1081,6 @@ void anv_CmdPushDescriptorSetKHR(
}
break;
- case VK_DESCRIPTOR_TYPE_INLINE_UNIFORM_BLOCK_EXT: {
- const VkWriteDescriptorSetInlineUniformBlockEXT *inline_write =
-vk_find_struct_const(write->pNext,
-
WRITE_DESCRIPTOR_SET_INLINE_UNIFORM_BLOCK_EXT);
- assert(inline_write->dataSize == write->descriptorCount);
- anv_descriptor_set_write_inline_uniform_data(cmd_buffer->device, set,
- write->dstBinding,
- inline_write->pData,
- write->dstArrayElement,
- inline_write->dataSize);
- break;
- }
-
default:
break;
}
--
2.17.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radv: write availability status vkGetQueryPoolResults() when the data is not available
On Thu, 2019-03-28 at 16:21 +0100, Samuel Pitoiset wrote:
> On 3/25/19 8:16 AM, Samuel Iglesias Gonsálvez wrote:
> > On Fri, 2019-03-22 at 17:21 +0100, Samuel Pitoiset wrote:
> > > Does this fix anything known?
> > >
> > I am writing CTS tests for VK_EXT_host_query_reset extension and I
> > found this bug while testing them on RADV.
> >
> > > Does that rule also apply for CmdCopyQueryPoolResults()? If so,
> > > we
> > > might
> > > need to fix it (I haven't looked yet).
> > >
> > The rule is slightly different on CmdCopyQueryPoolResults():
> >
> > "Similarly, if VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set and
> > VK_QUERY_RESULT_WAIT_BIT is not set, the availability is guaranteed
> > to
> > reflect the most recent use of the query on the same queue,
> > assuming
> > that the query is not being simultaneously used by other queues. As
> > with vkGetQueryPoolResults, implementations must guarantee that if
> > they
> > return a non-zero availability value, then the numerical results
> > are
> > valid."
> >
> > So if VK_QUERY_RESULT_WITH_AVAILABILITY_BIT we need to still set
> > the
> > availability state.
> >
> > I skimmed the implementation of this function on RADV, it seems it
> > is
> > missing setting the availability value for all the queries except
> > for
> > VK_QUERY_TYPE_TIMESTAMP.
> >
> > Could you take care of this?
> Yes, do you have tests for CmdCopyQueryPoolResults()?
There are no tests for this case on CTS. I modified manually one test
and it seems I was wrong: RADV is setting the availability value. So
you don't need to do anything for the moment.
I'm going to add in my TODO list to add tests for this in CTS when time
allows, as it is not fully covered right now.
Thanks,
Sam
> > > With the comment on patch 1, series is:
> > >
> > > Reviewed-by: Samuel Pitoiset
> > >
> > OK, thanks! It seems I did a wrong squash of patches on patch 1. I
> > will
> > fix it and push both patches to master.
> >
> > Sam
> >
> > > On 3/22/19 1:03 PM, Samuel Iglesias Gonsálvez wrote:
> > > > If VK_QUERY_RESULT_WITH_AVAILABILY_BIT is set and
> > > > VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are
> > > > both
> > > > not
> > > > set, we need return to VK_NOT_READY only and set the
> > > > availability
> > > > status field for each query.
> > > >
> > > > From Vulkan spec:
> > > >
> > > > "If VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT
> > > > are
> > > > both
> > > > not set then no result values are written to pData for queries
> > > > that
> > > > are
> > > > in the unavailable state at the time of the call, and
> > > > vkGetQueryPoolResults returns VK_NOT_READY. However,
> > > > availability
> > > > state
> > > > is still written to pData for those queries if
> > > > VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set."
> > > >
> > > > Signed-off-by: Samuel Iglesias Gonsálvez
> > > > ---
> > > >src/amd/vulkan/radv_query.c | 15 +++
> > > >1 file changed, 3 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/src/amd/vulkan/radv_query.c
> > > > b/src/amd/vulkan/radv_query.c
> > > > index 8578680f09d..63a2ab773a8 100644
> > > > --- a/src/amd/vulkan/radv_query.c
> > > > +++ b/src/amd/vulkan/radv_query.c
> > > > @@ -1141,11 +1141,8 @@ VkResult radv_GetQueryPoolResults(
> > > > available = *(uint64_t *)src !=
> > > > TIMESTAMP_NOT_READY;
> > > > }
> > > >
> > > > - if (!available && !(flags &
> > > > VK_QUERY_RESULT_PARTIAL_BIT)) {
> > > > + if (!available && !(flags &
> > > > VK_QUERY_RESULT_PARTIAL_BIT))
> > > > result = VK_NOT_READY;
> > > > - break;
> > > > -
> > > > - }
> > > >
> > > > if (flags & VK_QUERY_RESULT_64_BIT) {
> > > > if (available || (flags &
> > > > VK_QUERY_RESULT_PARTIAL_BIT))
> >
Re: [Mesa-dev] [PATCH] anv: fix alphaToCoverage when there is no color attachment
On Fri, 2019-03-22 at 10:06 -0500, Jason Ekstrand wrote:
> I'm confused. Don't we always have a NULL render target at location
> 0? Is the problem really that we need the NULL render target or is
> it that we can't throw away the alpha component of the RT write in
> the shader?
It is the latter.
> If it's that we can't throw away the alpha component of the RT
> write, then I'd suggest a slightly different workaround which does
> just that. We can rewrite the store_output intrinsic (or store_var;
> not sure which it is at that point) so that it writes vec4(undef,
> undef, undef, alpha) to help with linking but then keep the one
> output var so it we still get the write in the shader.
>
OK, thanks for the suggestion!
Sam
>
> On Mon, Mar 4, 2019 at 4:56 AM Samuel Iglesias Gonsálvez <
> sigles...@igalia.com> wrote:
> > Still unreviewed.
> >
> > Sam
> >
> > On Thu, 2019-02-21 at 12:08 +0100, Samuel Iglesias Gonsálvez wrote:
> > > CL#3532 added a test for alpha to coverage without a color
> > > attachment.
> > > First the test draws a primitive with alpha 0 and a subpass with
> > only
> > > a depth buffer. No writes to a depth buffer are expected. Then a
> > > second draw with a color buffer and the same depth buffer is done
> > to
> > > verify the depth buffer still has the original clear values.
> > >
> > > This behavior is not explicitly forbidden by the Vulkan spec, so
> > > it seems it is allowed.
> > >
> > > When there is no color attachment for a given output, we discard
> > it
> > > so at the end we have an FS assembly like:
> > >
> > > Native code for unnamed fragment shader (null)
> > > SIMD16 shader: 1 instructions. 0 loops. 4 cycles. 0:0
> > spills:fills.
> > > Promoted 0 constants. Compacted 16 to 16 bytes (0%)
> > >START B0 (4 cycles)
> > > sendc(16) null<1>UW g120<0,1,0>F0x90031000
> > >
> > > render MsgDesc: RT write SIMD16 LastRT Surface = 0 mlen 8 rlen 0
> > {
> > > align1 1H EOT };
> > >
> > > As g120 is not initialized, we see random writes to the depth
> > buffer
> > > due to the alphaToCoverage enablement. This commit fixes that by
> > > keeping the output and creating a null render target for it.
> > >
> > > Fixes tests:
> > >
> > > dEQP-
> > VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
> > >
> > > Signed-off-by: Samuel Iglesias Gonsálvez
> > > ---
> > > src/intel/vulkan/anv_pipeline.c | 35 +
> >
> > >
> > > 1 file changed, 27 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/src/intel/vulkan/anv_pipeline.c
> > > b/src/intel/vulkan/anv_pipeline.c
> > > index e2024212bd9..70a958bf3a8 100644
> > > --- a/src/intel/vulkan/anv_pipeline.c
> > > +++ b/src/intel/vulkan/anv_pipeline.c
> > > @@ -792,7 +792,9 @@ anv_pipeline_compile_gs(const struct
> > brw_compiler
> > > *compiler,
> > >
> > > static void
> > > anv_pipeline_link_fs(const struct brw_compiler *compiler,
> > > - struct anv_pipeline_stage *stage)
> > > + struct anv_pipeline_stage *stage,
> > > + const struct anv_subpass *subpass,
> > > + const VkPipelineMultisampleStateCreateInfo
> > > *ms_info)
> > > {
> > > unsigned num_rts = 0;
> > > const int max_rt = FRAG_RESULT_DATA7 - FRAG_RESULT_DATA0 + 1;
> > > @@ -843,12 +845,28 @@ anv_pipeline_link_fs(const struct
> > brw_compiler
> > > *compiler,
> > >const unsigned rt = var->data.location -
> > FRAG_RESULT_DATA0;
> > >if (rt >= MAX_RTS ||
> > >!(stage->key.wm.color_outputs_valid & (1 << rt))) {
> > > - /* Unused or out-of-bounds, throw it away */
> > > - deleted_output = true;
> > > - var->data.mode = nir_var_function_temp;
> > > - exec_node_remove(>node);
> > > - exec_list_push_tail(>locals, >node);
> > > - continue;
> > > + if (rt == 0 && ms_info && ms_info-
> > >alphaToCoverageEnable &&
> > > + subpass->depth_stencil_attachment &&
> > rt_to_bindings[rt]
> > > == -1) {
> > > +/* Don't throw away the unused output, because we
> > needed
>
Re: [Mesa-dev] [PATCH 2/2] radv: write availability status vkGetQueryPoolResults() when the data is not available
On Fri, 2019-03-22 at 17:21 +0100, Samuel Pitoiset wrote:
> Does this fix anything known?
>
I am writing CTS tests for VK_EXT_host_query_reset extension and I
found this bug while testing them on RADV.
> Does that rule also apply for CmdCopyQueryPoolResults()? If so, we
> might
> need to fix it (I haven't looked yet).
>
The rule is slightly different on CmdCopyQueryPoolResults():
"Similarly, if VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set and
VK_QUERY_RESULT_WAIT_BIT is not set, the availability is guaranteed to
reflect the most recent use of the query on the same queue, assuming
that the query is not being simultaneously used by other queues. As
with vkGetQueryPoolResults, implementations must guarantee that if they
return a non-zero availability value, then the numerical results are
valid."
So if VK_QUERY_RESULT_WITH_AVAILABILITY_BIT we need to still set the
availability state.
I skimmed the implementation of this function on RADV, it seems it is
missing setting the availability value for all the queries except for
VK_QUERY_TYPE_TIMESTAMP.
Could you take care of this?
> With the comment on patch 1, series is:
>
> Reviewed-by: Samuel Pitoiset
>
OK, thanks! It seems I did a wrong squash of patches on patch 1. I will
fix it and push both patches to master.
Sam
> On 3/22/19 1:03 PM, Samuel Iglesias Gonsálvez wrote:
> > If VK_QUERY_RESULT_WITH_AVAILABILY_BIT is set and
> > VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are both
> > not
> > set, we need return to VK_NOT_READY only and set the availability
> > status field for each query.
> >
> > From Vulkan spec:
> >
> > "If VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are
> > both
> > not set then no result values are written to pData for queries that
> > are
> > in the unavailable state at the time of the call, and
> > vkGetQueryPoolResults returns VK_NOT_READY. However, availability
> > state
> > is still written to pData for those queries if
> > VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set."
> >
> > Signed-off-by: Samuel Iglesias Gonsálvez
> > ---
> > src/amd/vulkan/radv_query.c | 15 +++
> > 1 file changed, 3 insertions(+), 12 deletions(-)
> >
> > diff --git a/src/amd/vulkan/radv_query.c
> > b/src/amd/vulkan/radv_query.c
> > index 8578680f09d..63a2ab773a8 100644
> > --- a/src/amd/vulkan/radv_query.c
> > +++ b/src/amd/vulkan/radv_query.c
> > @@ -1141,11 +1141,8 @@ VkResult radv_GetQueryPoolResults(
> > available = *(uint64_t *)src !=
> > TIMESTAMP_NOT_READY;
> > }
> >
> > - if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT)) {
> > + if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT))
> > result = VK_NOT_READY;
> > - break;
> > -
> > - }
> >
> > if (flags & VK_QUERY_RESULT_64_BIT) {
> > if (available || (flags &
> > VK_QUERY_RESULT_PARTIAL_BIT))
> > @@ -1178,11 +1175,8 @@ VkResult radv_GetQueryPoolResults(
> > }
> > }
> >
> > - if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT)) {
> > + if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT))
> > result = VK_NOT_READY;
> > - break;
> > -
> > - }
> >
> > if (flags & VK_QUERY_RESULT_64_BIT) {
> > if (available || (flags &
> > VK_QUERY_RESULT_PARTIAL_BIT))
> > @@ -1196,11 +1190,8 @@ VkResult radv_GetQueryPoolResults(
> > break;
> > }
> > case VK_QUERY_TYPE_PIPELINE_STATISTICS: {
> > - if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT)) {
> > + if (!available && !(flags &
> > VK_QUERY_RESULT_PARTIAL_BIT))
> > result = VK_NOT_READY;
> > - break;
> > -
> > - }
> >
> > const uint64_t *start = (uint64_t*)src;
> > const uint64_t *stop = (uint64_t*)(src +
> > pipelinestat_block_size);
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] radv: write availability status vkGetQueryPoolResults() when the data is not available
If VK_QUERY_RESULT_WITH_AVAILABILY_BIT is set and
VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are both not
set, we need return to VK_NOT_READY only and set the availability
status field for each query.
From Vulkan spec:
"If VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are both
not set then no result values are written to pData for queries that are
in the unavailable state at the time of the call, and
vkGetQueryPoolResults returns VK_NOT_READY. However, availability state
is still written to pData for those queries if
VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set."
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/amd/vulkan/radv_query.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index 8578680f09d..63a2ab773a8 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1141,11 +1141,8 @@ VkResult radv_GetQueryPoolResults(
available = *(uint64_t *)src !=
TIMESTAMP_NOT_READY;
}
- if (!available && !(flags &
VK_QUERY_RESULT_PARTIAL_BIT)) {
+ if (!available && !(flags &
VK_QUERY_RESULT_PARTIAL_BIT))
result = VK_NOT_READY;
- break;
-
- }
if (flags & VK_QUERY_RESULT_64_BIT) {
if (available || (flags &
VK_QUERY_RESULT_PARTIAL_BIT))
@@ -1178,11 +1175,8 @@ VkResult radv_GetQueryPoolResults(
}
}
- if (!available && !(flags &
VK_QUERY_RESULT_PARTIAL_BIT)) {
+ if (!available && !(flags &
VK_QUERY_RESULT_PARTIAL_BIT))
result = VK_NOT_READY;
- break;
-
- }
if (flags & VK_QUERY_RESULT_64_BIT) {
if (available || (flags &
VK_QUERY_RESULT_PARTIAL_BIT))
@@ -1196,11 +1190,8 @@ VkResult radv_GetQueryPoolResults(
break;
}
case VK_QUERY_TYPE_PIPELINE_STATISTICS: {
- if (!available && !(flags &
VK_QUERY_RESULT_PARTIAL_BIT)) {
+ if (!available && !(flags &
VK_QUERY_RESULT_PARTIAL_BIT))
result = VK_NOT_READY;
- break;
-
- }
const uint64_t *start = (uint64_t*)src;
const uint64_t *stop = (uint64_t*)(src +
pipelinestat_block_size);
--
2.20.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radv: don't overwrite results in VkGetQueryPoolResults() when queries are not available
If the query is not available and VK_QUERY_RESULT_WAIT_BIT and
VK_QUERY_RESULT_PARTIAL_BIT are both not set, the spec doesn't
allow to modify its result.
From Vulkan spec:
"If VK_QUERY_RESULT_WAIT_BIT and VK_QUERY_RESULT_PARTIAL_BIT are
both not set then no result values are written to pData for queries
that are in the unavailable state at the time of the call, and
vkGetQueryPoolResults returns VK_NOT_READY. However, availability state
is still written to pData for those queries
if VK_QUERY_RESULT_WITH_AVAILABILITY_BIT is set."
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/amd/vulkan/radv_query.c | 52 +++--
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/src/amd/vulkan/radv_query.c b/src/amd/vulkan/radv_query.c
index e808aa65170..8578680f09d 100644
--- a/src/amd/vulkan/radv_query.c
+++ b/src/amd/vulkan/radv_query.c
@@ -1148,10 +1148,12 @@ VkResult radv_GetQueryPoolResults(
}
if (flags & VK_QUERY_RESULT_64_BIT) {
- *(uint64_t*)dest = *(uint64_t*)src;
+ if (available || (flags &
VK_QUERY_RESULT_PARTIAL_BIT))
+ *(uint64_t*)dest = *(uint64_t*)src;
dest += 8;
} else {
- *(uint32_t*)dest = *(uint32_t*)src;
+ if (available || (flags &
VK_QUERY_RESULT_PARTIAL_BIT))
+ *(uint32_t*)dest = *(uint32_t*)src;
dest += 4;
}
break;
@@ -1183,10 +1185,12 @@ VkResult radv_GetQueryPoolResults(
}
if (flags & VK_QUERY_RESULT_64_BIT) {
- *(uint64_t*)dest = sample_count;
+ if (available || (flags &
VK_QUERY_RESULT_PARTIAL_BIT))
+ *(uint64_t*)dest = sample_count;
dest += 8;
} else {
- *(uint32_t*)dest = sample_count;
+ if (available || (flags &
VK_QUERY_RESULT_PARTIAL_BIT))
+ *(uint32_t*)dest = sample_count;
dest += 4;
}
break;
@@ -1203,18 +1207,26 @@ VkResult radv_GetQueryPoolResults(
if (flags & VK_QUERY_RESULT_64_BIT) {
uint64_t *dst = (uint64_t*)dest;
dest +=
util_bitcount(pool->pipeline_stats_mask) * 8;
- for(int i = 0; i < 11; ++i)
- if(pool->pipeline_stats_mask & (1u <<
i))
- *dst++ =
stop[pipeline_statistics_indices[i]] -
-
start[pipeline_statistics_indices[i]];
+ for(int i = 0; i < 11; ++i) {
+ if(pool->pipeline_stats_mask & (1u <<
i)) {
+ if (available || (flags &
VK_QUERY_RESULT_PARTIAL_BIT))
+ *dst =
stop[pipeline_statistics_indices[i]] -
+
start[pipeline_statistics_indices[i]];
+ dst++;
+ }
+ }
} else {
uint32_t *dst = (uint32_t*)dest;
dest +=
util_bitcount(pool->pipeline_stats_mask) * 4;
- for(int i = 0; i < 11; ++i)
- if(pool->pipeline_stats_mask & (1u <<
i))
- *dst++ =
stop[pipeline_statistics_indices[i]] -
-
start[pipeline_statistics_indices[i]];
+ for(int i = 0; i < 11; ++i) {
+ if(pool->pipeline_stats_mask & (1u <<
i)) {
+ if (available || (flags &
VK_QUERY_RESULT_PARTIAL_BIT))
+ *dst =
stop[pipeline_statistics_indices[i]] -
+
start[pipeline_statistics_indices[i]];
+ dst++;
+ }
+ }
}
break;
Re: [Mesa-dev] [PATCH] anv: Stop using VK_TRUE/FALSE
Reviewed-by: Samuel Iglesias Gonsálvez
Sam
On Tue, 2019-03-12 at 15:24 -0500, Jason Ekstrand wrote:
> We've been fairly inconsistent about this so we should really choose
> whether we're going to use VK_TRUE/FALSE or the C boolean
> values. The
> Vulkan #defines are set to 1 and 0 respectively so it's the same
> value
> as C gives you when you cast a boolean expression to an
> integer. Since
> there are several places where we set a VkBool32 to a C logical
> expression, let's just embrace C booleans and stop using the VK
> defines.
> ---
> src/intel/vulkan/anv_device.c | 42 +--
>
> 1 file changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_device.c
> b/src/intel/vulkan/anv_device.c
> index 729cceb3e32..83fa3936c19 100644
> --- a/src/intel/vulkan/anv_device.c
> +++ b/src/intel/vulkan/anv_device.c
> @@ -833,7 +833,7 @@ VkResult anv_EnumeratePhysicalDeviceGroups(
>memset(p->physicalDevices, 0, sizeof(p->physicalDevices));
>p->physicalDevices[0] =
> anv_physical_device_to_handle(>physicalDevice);
> - p->subsetAllocation = VK_FALSE;
> + p->subsetAllocation = false;
>
>vk_foreach_struct(ext, p->pNext)
> anv_debug_ignored_stype(ext->sType);
> @@ -967,7 +967,7 @@ void anv_GetPhysicalDeviceFeatures2(
>case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_DEPTH_CLIP_ENABLE_FEATURES_EXT: {
> VkPhysicalDeviceDepthClipEnableFeaturesEXT *features =
> (VkPhysicalDeviceDepthClipEnableFeaturesEXT *)ext;
> - features->depthClipEnable = VK_TRUE;
> + features->depthClipEnable = true;
> break;
>}
>
> @@ -990,7 +990,7 @@ void anv_GetPhysicalDeviceFeatures2(
>
>case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROTECTED_MEMORY_FEATURES: {
> VkPhysicalDeviceProtectedMemoryFeatures *features = (void
> *)ext;
> - features->protectedMemory = VK_FALSE;
> + features->protectedMemory = false;
> break;
>}
>
> @@ -1024,23 +1024,23 @@ void anv_GetPhysicalDeviceFeatures2(
>case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_FEATURES_EXT: {
> VkPhysicalDeviceTransformFeedbackFeaturesEXT *features =
> (VkPhysicalDeviceTransformFeedbackFeaturesEXT *)ext;
> - features->transformFeedback = VK_TRUE;
> - features->geometryStreams = VK_TRUE;
> + features->transformFeedback = true;
> + features->geometryStreams = true;
> break;
>}
>
>case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_FEATURES_E
> XT: {
> VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT *features
> =
> (VkPhysicalDeviceVertexAttributeDivisorFeaturesEXT
> *)ext;
> - features->vertexAttributeInstanceRateDivisor = VK_TRUE;
> - features->vertexAttributeInstanceRateZeroDivisor = VK_TRUE;
> + features->vertexAttributeInstanceRateDivisor = true;
> + features->vertexAttributeInstanceRateZeroDivisor = true;
> break;
>}
>
>case
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_YCBCR_IMAGE_ARRAYS_FEATURES_EXT: {
> VkPhysicalDeviceYcbcrImageArraysFeaturesEXT *features =
> (VkPhysicalDeviceYcbcrImageArraysFeaturesEXT *)ext;
> - features->ycbcrImageArrays = VK_TRUE;
> + features->ycbcrImageArrays = true;
> break;
>}
>
> @@ -1234,8 +1234,8 @@ void anv_GetPhysicalDeviceProperties2(
> VK_RESOLVE_MODE_MAX_BIT_KHR;
> }
>
> - props->independentResolveNone = VK_TRUE;
> - props->independentResolve = VK_TRUE;
> + props->independentResolveNone = true;
> + props->independentResolve = true;
> break;
>}
>
> @@ -1372,7 +1372,7 @@ void anv_GetPhysicalDeviceProperties2(
> VK_SUBGROUP_FEATURE_SHUFF
> LE_RELATIVE_BIT |
> VK_SUBGROUP_FEATURE_CLUST
> ERED_BIT |
> VK_SUBGROUP_FEATURE_QUAD_
> BIT;
> - properties->quadOperationsInAllStages = VK_TRUE;
> + properties->quadOperationsInAllStages = true;
> break;
>}
>
> @@ -1386,10 +1386,10 @@ void anv_GetPhysicalDeviceProperties2(
> props->maxTransformFeedbackStreamDataSize = 128 * 4;
> props->maxTransformFeedbackBufferDataSize = 128 * 4;
> props->maxTransformFeedbackBufferDataStride = 2048;
> -
Re: [Mesa-dev] [PATCH] anv: fix alphaToCoverage when there is no color attachment
Still unreviewed.
Sam
On Thu, 2019-02-21 at 12:08 +0100, Samuel Iglesias Gonsálvez wrote:
> CL#3532 added a test for alpha to coverage without a color
> attachment.
> First the test draws a primitive with alpha 0 and a subpass with only
> a depth buffer. No writes to a depth buffer are expected. Then a
> second draw with a color buffer and the same depth buffer is done to
> verify the depth buffer still has the original clear values.
>
> This behavior is not explicitly forbidden by the Vulkan spec, so
> it seems it is allowed.
>
> When there is no color attachment for a given output, we discard it
> so at the end we have an FS assembly like:
>
> Native code for unnamed fragment shader (null)
> SIMD16 shader: 1 instructions. 0 loops. 4 cycles. 0:0 spills:fills.
> Promoted 0 constants. Compacted 16 to 16 bytes (0%)
>START B0 (4 cycles)
> sendc(16) null<1>UW g120<0,1,0>F0x90031000
>
> render MsgDesc: RT write SIMD16 LastRT Surface = 0 mlen 8 rlen 0 {
> align1 1H EOT };
>
> As g120 is not initialized, we see random writes to the depth buffer
> due to the alphaToCoverage enablement. This commit fixes that by
> keeping the output and creating a null render target for it.
>
> Fixes tests:
>
> dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
>
> Signed-off-by: Samuel Iglesias Gonsálvez
> ---
> src/intel/vulkan/anv_pipeline.c | 35 +
>
> 1 file changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/src/intel/vulkan/anv_pipeline.c
> b/src/intel/vulkan/anv_pipeline.c
> index e2024212bd9..70a958bf3a8 100644
> --- a/src/intel/vulkan/anv_pipeline.c
> +++ b/src/intel/vulkan/anv_pipeline.c
> @@ -792,7 +792,9 @@ anv_pipeline_compile_gs(const struct brw_compiler
> *compiler,
>
> static void
> anv_pipeline_link_fs(const struct brw_compiler *compiler,
> - struct anv_pipeline_stage *stage)
> + struct anv_pipeline_stage *stage,
> + const struct anv_subpass *subpass,
> + const VkPipelineMultisampleStateCreateInfo
> *ms_info)
> {
> unsigned num_rts = 0;
> const int max_rt = FRAG_RESULT_DATA7 - FRAG_RESULT_DATA0 + 1;
> @@ -843,12 +845,28 @@ anv_pipeline_link_fs(const struct brw_compiler
> *compiler,
>const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
>if (rt >= MAX_RTS ||
>!(stage->key.wm.color_outputs_valid & (1 << rt))) {
> - /* Unused or out-of-bounds, throw it away */
> - deleted_output = true;
> - var->data.mode = nir_var_function_temp;
> - exec_node_remove(>node);
> - exec_list_push_tail(>locals, >node);
> - continue;
> + if (rt == 0 && ms_info && ms_info->alphaToCoverageEnable &&
> + subpass->depth_stencil_attachment && rt_to_bindings[rt]
> == -1) {
> +/* Don't throw away the unused output, because we needed
> it for
> + * calculate correctly the alpha to coverage samples
> when there
> + * is no color buffer attached at location 0.
> + */
> +rt_to_bindings[rt] = num_rts;
> +/* We need a null render target */
> +rt_bindings[rt_to_bindings[rt]] = (struct
> anv_pipeline_binding) {
> + .set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
> + .binding = 0,
> + .index = UINT32_MAX,
> +};
> +num_rts++;
> + } else {
> +/* Unused or out-of-bounds, throw it away */
> +deleted_output = true;
> +var->data.mode = nir_var_function_temp;
> +exec_node_remove(>node);
> +exec_list_push_tail(>locals, >node);
> +continue;
> + }
>}
>
>/* Give it the new location */
> @@ -1075,7 +1093,8 @@ anv_pipeline_compile_graphics(struct
> anv_pipeline *pipeline,
> anv_pipeline_link_gs(compiler, [s], next_stage);
> break;
>case MESA_SHADER_FRAGMENT:
> - anv_pipeline_link_fs(compiler, [s]);
> + anv_pipeline_link_fs(compiler, [s],
> + pipeline->subpass, info-
> >pMultisampleState);
> break;
>default:
> unreachable("Invalid graphics shader stage");
signature.asc
Description: This is a digitally signed message part
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] spirv: OpImageQueryLod requires a sampler
Reviewed-by: Samuel Iglesias Gonsálvez On Wed, 2019-02-27 at 00:15 -0600, Jason Ekstrand wrote: > No idea how this fell through the cracks besides the fact that the > sampler bound at 0 almost always works and the CTS isn't amazing. In > any case, this appears to have been broken for almost forever. > > Cc: mesa-sta...@lists.freedesktop.org > --- > src/compiler/spirv/spirv_to_nir.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/compiler/spirv/spirv_to_nir.c > b/src/compiler/spirv/spirv_to_nir.c > index f5511587be8..de5e6cc8659 100644 > --- a/src/compiler/spirv/spirv_to_nir.c > +++ b/src/compiler/spirv/spirv_to_nir.c > @@ -2154,6 +2154,7 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp > opcode, > case nir_texop_txl: > case nir_texop_txd: > case nir_texop_tg4: > + case nir_texop_lod: >/* These operations require a sampler */ >p->src = nir_src_for_ssa(>dest.ssa); >p->src_type = nir_tex_src_sampler_deref; > @@ -2162,7 +2163,6 @@ vtn_handle_texture(struct vtn_builder *b, SpvOp > opcode, > case nir_texop_txf: > case nir_texop_txf_ms: > case nir_texop_txs: > - case nir_texop_lod: > case nir_texop_query_levels: > case nir_texop_texture_samples: > case nir_texop_samples_identical: signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [MR] WIP: VK_KHR_shader_float_controls implementation on ANV
It is still unreviewed. Sam On 2/8/19 8:17 AM, Samuel Iglesias Gonsálvez wrote: > First three versions of this branch were sent for review to the mailing > list. In order to avoid flooding the list with more emails, I create > this MR to continue the review process there. > > Reminder: this patch series relies on VK_KHR_shader_float16_int8 patch > series which is currently under review. For that reason, I mark this > Merge Request as Work In Progress. > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/223 > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/2] isl: the display engine requires 64B alignment for linear surfaces
Lionel, are you going to push it with this quote? I can add it otherwise. Sam On Thu, 2019-02-21 at 13:41 +, Lionel Landwerlin wrote: > On 21/02/2019 13:30, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2019-02-21 12:57:09) > > > I did not find the PRM bit that says it must be 64b aligned, but > > > I can > > > see that's what i915 checks. > > > > > > Chris: If you have a pointer to it, I could add the quote. > > In amongst the register specs, > > PLANE_STRIDE: > > For Linear memory, this field specifies the stride in chunks of 64 > > bytes (1 cache line). > > -Chris > > > Thanks a lot! > > signature.asc Description: This is a digitally signed message part ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv: fix alphaToCoverage when there is no color attachment
CL#3532 added a test for alpha to coverage without a color attachment.
First the test draws a primitive with alpha 0 and a subpass with only
a depth buffer. No writes to a depth buffer are expected. Then a
second draw with a color buffer and the same depth buffer is done to
verify the depth buffer still has the original clear values.
This behavior is not explicitly forbidden by the Vulkan spec, so
it seems it is allowed.
When there is no color attachment for a given output, we discard it
so at the end we have an FS assembly like:
Native code for unnamed fragment shader (null)
SIMD16 shader: 1 instructions. 0 loops. 4 cycles. 0:0 spills:fills.
Promoted 0 constants. Compacted 16 to 16 bytes (0%)
START B0 (4 cycles)
sendc(16) null<1>UW g120<0,1,0>F0x90031000
render MsgDesc: RT write SIMD16 LastRT Surface = 0 mlen 8 rlen 0 { align1 1H
EOT };
As g120 is not initialized, we see random writes to the depth buffer
due to the alphaToCoverage enablement. This commit fixes that by
keeping the output and creating a null render target for it.
Fixes tests:
dEQP-VK.pipeline.multisample.alpha_to_coverage_no_color_attachment.*
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/vulkan/anv_pipeline.c | 35 +
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c
index e2024212bd9..70a958bf3a8 100644
--- a/src/intel/vulkan/anv_pipeline.c
+++ b/src/intel/vulkan/anv_pipeline.c
@@ -792,7 +792,9 @@ anv_pipeline_compile_gs(const struct brw_compiler *compiler,
static void
anv_pipeline_link_fs(const struct brw_compiler *compiler,
- struct anv_pipeline_stage *stage)
+ struct anv_pipeline_stage *stage,
+ const struct anv_subpass *subpass,
+ const VkPipelineMultisampleStateCreateInfo *ms_info)
{
unsigned num_rts = 0;
const int max_rt = FRAG_RESULT_DATA7 - FRAG_RESULT_DATA0 + 1;
@@ -843,12 +845,28 @@ anv_pipeline_link_fs(const struct brw_compiler *compiler,
const unsigned rt = var->data.location - FRAG_RESULT_DATA0;
if (rt >= MAX_RTS ||
!(stage->key.wm.color_outputs_valid & (1 << rt))) {
- /* Unused or out-of-bounds, throw it away */
- deleted_output = true;
- var->data.mode = nir_var_function_temp;
- exec_node_remove(>node);
- exec_list_push_tail(>locals, >node);
- continue;
+ if (rt == 0 && ms_info && ms_info->alphaToCoverageEnable &&
+ subpass->depth_stencil_attachment && rt_to_bindings[rt] == -1) {
+/* Don't throw away the unused output, because we needed it for
+ * calculate correctly the alpha to coverage samples when there
+ * is no color buffer attached at location 0.
+ */
+rt_to_bindings[rt] = num_rts;
+/* We need a null render target */
+rt_bindings[rt_to_bindings[rt]] = (struct anv_pipeline_binding) {
+ .set = ANV_DESCRIPTOR_SET_COLOR_ATTACHMENTS,
+ .binding = 0,
+ .index = UINT32_MAX,
+};
+num_rts++;
+ } else {
+/* Unused or out-of-bounds, throw it away */
+deleted_output = true;
+var->data.mode = nir_var_function_temp;
+exec_node_remove(>node);
+exec_list_push_tail(>locals, >node);
+continue;
+ }
}
/* Give it the new location */
@@ -1075,7 +1093,8 @@ anv_pipeline_compile_graphics(struct anv_pipeline
*pipeline,
anv_pipeline_link_gs(compiler, [s], next_stage);
break;
case MESA_SHADER_FRAGMENT:
- anv_pipeline_link_fs(compiler, [s]);
+ anv_pipeline_link_fs(compiler, [s],
+ pipeline->subpass, info->pMultisampleState);
break;
default:
unreachable("Invalid graphics shader stage");
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/2] isl: remove the cache line size alignment requirement
The cacheline size was a requirement for using the BLT engine, which
we don't use anymore except for a few things on old HW, so we drop it.
Fixes CTS's CL#3500 test:
dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.r8g8b8_unorm
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/isl/isl.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index eaaa28014a3..5c34efb9a13 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1381,20 +1381,6 @@ isl_calc_row_pitch(const struct isl_device *dev,
uint32_t alignment_B =
isl_calc_row_pitch_alignment(surf_info, tile_info);
- /* If pitch isn't given and it can be chosen freely, align it by cache line
-* allowing one to use blit engine on the surface.
-*/
- if (surf_info->row_pitch_B == 0 && tile_info->tiling == ISL_TILING_LINEAR) {
- /* From the Broadwell PRM docs for XY_SRC_COPY_BLT::SourceBaseAddress:
- *
- *"Base address of the destination surface: X=0, Y=0. Lower 32bits
- *of the 48bit addressing. When Src Tiling is enabled (Bit_15
- *enabled), this address must be 4KB-aligned. When Tiling is not
- *enabled, this address should be CL (64byte) aligned."
- */
- alignment_B = MAX2(alignment_B, 64);
- }
-
const uint32_t min_row_pitch_B =
isl_calc_min_row_pitch(dev, surf_info, tile_info, phys_total_el,
alignment_B);
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/2] isl: the display engine requires 64B alignment for linear surfaces
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/isl/isl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index 5c34efb9a13..7fb469687fa 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1519,6 +1519,9 @@ isl_surf_init_s(const struct isl_device *dev,
}
}
base_alignment_B = isl_round_up_to_power_of_two(base_alignment_B);
+ /* The display engine requires 64B alignment for linear surfaces. */
+ if (isl_surf_usage_is_display(info->usage))
+ base_alignment_B = MAX(base_alignment_B, 64);
} else {
const uint32_t total_h_tl =
isl_align_div(phys_total_el.h, tile_info.logical_extent_el.height);
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] anv/image: fix offset's alignment to the surface alignment
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/vulkan/anv_image.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 3999c7399d0..f4a65044a3b 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -142,7 +142,7 @@ add_surface(struct anv_image *image, struct anv_surface
*surf, uint32_t plane)
surf->isl.alignment_B);
/* Plane offset is always 0 when it's disjoint. */
} else {
- surf->offset = align_u32(image->size, surf->isl.alignment_B);
+ surf->offset = util_align_npot(image->size, surf->isl.alignment_B);
/* Determine plane's offset only once when the first surface is added. */
if (image->planes[plane].size == 0)
image->planes[plane].offset = image->size;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] isl: remove the cache line size alignment requirement
There are formats which bpp are not aligned to a power-of-two and
that can cause problems in the checks we do.
The cacheline size was a requirement for using the BLT engine, which
we don't use anymore except for a few things on old HW, so we drop it.
Fixes CTS's CL#3500 test:
dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.r8g8b8_unorm
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/isl/isl.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index eaaa28014a3..7f1f2339931 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1381,20 +1381,6 @@ isl_calc_row_pitch(const struct isl_device *dev,
uint32_t alignment_B =
isl_calc_row_pitch_alignment(surf_info, tile_info);
- /* If pitch isn't given and it can be chosen freely, align it by cache line
-* allowing one to use blit engine on the surface.
-*/
- if (surf_info->row_pitch_B == 0 && tile_info->tiling == ISL_TILING_LINEAR) {
- /* From the Broadwell PRM docs for XY_SRC_COPY_BLT::SourceBaseAddress:
- *
- *"Base address of the destination surface: X=0, Y=0. Lower 32bits
- *of the 48bit addressing. When Src Tiling is enabled (Bit_15
- *enabled), this address must be 4KB-aligned. When Tiling is not
- *enabled, this address should be CL (64byte) aligned."
- */
- alignment_B = MAX2(alignment_B, 64);
- }
-
const uint32_t min_row_pitch_B =
isl_calc_min_row_pitch(dev, surf_info, tile_info, phys_total_el,
alignment_B);
@@ -1527,12 +1513,13 @@ isl_surf_init_s(const struct isl_device *dev,
base_alignment_B = MAX(1, info->min_alignment_B);
if (info->usage & ISL_SURF_USAGE_RENDER_TARGET_BIT) {
if (isl_format_is_yuv(info->format)) {
-base_alignment_B = MAX(base_alignment_B, fmtl->bpb / 4);
+base_alignment_B = isl_align_npot(base_alignment_B, fmtl->bpb / 4);
} else {
-base_alignment_B = MAX(base_alignment_B, fmtl->bpb / 8);
+base_alignment_B = isl_align_npot(base_alignment_B, fmtl->bpb / 8);
}
+ } else {
+ base_alignment_B = isl_round_up_to_power_of_two(base_alignment_B);
}
- base_alignment_B = isl_round_up_to_power_of_two(base_alignment_B);
} else {
const uint32_t total_h_tl =
isl_align_div(phys_total_el.h, tile_info.logical_extent_el.height);
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] isl: remove the cache line size alignment requirement
There are formats which bpp are not aligned to a power-of-two and
that can cause problems in the checks we do.
The cacheline size was a requirement for using the BLT engine, which
we don't use anymore except for a few things on old HW, so we drop it.
Fixes CTS's CL#3500 test:
dEQP-VK.api.image_clearing.core.clear_color_image.2d.linear.single_layer.r8g8b8_unorm
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/isl/isl.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/src/intel/isl/isl.c b/src/intel/isl/isl.c
index eaaa28014a3..7f1f2339931 100644
--- a/src/intel/isl/isl.c
+++ b/src/intel/isl/isl.c
@@ -1381,20 +1381,6 @@ isl_calc_row_pitch(const struct isl_device *dev,
uint32_t alignment_B =
isl_calc_row_pitch_alignment(surf_info, tile_info);
- /* If pitch isn't given and it can be chosen freely, align it by cache line
-* allowing one to use blit engine on the surface.
-*/
- if (surf_info->row_pitch_B == 0 && tile_info->tiling == ISL_TILING_LINEAR) {
- /* From the Broadwell PRM docs for XY_SRC_COPY_BLT::SourceBaseAddress:
- *
- *"Base address of the destination surface: X=0, Y=0. Lower 32bits
- *of the 48bit addressing. When Src Tiling is enabled (Bit_15
- *enabled), this address must be 4KB-aligned. When Tiling is not
- *enabled, this address should be CL (64byte) aligned."
- */
- alignment_B = MAX2(alignment_B, 64);
- }
-
const uint32_t min_row_pitch_B =
isl_calc_min_row_pitch(dev, surf_info, tile_info, phys_total_el,
alignment_B);
@@ -1527,12 +1513,13 @@ isl_surf_init_s(const struct isl_device *dev,
base_alignment_B = MAX(1, info->min_alignment_B);
if (info->usage & ISL_SURF_USAGE_RENDER_TARGET_BIT) {
if (isl_format_is_yuv(info->format)) {
-base_alignment_B = MAX(base_alignment_B, fmtl->bpb / 4);
+base_alignment_B = isl_align_npot(base_alignment_B, fmtl->bpb / 4);
} else {
-base_alignment_B = MAX(base_alignment_B, fmtl->bpb / 8);
+base_alignment_B = isl_align_npot(base_alignment_B, fmtl->bpb / 8);
}
+ } else {
+ base_alignment_B = isl_round_up_to_power_of_two(base_alignment_B);
}
- base_alignment_B = isl_round_up_to_power_of_two(base_alignment_B);
} else {
const uint32_t total_h_tl =
isl_align_div(phys_total_el.h, tile_info.logical_extent_el.height);
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] anv/image: fix offset's alignment to the surface alignment
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/vulkan/anv_image.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_image.c b/src/intel/vulkan/anv_image.c
index 3999c7399d0..f4a65044a3b 100644
--- a/src/intel/vulkan/anv_image.c
+++ b/src/intel/vulkan/anv_image.c
@@ -142,7 +142,7 @@ add_surface(struct anv_image *image, struct anv_surface
*surf, uint32_t plane)
surf->isl.alignment_B);
/* Plane offset is always 0 when it's disjoint. */
} else {
- surf->offset = align_u32(image->size, surf->isl.alignment_B);
+ surf->offset = util_align_npot(image->size, surf->isl.alignment_B);
/* Determine plane's offset only once when the first surface is added. */
if (image->planes[plane].size == 0)
image->planes[plane].offset = image->size;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 12/44] nir: add new fadd, fsub, fmul opcodes taking into account rounding mode
On 2/6/19 12:47 PM, Connor Abbott wrote:
>
>
> On Wed, Feb 6, 2019 at 11:46 AM Samuel Iglesias Gonsálvez
> mailto:sigles...@igalia.com>> wrote:
>
> According to Vulkan spec, the new execution modes affect only
> correctly rounded SPIR-V instructions, which includes fadd,
> fsub and fmul.
>
> Signed-off-by: Samuel Iglesias Gonsálvez <mailto:sigles...@igalia.com>>
> ---
> src/compiler/nir/nir_opcodes.py | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/src/compiler/nir/nir_opcodes.py
> b/src/compiler/nir/nir_opcodes.py
> index f8997444c28..7b45d38f460 100644
> --- a/src/compiler/nir/nir_opcodes.py
> +++ b/src/compiler/nir/nir_opcodes.py
> @@ -453,9 +453,15 @@ def binop_convert(name, out_type, in_type,
> alg_props, const_expr):
> opcode(name, 0, out_type, [0, 0], [in_type, in_type],
> False, alg_props, const_expr, "")
>
> +def binop_convert_rounding_mode(name, out_type, in_type, alg_props,
> const_expr, rounding_mode):
> + opcode(name, 0, out_type, [0, 0], [in_type, in_type], False,
> alg_props, const_expr, rounding_mode)
> +
> def binop(name, ty, alg_props, const_expr):
> binop_convert(name, ty, ty, alg_props, const_expr)
>
> +def binop_rounding_mode(name, ty, alg_props, const_expr,
> rounding_mode):
> + binop_convert_rounding_mode(name, ty, ty, alg_props, const_expr,
> rounding_mode)
> +
> def binop_compare(name, ty, alg_props, const_expr):
> binop_convert(name, tbool1, ty, alg_props, const_expr)
>
> @@ -490,13 +496,24 @@ def binop_reduce(name, output_size,
> output_type, src_type, prereduce_expr,
> final(reduce_(reduce_(src0, src1), reduce_(src2, src3))), "")
>
> binop("fadd", tfloat, commutative + associative, "src0 + src1")
> +binop_rounding_mode("fadd_rtne", tfloat, commutative + associative,
> + "_mesa_roundeven(src0 + src1)", "_rtne")
>
>
> There are two things wrong here:
> - The default floating-point environment, and the one Mesa expects, does
> round-to-nearest-even so it's rtz that needs special handling.
> - _mesa_roundeven here is a no-op (it'll implicitly expand to a double
> and then convert back to a float). The rounding actually happens as part
> of the addition itself. I'm not sure if adding as double (with
> round-to-nearest-even) and then rounding back to a float will work, but
> that definitely won't work for doubles. I think you'll have to implement
> round-to-zero addition yourself, or fiddle with the CPU's floating-point
> environment.
>
> The same goes multiply and fma.
>
In order to avoid flooding the ML with more patches, I created a MR with
the suggested changes:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/223
Please take a look at them and let me know if now it is fine.
Thanks,
Sam
>
> +binop_rounding_mode("fadd_rtz", tfloat, commutative + associative,
> "src0 + src1", "_rtz")
> +
> binop("iadd", tint, commutative + associative, "src0 + src1")
> binop("uadd_sat", tuint, commutative,
> "(src0 + src1) < src0 ? UINT64_MAX : (src0 + src1)")
> binop("fsub", tfloat, "", "src0 - src1")
> +binop_rounding_mode("fsub_rtne", tfloat, "",
> + "_mesa_roundeven(src0 - src1)", "_rtne")
> +binop_rounding_mode("fsub_rtz", tfloat, "", "src0 - src1", "_rtz")
> binop("isub", tint, "", "src0 - src1")
>
> binop("fmul", tfloat, commutative + associative, "src0 * src1")
> +binop_rounding_mode("fmul_rtne", tfloat, commutative + associative,
> + "_mesa_roundeven(src0 * src1)", "_rtne")
> +binop_rounding_mode("fmul_rtz", tfloat, commutative + associative,
> "src0 * src1", "_rtz")
> +
> # low 32-bits of signed/unsigned integer multiply
> binop("imul", tint, commutative + associative, "src0 * src1")
>
> --
> 2.19.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org <mailto:mesa-dev@lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [MR] WIP: VK_KHR_shader_float_controls implementation on ANV
First three versions of this branch were sent for review to the mailing list. In order to avoid flooding the list with more emails, I create this MR to continue the review process there. Reminder: this patch series relies on VK_KHR_shader_float16_int8 patch series which is currently under review. For that reason, I mark this Merge Request as Work In Progress. https://gitlab.freedesktop.org/mesa/mesa/merge_requests/223 signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 12/44] nir: add new fadd, fsub, fmul opcodes taking into account rounding mode
On 2/6/19 12:47 PM, Connor Abbott wrote:
>
>
> On Wed, Feb 6, 2019 at 11:46 AM Samuel Iglesias Gonsálvez
> mailto:sigles...@igalia.com>> wrote:
>
> According to Vulkan spec, the new execution modes affect only
> correctly rounded SPIR-V instructions, which includes fadd,
> fsub and fmul.
>
> Signed-off-by: Samuel Iglesias Gonsálvez <mailto:sigles...@igalia.com>>
> ---
> src/compiler/nir/nir_opcodes.py | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/src/compiler/nir/nir_opcodes.py
> b/src/compiler/nir/nir_opcodes.py
> index f8997444c28..7b45d38f460 100644
> --- a/src/compiler/nir/nir_opcodes.py
> +++ b/src/compiler/nir/nir_opcodes.py
> @@ -453,9 +453,15 @@ def binop_convert(name, out_type, in_type,
> alg_props, const_expr):
> opcode(name, 0, out_type, [0, 0], [in_type, in_type],
> False, alg_props, const_expr, "")
>
> +def binop_convert_rounding_mode(name, out_type, in_type, alg_props,
> const_expr, rounding_mode):
> + opcode(name, 0, out_type, [0, 0], [in_type, in_type], False,
> alg_props, const_expr, rounding_mode)
> +
> def binop(name, ty, alg_props, const_expr):
> binop_convert(name, ty, ty, alg_props, const_expr)
>
> +def binop_rounding_mode(name, ty, alg_props, const_expr,
> rounding_mode):
> + binop_convert_rounding_mode(name, ty, ty, alg_props, const_expr,
> rounding_mode)
> +
> def binop_compare(name, ty, alg_props, const_expr):
> binop_convert(name, tbool1, ty, alg_props, const_expr)
>
> @@ -490,13 +496,24 @@ def binop_reduce(name, output_size,
> output_type, src_type, prereduce_expr,
> final(reduce_(reduce_(src0, src1), reduce_(src2, src3))), "")
>
> binop("fadd", tfloat, commutative + associative, "src0 + src1")
> +binop_rounding_mode("fadd_rtne", tfloat, commutative + associative,
> + "_mesa_roundeven(src0 + src1)", "_rtne")
>
>
> There are two things wrong here:
> - The default floating-point environment, and the one Mesa expects, does
> round-to-nearest-even so it's rtz that needs special handling.
> - _mesa_roundeven here is a no-op (it'll implicitly expand to a double
> and then convert back to a float). The rounding actually happens as part
> of the addition itself. I'm not sure if adding as double (with
> round-to-nearest-even) and then rounding back to a float will work, but
> that definitely won't work for doubles. I think you'll have to implement
> round-to-zero addition yourself, or fiddle with the CPU's floating-point
> environment.
>
> The same goes multiply and fma.
>
OK, thanks for the feedback. I will implement the needed RTZ ops and
send a new version.
Sam
>
> +binop_rounding_mode("fadd_rtz", tfloat, commutative + associative,
> "src0 + src1", "_rtz")
> +
> binop("iadd", tint, commutative + associative, "src0 + src1")
> binop("uadd_sat", tuint, commutative,
> "(src0 + src1) < src0 ? UINT64_MAX : (src0 + src1)")
> binop("fsub", tfloat, "", "src0 - src1")
> +binop_rounding_mode("fsub_rtne", tfloat, "",
> + "_mesa_roundeven(src0 - src1)", "_rtne")
> +binop_rounding_mode("fsub_rtz", tfloat, "", "src0 - src1", "_rtz")
> binop("isub", tint, "", "src0 - src1")
>
> binop("fmul", tfloat, commutative + associative, "src0 * src1")
> +binop_rounding_mode("fmul_rtne", tfloat, commutative + associative,
> + "_mesa_roundeven(src0 * src1)", "_rtne")
> +binop_rounding_mode("fmul_rtz", tfloat, commutative + associative,
> "src0 * src1", "_rtz")
> +
> # low 32-bits of signed/unsigned integer multiply
> binop("imul", tint, commutative + associative, "src0 * src1")
>
> --
> 2.19.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org <mailto:mesa-dev@lists.freedesktop.org>
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 42/44] anv: add support for VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/vulkan/anv_device.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 6b272ecf558..3d5ffa641a0 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1298,6 +1298,37 @@ void anv_GetPhysicalDeviceProperties2(
properties->quadOperationsInAllStages = VK_TRUE;
break;
}
+ case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR : {
+ VkPhysicalDeviceFloatControlsPropertiesKHR *properties = (void *)ext;
+ properties->separateDenormSettings = true;
+ properties->separateRoundingModeSettings = false;
+
+ /* Broadwell does not support HF denorms and there are restrictions
+ * other gens. According to Kabylake's PRM:
+ *
+ * "math - Extended Math Function
+ * [...]
+ * Restriction : Half-float denorms are always retained."
+ */
+ properties->shaderDenormFlushToZeroFloat16 = false;
+ properties->shaderDenormPreserveFloat16 = pdevice->info.gen > 8;
+ properties->shaderRoundingModeRTEFloat16 = true;
+ properties->shaderRoundingModeRTZFloat16 = true;
+ properties->shaderSignedZeroInfNanPreserveFloat16 = true;
+
+ properties->shaderDenormFlushToZeroFloat32 = true;
+ properties->shaderDenormPreserveFloat32 = true;
+ properties->shaderRoundingModeRTEFloat32 = true;
+ properties->shaderRoundingModeRTZFloat32 = true;
+ properties->shaderSignedZeroInfNanPreserveFloat32 = true;
+
+ properties->shaderDenormFlushToZeroFloat64 = true;
+ properties->shaderDenormPreserveFloat64 = true;
+ properties->shaderRoundingModeRTEFloat64 = true;
+ properties->shaderRoundingModeRTZFloat64 = true;
+ properties->shaderSignedZeroInfNanPreserveFloat64 = true;
+ break;
+ }
case
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TRANSFORM_FEEDBACK_PROPERTIES_EXT: {
VkPhysicalDeviceTransformFeedbackPropertiesEXT *props =
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 44/44] anv: enable VK_KHR_shader_float_controls extension
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/vulkan/anv_extensions.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/intel/vulkan/anv_extensions.py
b/src/intel/vulkan/anv_extensions.py
index defe263b2fb..fb8e9d593a3 100644
--- a/src/intel/vulkan/anv_extensions.py
+++ b/src/intel/vulkan/anv_extensions.py
@@ -110,6 +110,7 @@ EXTENSIONS = [
Extension('VK_KHR_sampler_ycbcr_conversion', 1, True),
Extension('VK_KHR_shader_draw_parameters',1, True),
Extension('VK_KHR_shader_float16_int8', 1, 'device->info.gen
>= 8'),
+Extension('VK_KHR_shader_float_controls', 1, 'device->info.gen
>= 8'),
Extension('VK_KHR_storage_buffer_storage_class', 1, True),
Extension('VK_KHR_surface', 25,
'ANV_HAS_SURFACE'),
Extension('VK_KHR_swapchain',68,
'ANV_HAS_SURFACE'),
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 43/44] anv: enable support for SPV_KHR_shader_float_controls capabilities
Signed-off-by: Samuel Iglesias Gonsálvez --- src/intel/vulkan/anv_pipeline.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c index adc8bb4ddf5..1ee0e4d3e4e 100644 --- a/src/intel/vulkan/anv_pipeline.c +++ b/src/intel/vulkan/anv_pipeline.c @@ -148,6 +148,7 @@ anv_shader_compile_to_nir(struct anv_device *device, .min_lod = true, .multiview = true, .post_depth_coverage = pdevice->info.gen >= 9, + .shader_float_controls = pdevice->info.gen >= 8, .shader_viewport_index_layer = true, .stencil_export = pdevice->info.gen >= 9, .storage_8bit = pdevice->info.gen >= 8, -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 41/44] i965/fs: add support for shader float control to remove_extra_rounding_modes()
The remove_extra_rounding_modes() optimization will remove duplicated
rounding mode changes.
v2:
- Fix bug in the rounding mode change (Alejandro)
v3:
- Fix rounding modes.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs.cpp | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index dfa6176340a..a5f5566951c 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -3449,9 +3449,20 @@ bool
fs_visitor::remove_extra_rounding_modes()
{
bool progress = false;
+ unsigned execution_mode =
this->nir->info.shader_float_controls_execution_mode;
+
+ brw_rnd_mode base_mode = BRW_RND_MODE_UNSPECIFIED;
+ if ((execution_mode & SHADER_ROUNDING_MODE_RTE_FP16) ||
+ (execution_mode & SHADER_ROUNDING_MODE_RTE_FP32) ||
+ (execution_mode & SHADER_ROUNDING_MODE_RTE_FP64))
+ base_mode = BRW_RND_MODE_RTNE;
+ if ((execution_mode & SHADER_ROUNDING_MODE_RTZ_FP16) ||
+ (execution_mode & SHADER_ROUNDING_MODE_RTZ_FP32) ||
+ (execution_mode & SHADER_ROUNDING_MODE_RTZ_FP64))
+ base_mode = BRW_RND_MODE_RTZ;
foreach_block (block, cfg) {
- brw_rnd_mode prev_mode = BRW_RND_MODE_UNSPECIFIED;
+ brw_rnd_mode prev_mode = base_mode;
foreach_inst_in_block_safe (fs_inst, inst, block) {
if (inst->opcode == SHADER_OPCODE_RND_MODE) {
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 37/44] i965/fs: emit shader float controls execution modes as first instruction of shaders
Signed-off-by: Samuel Iglesias Gonsálvez --- src/intel/compiler/brw_fs.cpp | 11 +++ 1 file changed, 11 insertions(+) diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp index 809c7971c94..dfa6176340a 100644 --- a/src/intel/compiler/brw_fs.cpp +++ b/src/intel/compiler/brw_fs.cpp @@ -6661,6 +6661,8 @@ fs_visitor::run_vs() if (shader_time_index >= 0) emit_shader_time_begin(); + emit_shader_float_controls_execution_mode(); + emit_nir_code(); if (failed) @@ -6730,6 +6732,7 @@ fs_visitor::run_tcs_single_patch() brw_imm_ud(nir->info.tess.tcs_vertices_out), BRW_CONDITIONAL_L); bld.IF(BRW_PREDICATE_NORMAL); } + emit_shader_float_controls_execution_mode(); emit_nir_code(); @@ -6781,6 +6784,8 @@ fs_visitor::run_tes() if (shader_time_index >= 0) emit_shader_time_begin(); + emit_shader_float_controls_execution_mode(); + emit_nir_code(); if (failed) @@ -6830,6 +6835,8 @@ fs_visitor::run_gs() if (shader_time_index >= 0) emit_shader_time_begin(); + emit_shader_float_controls_execution_mode(); + emit_nir_code(); emit_gs_thread_end(); @@ -6920,6 +6927,8 @@ fs_visitor::run_fs(bool allow_spilling, bool do_rep_send) retype(dispatch_mask, BRW_REGISTER_TYPE_UW)); } + emit_shader_float_controls_execution_mode(); + emit_nir_code(); if (failed) @@ -6975,6 +6984,8 @@ fs_visitor::run_cs(unsigned min_dispatch_width) suboffset(retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UW), 1)); } + emit_shader_float_controls_execution_mode(); + emit_nir_code(); if (failed) -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 32/44] i965/fs: add nir_op_ffract_{rtne, rtz} support
According to the PRMs: "The frc instruction computes, component-wise, the truncate-to-minus-infinity fractional values of src0 and stores the results in dst. The results, in the range of [0.0, 1.0], are the fractional portion of the source data. The result is in the range [0.0, 1.0] irrespective of the rounding mode." Signed-off-by: Samuel Iglesias Gonsálvez --- src/intel/compiler/brw_fs_nir.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/intel/compiler/brw_fs_nir.cpp b/src/intel/compiler/brw_fs_nir.cpp index ac5067f7ecc..ef1ed9b7f0a 100644 --- a/src/intel/compiler/brw_fs_nir.cpp +++ b/src/intel/compiler/brw_fs_nir.cpp @@ -1301,6 +1301,8 @@ fs_visitor::nir_emit_alu(const fs_builder , nir_alu_instr *instr) inst = bld.RNDD(result, op[0]); inst->saturate = instr->dest.saturate; break; + case nir_op_ffract_rtne: + case nir_op_ffract_rtz: case nir_op_ffract: inst = bld.FRC(result, op[0]); inst->saturate = instr->dest.saturate; -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 36/44] i965/fs: define emit_shader_float_controls_execution_mode() and aux functions
We need this function to emit code that setups the control register later with
the defined execution mode for the shader.
v2:
- Fix bug in setting the default mode mask in brw_rnd_mode_from_nir()
- Fix support for rounding modes in brw_rnd_mode_from_nir()
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs.h | 1 +
src/intel/compiler/brw_fs_visitor.cpp | 56 +++
2 files changed, 57 insertions(+)
diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
index 68287bcdcea..e3e97183c50 100644
--- a/src/intel/compiler/brw_fs.h
+++ b/src/intel/compiler/brw_fs.h
@@ -186,6 +186,7 @@ public:
void emit_gen6_gather_wa(uint8_t wa, fs_reg dst);
fs_reg resolve_source_modifiers(const fs_reg );
void emit_discard_jump();
+ void emit_shader_float_controls_execution_mode();
bool opt_peephole_sel();
bool opt_peephole_csel();
bool opt_peephole_predicated_break();
diff --git a/src/intel/compiler/brw_fs_visitor.cpp
b/src/intel/compiler/brw_fs_visitor.cpp
index 51a0ca2374a..4e7c9093743 100644
--- a/src/intel/compiler/brw_fs_visitor.cpp
+++ b/src/intel/compiler/brw_fs_visitor.cpp
@@ -198,6 +198,62 @@ fs_visitor::emit_interpolation_setup_gen4()
abld.emit(SHADER_OPCODE_RCP, this->pixel_w, wpos_w);
}
+static unsigned
+brw_rnd_mode_from_nir(unsigned mode, unsigned *mask)
+{
+ unsigned brw_mode = 0;
+ *mask = 0;
+
+ if ((mode & SHADER_ROUNDING_MODE_RTZ_FP16) ||
+ (mode & SHADER_ROUNDING_MODE_RTZ_FP32) ||
+ (mode & SHADER_ROUNDING_MODE_RTZ_FP64)) {
+ brw_mode |= BRW_RND_MODE_RTZ << BRW_CR0_RND_MODE_SHIFT;
+ *mask |= BRW_CR0_RND_MODE_MASK;
+ }
+ if ((mode & SHADER_ROUNDING_MODE_RTE_FP16) ||
+ (mode & SHADER_ROUNDING_MODE_RTE_FP32) ||
+ (mode & SHADER_ROUNDING_MODE_RTE_FP64)) {
+ brw_mode |= BRW_RND_MODE_RTNE << BRW_CR0_RND_MODE_SHIFT;
+ *mask |= BRW_CR0_RND_MODE_MASK;
+ }
+ if (mode & SHADER_DENORM_PRESERVE_FP16) {
+ brw_mode |= BRW_CR0_FP16_DENORM_PRESERVE;
+ *mask |= BRW_CR0_FP16_DENORM_PRESERVE;
+ }
+ if (mode & SHADER_DENORM_PRESERVE_FP32) {
+ brw_mode |= BRW_CR0_FP32_DENORM_PRESERVE;
+ *mask |= BRW_CR0_FP32_DENORM_PRESERVE;
+ }
+ if (mode & SHADER_DENORM_PRESERVE_FP64) {
+ brw_mode |= BRW_CR0_FP64_DENORM_PRESERVE;
+ *mask |= BRW_CR0_FP64_DENORM_PRESERVE;
+ }
+ if (mode & SHADER_DENORM_FLUSH_TO_ZERO_FP16)
+ *mask |= BRW_CR0_FP16_DENORM_PRESERVE;
+ if (mode & SHADER_DENORM_FLUSH_TO_ZERO_FP32)
+ *mask |= BRW_CR0_FP32_DENORM_PRESERVE;
+ if (mode & SHADER_DENORM_FLUSH_TO_ZERO_FP64)
+ *mask |= BRW_CR0_FP64_DENORM_PRESERVE;
+ if (mode == SHADER_DEFAULT_FLOAT_CONTROL_MODE)
+ *mask |= BRW_CR0_FP_MODE_MASK;
+
+ return brw_mode;
+}
+
+void
+fs_visitor::emit_shader_float_controls_execution_mode()
+{
+ unsigned execution_mode =
this->nir->info.shader_float_controls_execution_mode;
+ if (execution_mode == SHADER_DEFAULT_FLOAT_CONTROL_MODE)
+ return;
+
+ fs_builder abld = bld.annotate("shader floats control execution mode");
+ unsigned mask = 0;
+ unsigned mode = brw_rnd_mode_from_nir(execution_mode, );
+ abld.emit(SHADER_OPCODE_FLOAT_CONTROL_MODE, bld.null_reg_ud(),
+ brw_imm_d(mode), brw_imm_d(mask));
+}
+
/** Emits the interpolation for the varying inputs. */
void
fs_visitor::emit_interpolation_setup_gen6()
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 38/44] i965/fs: set rounding mode when emitting affected conversion instructions
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs_nir.cpp | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 71e5a96e0a3..aab06a525bc 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -653,10 +653,15 @@ emit_find_msb_using_lzd(const fs_builder ,
}
static brw_rnd_mode
-brw_rnd_mode_from_nir_op (const nir_op op) {
+brw_rnd_mode_from_nir_op (const nir_op op)
+{
switch (op) {
+ case nir_op_f2f64_rtz:
+ case nir_op_f2f32_rtz:
case nir_op_f2f16_rtz:
return BRW_RND_MODE_RTZ;
+ case nir_op_f2f64_rtne:
+ case nir_op_f2f32_rtne:
case nir_op_f2f16_rtne:
return BRW_RND_MODE_RTNE;
default:
@@ -801,15 +806,11 @@ fs_visitor::nir_emit_alu(const fs_builder ,
nir_alu_instr *instr)
case nir_op_i2i64:
case nir_op_u2f64:
case nir_op_u2u64:
- case nir_op_f2f64_rtne:
- case nir_op_f2f64_rtz:
case nir_op_f2f64:
case nir_op_f2i64:
case nir_op_f2u64:
case nir_op_i2i32:
case nir_op_u2u32:
- case nir_op_f2f32_rtne:
- case nir_op_f2f32_rtz:
case nir_op_f2f32:
case nir_op_f2i32:
case nir_op_f2u32:
@@ -837,6 +838,17 @@ fs_visitor::nir_emit_alu(const fs_builder ,
nir_alu_instr *instr)
inst->saturate = instr->dest.saturate;
break;
+ case nir_op_f2f64_rtne:
+ case nir_op_f2f64_rtz:
+ case nir_op_f2f32_rtne:
+ case nir_op_f2f32_rtz:
+ bld.emit(SHADER_OPCODE_RND_MODE, bld.null_reg_ud(),
+ brw_imm_d(brw_rnd_mode_from_nir_op(instr->op)));
+
+ inst = bld.MOV(result, op[0]);
+ inst->saturate = instr->dest.saturate;
+ break;
+
case nir_op_fsign: {
assert(!instr->dest.saturate);
if (op[0].abs) {
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 33/44] i965/fs/nir: check that fdot*_{rtne, rtz} was properly lowered
Signed-off-by: Samuel Iglesias Gonsálvez --- src/intel/compiler/brw_fs_nir.cpp | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/intel/compiler/brw_fs_nir.cpp b/src/intel/compiler/brw_fs_nir.cpp index ef1ed9b7f0a..9dacff9785b 100644 --- a/src/intel/compiler/brw_fs_nir.cpp +++ b/src/intel/compiler/brw_fs_nir.cpp @@ -1200,6 +1200,12 @@ fs_visitor::nir_emit_alu(const fs_builder , nir_alu_instr *instr) case nir_op_fdot2: case nir_op_fdot3: case nir_op_fdot4: + case nir_op_fdot2_rtne: + case nir_op_fdot3_rtne: + case nir_op_fdot4_rtne: + case nir_op_fdot2_rtz: + case nir_op_fdot3_rtz: + case nir_op_fdot4_rtz: case nir_op_b32all_fequal2: case nir_op_b32all_iequal2: case nir_op_b32all_fequal3: -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 34/44] i965/fs/nir: add nir_op_unpack_half_2x16_split_*_flush_to_zero
The denorm mode is set in the control register, no need to do something else.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs_nir.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 9dacff9785b..71e5a96e0a3 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -1373,11 +1373,13 @@ fs_visitor::nir_emit_alu(const fs_builder ,
nir_alu_instr *instr)
unreachable("not reached: should be handled by lower_packing_builtins");
case nir_op_unpack_half_2x16_split_x:
+ case nir_op_unpack_half_2x16_split_x_flush_to_zero:
inst = bld.emit(BRW_OPCODE_F16TO32, result,
subscript(op[0], BRW_REGISTER_TYPE_UW, 0));
inst->saturate = instr->dest.saturate;
break;
case nir_op_unpack_half_2x16_split_y:
+ case nir_op_unpack_half_2x16_split_y_flush_to_zero:
inst = bld.emit(BRW_OPCODE_F16TO32, result,
subscript(op[0], BRW_REGISTER_TYPE_UW, 1));
inst->saturate = instr->dest.saturate;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 40/44] i965/fs: remove brw_rounding_mode() and use brw_float_controls_mode() instead
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_eu.h | 4 ---
src/intel/compiler/brw_eu_emit.c| 36 -
src/intel/compiler/brw_fs_generator.cpp | 13 +++--
3 files changed, 11 insertions(+), 42 deletions(-)
diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
index 2309d3b10d8..ae068964936 100644
--- a/src/intel/compiler/brw_eu.h
+++ b/src/intel/compiler/brw_eu.h
@@ -673,10 +673,6 @@ brw_broadcast(struct brw_codegen *p,
struct brw_reg src,
struct brw_reg idx);
-void
-brw_rounding_mode(struct brw_codegen *p,
- enum brw_rnd_mode mode);
-
void
brw_float_controls_mode(struct brw_codegen *p,
unsigned mode, unsigned mask);
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 9de829e85f0..84075155832 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -3665,42 +3665,6 @@ brw_WAIT(struct brw_codegen *p)
brw_inst_set_mask_control(devinfo, insn, BRW_MASK_DISABLE);
}
-/**
- * Changes the floating point rounding mode updating the control register
- * field defined at cr0.0[5-6] bits. This function supports the changes to
- * RTNE (00), RU (01), RD (10) and RTZ (11) rounding using bitwise operations.
- * Only RTNE and RTZ rounding are enabled at nir.
- */
-void
-brw_rounding_mode(struct brw_codegen *p,
- enum brw_rnd_mode mode)
-{
- const unsigned bits = mode << BRW_CR0_RND_MODE_SHIFT;
-
- if (bits != BRW_CR0_RND_MODE_MASK) {
- brw_inst *inst = brw_AND(p, brw_cr0_reg(0), brw_cr0_reg(0),
- brw_imm_ud(~BRW_CR0_RND_MODE_MASK));
- brw_inst_set_exec_size(p->devinfo, inst, BRW_EXECUTE_1);
-
- /* From the Skylake PRM, Volume 7, page 760:
- * "Implementation Restriction on Register Access: When the control
- * register is used as an explicit source and/or destination, hardware
- * does not ensure execution pipeline coherency. Software must set the
- * thread control field to ‘switch’ for an instruction that uses
- * control register as an explicit operand."
- */
- brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
-}
-
- if (bits) {
- brw_inst *inst = brw_OR(p, brw_cr0_reg(0), brw_cr0_reg(0),
- brw_imm_ud(bits));
- brw_inst_set_exec_size(p->devinfo, inst, BRW_EXECUTE_1);
- brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
- }
-}
-
-/* TODO: Refactor brw_rounding_mode() to use this. */
void
brw_float_controls_mode(struct brw_codegen *p,
unsigned mode, unsigned mask)
diff --git a/src/intel/compiler/brw_fs_generator.cpp
b/src/intel/compiler/brw_fs_generator.cpp
index fd6201f2220..418c3fee44d 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -2435,9 +2435,18 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
brw_DIM(p, dst, retype(src[0], BRW_REGISTER_TYPE_F));
break;
- case SHADER_OPCODE_RND_MODE:
+ case SHADER_OPCODE_RND_MODE: {
assert(src[0].file == BRW_IMMEDIATE_VALUE);
- brw_rounding_mode(p, (enum brw_rnd_mode) src[0].d);
+ /*
+ * Changes the floating point rounding mode updating the control
register
+ * field defined at cr0.0[5-6] bits. This function supports the
changes to
+ * RTNE (00), RU (01), RD (10) and RTZ (11) rounding using bitwise
operations.
+ * Only RTNE and RTZ rounding are enabled at nir.
+ */
+ enum brw_rnd_mode mode =
+(enum brw_rnd_mode) (src[0].d << BRW_CR0_RND_MODE_SHIFT);
+ brw_float_controls_mode(p, mode, BRW_CR0_RND_MODE_MASK);
+ }
break;
case SHADER_OPCODE_FLOAT_CONTROL_MODE:
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 35/44] i965/fs/generator: add support to set floating points modes in control register
v2:
- Fix bug in defining BRW_CR0_FP_MODE_MASK.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_eu.h | 4
src/intel/compiler/brw_eu_defines.h | 10 ++
src/intel/compiler/brw_eu_emit.c| 26 +
src/intel/compiler/brw_fs_generator.cpp | 8 +++-
src/intel/compiler/brw_shader.cpp | 3 +++
5 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
index 9f1ca769bd3..2309d3b10d8 100644
--- a/src/intel/compiler/brw_eu.h
+++ b/src/intel/compiler/brw_eu.h
@@ -677,6 +677,10 @@ void
brw_rounding_mode(struct brw_codegen *p,
enum brw_rnd_mode mode);
+void
+brw_float_controls_mode(struct brw_codegen *p,
+unsigned mode, unsigned mask);
+
/***
* brw_eu_util.c:
*/
diff --git a/src/intel/compiler/brw_eu_defines.h
b/src/intel/compiler/brw_eu_defines.h
index b7bd104be59..e256ca6d5c6 100644
--- a/src/intel/compiler/brw_eu_defines.h
+++ b/src/intel/compiler/brw_eu_defines.h
@@ -412,6 +412,7 @@ enum opcode {
SHADER_OPCODE_TYPED_SURFACE_WRITE_LOGICAL,
SHADER_OPCODE_RND_MODE,
+ SHADER_OPCODE_FLOAT_CONTROL_MODE,
/**
* Byte scattered write/read opcodes.
@@ -1312,6 +1313,15 @@ enum PACKED brw_rnd_mode {
BRW_RND_MODE_UNSPECIFIED, /* Unspecified rounding mode */
};
+#define BRW_CR0_FP64_DENORM_PRESERVE (1 << 6)
+#define BRW_CR0_FP32_DENORM_PRESERVE (1 << 7)
+#define BRW_CR0_FP16_DENORM_PRESERVE (1 << 10)
+
+#define BRW_CR0_FP_MODE_MASK (BRW_CR0_FP64_DENORM_PRESERVE | \
+ BRW_CR0_FP32_DENORM_PRESERVE | \
+ BRW_CR0_FP16_DENORM_PRESERVE | \
+ BRW_CR0_RND_MODE_MASK)
+
/* MDC_DS - Data Size Message Descriptor Control Field
* Skylake PRM, Volume 2d, page 129
*
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 54aa09ea652..9de829e85f0 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -3699,3 +3699,29 @@ brw_rounding_mode(struct brw_codegen *p,
brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
}
}
+
+/* TODO: Refactor brw_rounding_mode() to use this. */
+void
+brw_float_controls_mode(struct brw_codegen *p,
+unsigned mode, unsigned mask)
+{
+ brw_inst *inst = brw_AND(p, brw_cr0_reg(0), brw_cr0_reg(0),
+brw_imm_ud(~mask));
+ brw_inst_set_exec_size(p->devinfo, inst, BRW_EXECUTE_1);
+
+ /* From the Skylake PRM, Volume 7, page 760:
+* "Implementation Restriction on Register Access: When the control
+* register is used as an explicit source and/or destination, hardware
+* does not ensure execution pipeline coherency. Software must set the
+* thread control field to ‘switch’ for an instruction that uses
+* control register as an explicit operand."
+*/
+ brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
+
+ if (mode) {
+ brw_inst *inst_or = brw_OR(p, brw_cr0_reg(0), brw_cr0_reg(0),
+ brw_imm_ud(mode));
+ brw_inst_set_exec_size(p->devinfo, inst_or, BRW_EXECUTE_1);
+ brw_inst_set_thread_control(p->devinfo, inst_or, BRW_THREAD_SWITCH);
+ }
+}
diff --git a/src/intel/compiler/brw_fs_generator.cpp
b/src/intel/compiler/brw_fs_generator.cpp
index 37f8730f326..fd6201f2220 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -2437,7 +2437,13 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
case SHADER_OPCODE_RND_MODE:
assert(src[0].file == BRW_IMMEDIATE_VALUE);
- brw_rounding_mode(p, (brw_rnd_mode) src[0].d);
+ brw_rounding_mode(p, (enum brw_rnd_mode) src[0].d);
+ break;
+
+ case SHADER_OPCODE_FLOAT_CONTROL_MODE:
+ assert(src[0].file == BRW_IMMEDIATE_VALUE);
+ assert(src[1].file == BRW_IMMEDIATE_VALUE);
+ brw_float_controls_mode(p, src[0].d, src[1].d);
break;
default:
diff --git a/src/intel/compiler/brw_shader.cpp
b/src/intel/compiler/brw_shader.cpp
index 3c636c9d3a4..61abccfbcbe 100644
--- a/src/intel/compiler/brw_shader.cpp
+++ b/src/intel/compiler/brw_shader.cpp
@@ -505,6 +505,8 @@ brw_instruction_name(const struct gen_device_info *devinfo,
enum opcode op)
case SHADER_OPCODE_RND_MODE:
return "rnd_mode";
+ case SHADER_OPCODE_FLOAT_CONTROL_MODE:
+ return "float_control_mode";
}
unreachable("not reached");
@@ -1049,6 +1051,7 @@ backend_instruction::has_side_effects() const
case TCS_OPCODE_URB_WRITE:
case TCS_OPCODE_RELEASE_INPUT:
case SHADER_OPCODE_RND_MODE:
+ case SHADER_OPCODE_FLOAT_CON
[Mesa-dev] [PATCH v3 39/44] i965/fs: set rounding mode when emitting the respective fadd and fmul instructions
---
src/intel/compiler/brw_fs_nir.cpp | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index aab06a525bc..86ab8c48135 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -656,10 +656,14 @@ static brw_rnd_mode
brw_rnd_mode_from_nir_op (const nir_op op)
{
switch (op) {
+ case nir_op_fadd_rtz:
+ case nir_op_fmul_rtz:
case nir_op_f2f64_rtz:
case nir_op_f2f32_rtz:
case nir_op_f2f16_rtz:
return BRW_RND_MODE_RTZ;
+ case nir_op_fadd_rtne:
+ case nir_op_fmul_rtne:
case nir_op_f2f64_rtne:
case nir_op_f2f32_rtne:
case nir_op_f2f16_rtne:
@@ -1010,6 +1014,11 @@ fs_visitor::nir_emit_alu(const fs_builder ,
nir_alu_instr *instr)
inst->saturate = instr->dest.saturate;
break;
+ case nir_op_fadd_rtne:
+ case nir_op_fadd_rtz:
+ bld.emit(SHADER_OPCODE_RND_MODE, bld.null_reg_ud(),
+ brw_imm_d(brw_rnd_mode_from_nir_op(instr->op)));
+ /* fallthrough */
case nir_op_iadd:
case nir_op_fadd:
inst = bld.ADD(result, op[0], op[1]);
@@ -1021,6 +1030,11 @@ fs_visitor::nir_emit_alu(const fs_builder ,
nir_alu_instr *instr)
inst->saturate = true;
break;
+ case nir_op_fmul_rtne:
+ case nir_op_fmul_rtz:
+ bld.emit(SHADER_OPCODE_RND_MODE, bld.null_reg_ud(),
+ brw_imm_d(brw_rnd_mode_from_nir_op(instr->op)));
+ /* fallthrough */
case nir_op_fmul:
inst = bld.MUL(result, op[0], op[1]);
inst->saturate = instr->dest.saturate;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 30/44] intel/nir: call nir_opt_constant_folding before brw_nir_apply_trig_workarounds
If we have fsin or fcos trigonometric operations with constant values as inputs,
we will multiply the result by 0.7 in brw_nir_apply_trig_workarounds,
making the result wrong. Running nir_opt_constant_folding before, we will
calculate correctly the result for these trignometric ops.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_nir.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 1d62f2adde8..e797794bfb8 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -751,8 +751,10 @@ brw_preprocess_nir(const struct brw_compiler *compiler,
nir_shader *nir)
/* See also brw_nir_trig_workarounds.py */
if (compiler->precise_trig &&
- !(devinfo->gen >= 10 || devinfo->is_kabylake))
+ !(devinfo->gen >= 10 || devinfo->is_kabylake)) {
+ OPT(nir_opt_constant_folding);
OPT(brw_nir_apply_trig_workarounds);
+ }
static const nir_lower_tex_options tex_options = {
.lower_txp = ~0,
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 12/44] nir: add new fadd, fsub, fmul opcodes taking into account rounding mode
According to Vulkan spec, the new execution modes affect only
correctly rounded SPIR-V instructions, which includes fadd,
fsub and fmul.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_opcodes.py | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index f8997444c28..7b45d38f460 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -453,9 +453,15 @@ def binop_convert(name, out_type, in_type, alg_props,
const_expr):
opcode(name, 0, out_type, [0, 0], [in_type, in_type],
False, alg_props, const_expr, "")
+def binop_convert_rounding_mode(name, out_type, in_type, alg_props,
const_expr, rounding_mode):
+ opcode(name, 0, out_type, [0, 0], [in_type, in_type], False, alg_props,
const_expr, rounding_mode)
+
def binop(name, ty, alg_props, const_expr):
binop_convert(name, ty, ty, alg_props, const_expr)
+def binop_rounding_mode(name, ty, alg_props, const_expr, rounding_mode):
+ binop_convert_rounding_mode(name, ty, ty, alg_props, const_expr,
rounding_mode)
+
def binop_compare(name, ty, alg_props, const_expr):
binop_convert(name, tbool1, ty, alg_props, const_expr)
@@ -490,13 +496,24 @@ def binop_reduce(name, output_size, output_type,
src_type, prereduce_expr,
final(reduce_(reduce_(src0, src1), reduce_(src2, src3))), "")
binop("fadd", tfloat, commutative + associative, "src0 + src1")
+binop_rounding_mode("fadd_rtne", tfloat, commutative + associative,
+"_mesa_roundeven(src0 + src1)", "_rtne")
+binop_rounding_mode("fadd_rtz", tfloat, commutative + associative, "src0 +
src1", "_rtz")
+
binop("iadd", tint, commutative + associative, "src0 + src1")
binop("uadd_sat", tuint, commutative,
"(src0 + src1) < src0 ? UINT64_MAX : (src0 + src1)")
binop("fsub", tfloat, "", "src0 - src1")
+binop_rounding_mode("fsub_rtne", tfloat, "",
+"_mesa_roundeven(src0 - src1)", "_rtne")
+binop_rounding_mode("fsub_rtz", tfloat, "", "src0 - src1", "_rtz")
binop("isub", tint, "", "src0 - src1")
binop("fmul", tfloat, commutative + associative, "src0 * src1")
+binop_rounding_mode("fmul_rtne", tfloat, commutative + associative,
+"_mesa_roundeven(src0 * src1)", "_rtne")
+binop_rounding_mode("fmul_rtz", tfloat, commutative + associative, "src0 *
src1", "_rtz")
+
# low 32-bits of signed/unsigned integer multiply
binop("imul", tint, commutative + associative, "src0 * src1")
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 28/44] nir: fix denorm flush-to-zero in sqrt's lowering at nir_lower_double_ops
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_lower_double_ops.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_lower_double_ops.c
b/src/compiler/nir/nir_lower_double_ops.c
index 4d4cdf635ea..525f2d19dc7 100644
--- a/src/compiler/nir/nir_lower_double_ops.c
+++ b/src/compiler/nir/nir_lower_double_ops.c
@@ -289,9 +289,14 @@ lower_sqrt_rsq(nir_builder *b, nir_ssa_def *src, bool sqrt)
* 0 -> 0 and
* +inf -> +inf
*/
- res = nir_bcsel(b, nir_ior(b, nir_feq(b, src, nir_imm_double(b, 0.0)),
+ nir_ssa_def *src_flushed = nir_bcsel(b,
+ nir_flt(b, nir_fabs(b, src),
+ nir_imm_double(b,
2.22507385850720138309023271733e-308)),
+ nir_imm_double(b, 0.0),
+ src);
+ res = nir_bcsel(b, nir_ior(b, nir_feq(b, src_flushed, nir_imm_double(b,
0.0)),
nir_feq(b, src, nir_imm_double(b, INFINITY))),
- src, res);
+ src_flushed, res);
} else {
res = fix_inv_result(b, res, src, new_exp);
}
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 23/44] spirv/nir: add rounding mode support for GLSLstd450Ldexp
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/spirv/vtn_glsl450.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index b0092bcb2ad..b62641f3db5 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -513,7 +513,9 @@ build_frexp64(nir_builder *b, nir_ssa_def *x, nir_ssa_def
**exponent)
static nir_op
vtn_nir_alu_op_for_spirv_glsl_opcode(struct vtn_builder *b,
- enum GLSLstd450 opcode)
+ enum GLSLstd450 opcode,
+ unsigned execution_mode,
+ unsigned bit_size)
{
switch (opcode) {
case GLSLstd450Round: return nir_op_fround_even;
@@ -543,7 +545,13 @@ vtn_nir_alu_op_for_spirv_glsl_opcode(struct vtn_builder *b,
case GLSLstd450SMax: return nir_op_imax;
case GLSLstd450FMix: return nir_op_flrp;
case GLSLstd450Fma: return nir_op_ffma;
- case GLSLstd450Ldexp: return nir_op_ldexp;
+ case GLSLstd450Ldexp:
+ if (nir_is_rounding_mode_rtne(execution_mode, bit_size))
+ return nir_op_ldexp_rtne;
+ else if (nir_is_rounding_mode_rtz(execution_mode, bit_size))
+ return nir_op_ldexp_rtz;
+ else
+ return nir_op_ldexp;
case GLSLstd450FindILsb: return nir_op_find_lsb;
case GLSLstd450FindSMsb: return nir_op_ifind_msb;
case GLSLstd450FindUMsb: return nir_op_ufind_msb;
@@ -821,13 +829,17 @@ handle_glsl450_alu(struct vtn_builder *b, enum GLSLstd450
entrypoint,
return;
}
- default:
+ default: {
+ unsigned execution_mode =
+ b->shader->info.shader_float_controls_execution_mode;
+
val->ssa->def =
nir_build_alu(>nb,
- vtn_nir_alu_op_for_spirv_glsl_opcode(b, entrypoint),
+ vtn_nir_alu_op_for_spirv_glsl_opcode(b, entrypoint,
execution_mode, glsl_get_bit_size(dest_type)),
src[0], src[1], src[2], NULL);
return;
}
+ }
}
static void
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 26/44] spirv/nir: add rounding mode support for GLSLstd450Fract opcode
Signed-off-by: Samuel Iglesias Gonsálvez --- src/compiler/spirv/vtn_glsl450.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c index 8128ed346af..b6036cf876e 100644 --- a/src/compiler/spirv/vtn_glsl450.c +++ b/src/compiler/spirv/vtn_glsl450.c @@ -527,7 +527,13 @@ vtn_nir_alu_op_for_spirv_glsl_opcode(struct vtn_builder *b, case GLSLstd450SSign: return nir_op_isign; case GLSLstd450Floor: return nir_op_ffloor; case GLSLstd450Ceil: return nir_op_fceil; - case GLSLstd450Fract: return nir_op_ffract; + case GLSLstd450Fract: + if (nir_is_rounding_mode_rtne(execution_mode, bit_size)) + return nir_op_ffract_rtne; + else if (nir_is_rounding_mode_rtz(execution_mode, bit_size)) + return nir_op_ffract_rtz; + else + return nir_op_ffract; case GLSLstd450Sin: return nir_op_fsin; case GLSLstd450Cos: return nir_op_fcos; case GLSLstd450Pow: return nir_op_fpow; -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 09/44] util: add fp64 -> fp32 conversion support for RTNE and RTZ rounding modes
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/util/Makefile.sources | 2 +
src/util/double.c | 197 ++
src/util/double.h | 46 +
src/util/meson.build | 2 +
4 files changed, 247 insertions(+)
create mode 100644 src/util/double.c
create mode 100644 src/util/double.h
diff --git a/src/util/Makefile.sources b/src/util/Makefile.sources
index f09b89b3be5..1b998bf26c4 100644
--- a/src/util/Makefile.sources
+++ b/src/util/Makefile.sources
@@ -11,6 +11,8 @@ MESA_UTIL_FILES := \
debug.h \
disk_cache.c \
disk_cache.h \
+ double.c \
+ double.h \
fast_idiv_by_const.c \
fast_idiv_by_const.h \
format_r11g11b10f.h \
diff --git a/src/util/double.c b/src/util/double.c
new file mode 100644
index 000..61f23e3b57b
--- /dev/null
+++ b/src/util/double.c
@@ -0,0 +1,197 @@
+/*
+ * Mesa 3-D graphics library
+ *
+ * Copyright (C) 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "rounding.h"
+#include "double.h"
+
+
+
+
+typedef union { double f; int64_t i; uint64_t u; } fi_type;
+
+/**
+ * Convert a 8-byte double to a 4-byte float.
+ *
+ * Not all float64 values can be represented exactly as a float32 value. We
+ * round such intermediate float64 values to the nearest float32. When the
+ * float64 lies exactly between two float32 values, we round to the one with
+ * an even mantissa.
+ */
+
+float
+_mesa_double_to_float(double val)
+{
+ const fi_type fi = {val};
+ const int64_t flt_m = fi.i & 0x0f;
+ const int64_t flt_e = (fi.i >> 52) & 0x7ff;
+ const int64_t flt_s = (fi.i >> 63) & 0x1;
+ int s, e, m = 0;
+ float result;
+
+ /* sign bit */
+ s = flt_s;
+
+ /* handle special cases */
+ if ((flt_e == 0) && (flt_m == 0)) {
+ /* zero */
+ /* m = 0; - already set */
+ e = 0;
+ }
+ else if ((flt_e == 0) && (flt_m != 0)) {
+ /* denorm -- denorm float64 maps to 0 */
+ /* m = 0; - already set */
+ e = 0;
+ }
+ else if ((flt_e == 0x7ff) && (flt_m == 0)) {
+ /* infinity */
+ /* m = 0; - already set */
+ e = 255;
+ }
+ else if ((flt_e == 0x7ff) && (flt_m != 0)) {
+ /* NaN */
+ m = 1;
+ e = 255;
+ }
+ else {
+ /* regular number */
+ const int new_exp = flt_e - 1023;
+ if (new_exp < -126) {
+ /* The float64 lies in the range (0.0, min_normal32) and is rounded
+ * to a nearby float32 value. The result will be either zero,
subnormal,
+ * or normal.
+ */
+ e = 0;
+ m = _mesa_lroundeven(((double)((uint64_t)1 << 54)) * fabs(fi.f));
+ }
+ else if (new_exp > 127) {
+ /* map this value to infinity */
+ /* m = 0; - already set */
+ e = 255;
+ }
+ else {
+ /* The float64 lies in the range
+ * [min_normal32, max_normal32 + max_step32)
+ * and is rounded to a nearby float32 value. The result will be
+ * either normal or infinite.
+ */
+ e = new_exp + 127;
+ m = _mesa_lroundeven((double)flt_m / (double) (1 << 29));
+ }
+ }
+
+ assert(0 <= m && m <= (1 << 23));
+ if (m == (1 << 23)) {
+ /* The float64 was rounded upwards into the range of the next exponent,
+ * so bump the exponent. This correctly handles the case where f64
+ * should be rounded up to float32 infinity.
+ */
+ ++e;
+ m = 0;
+ }
+
+ unsigned result_int = (s << 31) | (e << 23) | m;
+ memcpy(, _int, sizeof(float));
+ return result;
+}
+
+float
+_mesa_double_to_float_rtz(double val)
+{
+ const fi_type fi = {val};
+ const int64_t flt_m = fi.i & 0x0f
[Mesa-dev] [PATCH v3 11/44] nir: add new floating point conversion opcodes taking into account rounding mode
It adds round-towards-zero and round-to-nearest-even opcodes for
floating point conversions.
According to Vulkan spec, the new execution modes affect only
correctly rounded SPIR-V instructions, which includes these conversions.
v2:
- Move code to nir_opcodes.py (Connor)
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_opcodes.py | 20 ++--
src/compiler/nir/nir_opcodes_c.py | 4 ++--
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 21f6ee6f742..f8997444c28 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -221,12 +221,28 @@ for src_t in [tint, tuint, tfloat, tbool]:
for dst_t in dst_types:
for bit_size in type_sizes(dst_t):
- if bit_size == 16 and dst_t == tfloat and src_t == tfloat:
+ if src_t == tfloat and dst_t == tfloat:
rnd_modes = ['_rtne', '_rtz', '']
for rnd_mode in rnd_modes:
+ if rnd_mode == '_rtne':
+ src = "bit_size == 64 ? _mesa_double_to_float_rtne(src0)
: src0"
+ if rnd_mode == '_rtz':
+ src = "bit_size == 64 ? _mesa_double_to_float_rtz(src0) :
src0"
+ else:
+ src = "src0"
unop_numeric_convert("{0}2{1}{2}{3}".format(src_t[0],
dst_t[0],
bit_size,
rnd_mode),
- dst_t + str(bit_size), src_t, "src0",
rnd_mode)
+ dst_t + str(bit_size), src_t, src,
rnd_mode)
+ elif src_t == tfloat and dst_t == tint:
+ rnd_modes = ['_rtne', '_rtz', '']
+ for rnd_mode in rnd_modes:
+ if rnd_mode == '_rtne':
+ src = "bit_size == 32 ? _mesa_roundevenf(src0) :
_mesa_roundeven(src0)"
+ else:
+ src = "src0"
+ unop_numeric_convert("{0}2{1}{2}{3}".format(src_t[0],
dst_t[0],
+ bit_size,
rnd_mode),
+ dst_t + str(bit_size), src_t, src,
rnd_mode)
else:
conv_expr = "src0 != 0" if dst_t == tbool else "src0"
unop_numeric_convert("{0}2{1}{2}".format(src_t[0], dst_t[0],
bit_size),
diff --git a/src/compiler/nir/nir_opcodes_c.py
b/src/compiler/nir/nir_opcodes_c.py
index c6cab5a5e1a..46bbb400b84 100644
--- a/src/compiler/nir/nir_opcodes_c.py
+++ b/src/compiler/nir/nir_opcodes_c.py
@@ -76,7 +76,7 @@ nir_type_conversion_op(nir_alu_type src, nir_alu_type dst,
nir_rounding_mode rnd
switch (dst_bit_size) {
% for dst_bits in type_sizes(dst_t):
case ${dst_bits}:
-%if src_t == 'float' and dst_t == 'float' and dst_bits ==
16:
+%if src_t == 'float' and dst_t == 'float':
switch(rnd) {
% for rnd_t in [('rtne', '_rtne'), ('rtz', '_rtz'),
('undef', '')]:
case nir_rounding_mode_${rnd_t[0]}:
@@ -84,7 +84,7 @@ nir_type_conversion_op(nir_alu_type src, nir_alu_type dst,
nir_rounding_mode rnd
dst_bits,
rnd_t[1])};
% endfor
default:
- unreachable("Invalid 16-bit nir rounding mode");
+ unreachable("Invalid ${dst_bits}-bit nir rounding
mode");
}
%else:
assert(rnd == nir_rounding_mode_undef);
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 29/44] nir: fix fmin/fmax support for doubles
Until now, it was using the floating point version of fmin/fmax,
instead of the double version.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_opcodes.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 230057c1f30..5990a195c29 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -713,10 +713,10 @@ opcode("fdph", 1, tfloat, [3, 4], [tfloat, tfloat],
False, "",
opcode("fdph_replicated", 4, tfloat, [3, 4], [tfloat, tfloat], False, "",
"src0.x * src1.x + src0.y * src1.y + src0.z * src1.z + src1.w", "")
-binop("fmin", tfloat, "", "fminf(src0, src1)")
+binop("fmin", tfloat, "", "fmin(src0, src1)")
binop("imin", tint, commutative + associative, "src1 > src0 ? src0 : src1")
binop("umin", tuint, commutative + associative, "src1 > src0 ? src0 : src1")
-binop("fmax", tfloat, "", "fmaxf(src0, src1)")
+binop("fmax", tfloat, "", "fmax(src0, src1)")
binop("imax", tint, commutative + associative, "src1 > src0 ? src1 : src0")
binop("umax", tuint, commutative + associative, "src1 > src0 ? src1 : src0")
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 27/44] nir: fix denorms in unpack_half_1x16()
According to VK_KHR_shader_float_controls:
"Denormalized values obtained via unpacking an integer into a vector
of values with smaller bit width and interpreting those values as
floating-point numbers must: be flushed to zero, unless the entry point
is declared with the code:DenormPreserve execution mode."
v2:
- Add nir_op_unpack_half_2x16_flush_to_zero opcode (Connor)
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_constant_expressions.py | 13 +
src/compiler/nir/nir_lower_alu_to_scalar.c | 11 +--
src/compiler/nir/nir_opcodes.py | 11 ++-
src/compiler/spirv/vtn_glsl450.c | 6 +-
4 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/src/compiler/nir/nir_constant_expressions.py
b/src/compiler/nir/nir_constant_expressions.py
index 0b3da1b21ac..f8d1c2d3bdc 100644
--- a/src/compiler/nir/nir_constant_expressions.py
+++ b/src/compiler/nir/nir_constant_expressions.py
@@ -261,6 +261,19 @@ pack_half_1x16(float x)
return _mesa_float_to_half(x);
}
+/**
+ * Evaluate one component of unpackHalf2x16.
+ */
+static float
+unpack_half_1x16_flush_to_zero(uint16_t u)
+{
+ if (u < 0x0400)
+ u = 0;
+ if (u & 0x8000 && !(u & 0x7c00))
+ u = 0x8000;
+ return _mesa_half_to_float(u);
+}
+
/**
* Evaluate one component of unpackHalf2x16.
*/
diff --git a/src/compiler/nir/nir_lower_alu_to_scalar.c
b/src/compiler/nir/nir_lower_alu_to_scalar.c
index 2ed4098d59b..6a5a0d2f991 100644
--- a/src/compiler/nir/nir_lower_alu_to_scalar.c
+++ b/src/compiler/nir/nir_lower_alu_to_scalar.c
@@ -132,6 +132,7 @@ lower_alu_instr_scalar(nir_alu_instr *instr, nir_builder *b)
*/
return false;
+ case nir_op_unpack_half_2x16_flush_to_zero:
case nir_op_unpack_half_2x16: {
if (!b->shader->options->lower_unpack_half_2x16)
return false;
@@ -139,8 +140,14 @@ lower_alu_instr_scalar(nir_alu_instr *instr, nir_builder
*b)
nir_ssa_def *packed = nir_ssa_for_alu_src(b, instr, 0);
nir_ssa_def *comps[2];
- comps[0] = nir_unpack_half_2x16_split_x(b, packed);
- comps[1] = nir_unpack_half_2x16_split_y(b, packed);
+
+ if (instr->op == nir_op_unpack_half_2x16_flush_to_zero) {
+ comps[0] = nir_unpack_half_2x16_split_x_flush_to_zero(b, packed);
+ comps[1] = nir_unpack_half_2x16_split_y_flush_to_zero(b, packed);
+ } else {
+ comps[0] = nir_unpack_half_2x16_split_x(b, packed);
+ comps[1] = nir_unpack_half_2x16_split_y(b, packed);
+ }
nir_ssa_def *vec = nir_vec(b, comps, 2);
nir_ssa_def_rewrite_uses(>dest.dest.ssa, nir_src_for_ssa(vec));
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index a8ccb237a65..230057c1f30 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -357,14 +357,23 @@ unop_horiz("unpack_64_4x16", 4, tuint16, 1, tuint64,
unop_horiz("unpack_32_2x16", 2, tuint16, 1, tuint32,
"dst.x = src0.x; dst.y = src0.x >> 16;")
-# Lowered floating point unpacking operations.
+unop_horiz("unpack_half_2x16_flush_to_zero", 2, tfloat32, 1, tuint32, """
+dst.x = unpack_half_1x16_flush_to_zero((uint16_t)(src0.x & 0x));
+dst.y = unpack_half_1x16_flush_to_zero((uint16_t)(src0.x << 16));
+""")
+# Lowered floating point unpacking operations.
unop_convert("unpack_half_2x16_split_x", tfloat32, tuint32,
"unpack_half_1x16((uint16_t)(src0 & 0x))", "")
unop_convert("unpack_half_2x16_split_y", tfloat32, tuint32,
"unpack_half_1x16((uint16_t)(src0 >> 16))", "")
+unop_convert("unpack_half_2x16_split_x_flush_to_zero", tfloat32, tuint32,
+ "unpack_half_1x16_flush_to_zero((uint16_t)(src0 & 0x))", "")
+unop_convert("unpack_half_2x16_split_y_flush_to_zero", tfloat32, tuint32,
+ "unpack_half_1x16_flush_to_zero((uint16_t)(src0 >> 16))", "")
+
unop_convert("unpack_32_2x16_split_x", tuint16, tuint32, "src0", "")
unop_convert("unpack_32_2x16_split_y", tuint16, tuint32, "src0 >> 16", "")
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index b6036cf876e..e75efbc695c 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -573,7 +573,11 @@ vtn_nir_alu_op_for_spirv_glsl_opcode(struct vtn_builder *b,
case GLSLstd450UnpackUnorm4x8: return nir_op_unpack_unorm_4x8;
case GLSLstd450UnpackSnorm2x16: return nir_op_unpack_snorm_2x16;
case GLSLstd450UnpackUnorm2x16: return nir_op_unpack_unorm_2x16;
- case GLSLstd450UnpackHalf2x16: return nir_op_unpack_half_2x16;
+ case GLSLstd450UnpackHalf2x16:
+ i
[Mesa-dev] [PATCH v3 31/44] i965/fs: add nir_op_f2f*_{rtne,rtz}
This way, we can implement its support later if SPIR-V supports it. Right now, the RTZ, RTNE support in SPIR-V in FPRoundingMode only applies to f2f16 conversions. Signed-off-by: Samuel Iglesias Gonsálvez --- src/intel/compiler/brw_fs_nir.cpp | 4 1 file changed, 4 insertions(+) diff --git a/src/intel/compiler/brw_fs_nir.cpp b/src/intel/compiler/brw_fs_nir.cpp index 84e48fc6754..ac5067f7ecc 100644 --- a/src/intel/compiler/brw_fs_nir.cpp +++ b/src/intel/compiler/brw_fs_nir.cpp @@ -801,11 +801,15 @@ fs_visitor::nir_emit_alu(const fs_builder , nir_alu_instr *instr) case nir_op_i2i64: case nir_op_u2f64: case nir_op_u2u64: + case nir_op_f2f64_rtne: + case nir_op_f2f64_rtz: case nir_op_f2f64: case nir_op_f2i64: case nir_op_f2u64: case nir_op_i2i32: case nir_op_u2u32: + case nir_op_f2f32_rtne: + case nir_op_f2f32_rtz: case nir_op_f2f32: case nir_op_f2i32: case nir_op_f2u32: -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 18/44] nir/algebraic: add optimizations for fadd, fsub and fmul with rounding mode
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_opt_algebraic.py | 73 +++
1 file changed, 73 insertions(+)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
index 71c626e1b3f..3800db1da20 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -89,30 +89,51 @@ optimizations = [
(('f2b', ('fneg', a)), ('f2b', a)),
(('i2b', ('ineg', a)), ('i2b', a)),
(('~fadd', a, 0.0), a),
+ (('~fadd_rtne', a, 0.0), a),
+ (('~fadd_rtz', a, 0.0), a),
(('iadd', a, 0), a),
(('usadd_4x8', a, 0), a),
(('usadd_4x8', a, ~0), ~0),
(('~fadd', ('fmul', a, b), ('fmul', a, c)), ('fmul', a, ('fadd', b, c))),
+ (('~fadd_rtne', ('fmul_rtne', a, b), ('fmul_rtne', a, c)), ('fmul_rtne', a,
('fadd_rtne', b, c))),
+ (('~fadd_rtz', ('fmul_rtz', a, b), ('fmul_rtz', a, c)), ('fmul_rtz', a,
('fadd_rtz', b, c))),
(('iadd', ('imul', a, b), ('imul', a, c)), ('imul', a, ('iadd', b, c))),
(('~fadd', ('fneg', a), a), 0.0),
+ (('~fadd_rtne', ('fneg', a), a), 0.0),
+ (('~fadd_rtz', ('fneg', a), a), 0.0),
(('iadd', ('ineg', a), a), 0),
(('iadd', ('ineg', a), ('iadd', a, b)), b),
(('iadd', a, ('iadd', ('ineg', a), b)), b),
(('~fadd', ('fneg', a), ('fadd', a, b)), b),
(('~fadd', a, ('fadd', ('fneg', a), b)), b),
(('~fmul', a, 0.0), 0.0),
+ (('~fadd_rtne', ('fneg', a), ('fadd_rtne', a, b)), b),
+ (('~fadd_rtne', a, ('fadd_rtne', ('fneg', a), b)), b),
+ (('~fmul_rtne', a, 0.0), 0.0),
+ (('~fadd_rtz', ('fneg', a), ('fadd_rtz', a, b)), b),
+ (('~fadd_rtz', a, ('fadd_rtz', ('fneg', a), b)), b),
+ (('~fmul_rtz', a, 0.0), 0.0),
+
(('imul', a, 0), 0),
(('umul_unorm_4x8', a, 0), 0),
(('umul_unorm_4x8', a, ~0), a),
(('fmul', a, 1.0), a),
+ (('fmul_rtne', a, 1.0), a),
+ (('fmul_rtz', a, 1.0), a),
(('imul', a, 1), a),
(('fmul', a, -1.0), ('fneg', a)),
+ (('fmul_rtne', a, -1.0), ('fneg', a)),
+ (('fmul_rtz', a, -1.0), ('fneg', a)),
(('imul', a, -1), ('ineg', a)),
# If a < 0: fsign(a)*a*a => -1*a*a => -a*a => abs(a)*a
# If a > 0: fsign(a)*a*a => 1*a*a => a*a => abs(a)*a
# If a == 0: fsign(a)*a*a => 0*0*0 => abs(0)*0
(('fmul', ('fsign', a), ('fmul', a, a)), ('fmul', ('fabs', a), a)),
(('fmul', ('fmul', ('fsign', a), a), a), ('fmul', ('fabs', a), a)),
+ (('fmul_rtne', ('fsign', a), ('fmul_rtne', a, a)), ('fmul_rtne', ('fabs',
a), a)),
+ (('fmul_rtne', ('fmul_rtne', ('fsign', a), a), a), ('fmul_rtne', ('fabs',
a), a)),
+ (('fmul_rtz', ('fsign', a), ('fmul_rtz', a, a)), ('fmul_rtz', ('fabs', a),
a)),
+ (('fmul_rtz', ('fmul_rtz', ('fsign', a), a), a), ('fmul_rtz', ('fabs', a),
a)),
(('~ffma', 0.0, a, b), b),
(('~ffma', a, 0.0, b), b),
(('~ffma', a, b, 0.0), ('fmul', a, b)),
@@ -139,6 +160,23 @@ optimizations = [
(('ffma', a, b, c), ('fadd', ('fmul', a, b), c), 'options->lower_ffma'),
(('~fadd', ('fmul', a, b), c), ('ffma', a, b, c), 'options->fuse_ffma'),
+ (('~fadd_rtne', ('fmul_rtne', a, ('fadd_rtne', 1.0, ('fneg', ('b2f',
'c@1', ('fmul_rtne', b, ('b2f', c))), ('bcsel', c, b, a),
'options->lower_flrp32'),
+ (('~fadd_rtne@32', ('fmul_rtne', a, ('fadd_rtne', 1.0, ('fneg', c
))), ('fmul_rtne', b, c )), ('flrp', a, b, c),
'!options->lower_flrp32'),
+ (('~fadd_rtne@64', ('fmul_rtne', a, ('fadd_rtne', 1.0, ('fneg', c
))), ('fmul_rtne', b, c )), ('flrp', a, b, c),
'!options->lower_flrp64'),
+ (('~fadd_rtne', a, ('fmul_rtne', ('b2f', 'c@1'), ('fadd_rtne', b, ('fneg',
a, ('bcsel', c, b, a), 'options->lower_flrp32'),
+ (('~fadd_rtne@32', a, ('fmul_rtne', c , ('fadd_rtne', b, ('fneg',
a, ('flrp', a, b, c), '!options->lower_flrp32'),
+ (('~fadd_rtne@64', a, ('fmul_rtne', c , ('fadd_rtne', b, ('fneg',
a, ('flrp', a, b, c), '!options->lower_flrp64'),
+ (('~fadd_rtne', ('fmul_rtne', a, b), c), ('ffma', a, b, c),
'options->fuse_ffma'),
+
+ (('~fadd_rtz', ('fmul_rtz', a, ('fadd_rtz', 1.0, ('fneg', ('b2f',
'c@1', ('fmul_rtz', b, ('b2f', c))), ('bcsel', c, b, a),
'options->lower_flrp32'),
+ (('~fadd_rtz@32', ('fmul_rtz', a, ('fadd_rtz', 1.0, ('fneg', c ))),
('fmul_rtz', b, c )), ('flrp', a, b, c), '!options->lower_flrp32'),
+ (('~fadd_rtz@64', ('fmul_rtz', a, ('fadd_rtz', 1.0, ('fneg', c ))),
('fmul_rtz', b, c )), ('flrp', a, b, c), '!options->lower_flrp64'),
+ (('~fadd_rtz', a, ('fmul_rtz', ('b2f', 'c@1'), ('fadd_rtz', b, ('fneg',
a, ('bcsel', c, b, a), 'options->lower_flrp32'),
+ (('~fadd_rtz@32', a, ('fmul_rtz', c , ('fadd_rtz', b, ('fneg',
a, ('flrp', a, b, c), '!options->lower_flrp32'),
+ (('~fadd_rtz@64', a, ('fmul_rtz', c , ('fadd_rtz', b, ('fneg',
a, ('flrp', a, b, c), '!options->lower_flrp64'),
+ (('~fadd_rtz', ('fmul_rtz', a, b), c), ('ffm
[Mesa-dev] [PATCH v3 24/44] spirv/nir: add rounding mode support for FaceForward opcode
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/spirv/vtn_glsl450.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index b62641f3db5..e9b1b0b8fec 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -588,6 +588,8 @@ handle_glsl450_alu(struct vtn_builder *b, enum GLSLstd450
entrypoint,
struct vtn_value *val = vtn_push_value(b, w[2], vtn_value_type_ssa);
val->ssa = vtn_create_ssa_value(b, dest_type);
+ unsigned execution_mode =
b->shader->info.shader_float_controls_execution_mode;
+
/* Collect the various SSA sources */
unsigned num_inputs = count - 5;
nir_ssa_def *src[3] = { NULL, };
@@ -673,10 +675,21 @@ handle_glsl450_alu(struct vtn_builder *b, enum GLSLstd450
entrypoint,
}
case GLSLstd450FaceForward:
- val->ssa->def =
- nir_bcsel(nb, nir_flt(nb, nir_fdot(nb, src[2], src[1]),
- NIR_IMM_FP(nb, 0.0)),
- src[0], nir_fneg(nb, src[0]));
+ if (nir_is_rounding_mode_rtne(execution_mode,
glsl_get_bit_size(dest_type)))
+ val->ssa->def =
+nir_bcsel(nb, nir_flt(nb, nir_fdot_rtne(nb, src[2], src[1]),
+ NIR_IMM_FP(nb, 0.0)),
+ src[0], nir_fneg(nb, src[0]));
+ else if (nir_is_rounding_mode_rtz(execution_mode,
glsl_get_bit_size(dest_type)))
+ val->ssa->def =
+nir_bcsel(nb, nir_flt(nb, nir_fdot_rtz(nb, src[2], src[1]),
+ NIR_IMM_FP(nb, 0.0)),
+ src[0], nir_fneg(nb, src[0]));
+ else
+ val->ssa->def =
+nir_bcsel(nb, nir_flt(nb, nir_fdot(nb, src[2], src[1]),
+ NIR_IMM_FP(nb, 0.0)),
+ src[0], nir_fneg(nb, src[0]));
return;
case GLSLstd450Reflect: {
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 15/44] nir: add new ffract opcodes taking into account rounding mode
According to Vulkan spec, the new execution modes affect only
correctly rounded SPIR-V instructions, which includes Fract.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_opcodes.py | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 21f6569c888..a8ccb237a65 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -156,6 +156,10 @@ def unop_convert(name, out_type, in_type, const_expr,
rounding_mode):
def unop(name, ty, const_expr):
opcode(name, 0, ty, [0], [ty], False, "", const_expr, "")
+def unop_rounding_mode(name, ty, const_expr, rounding_mode):
+ op_name = "{0}{1}".format(name, rounding_mode)
+ opcode(op_name, 0, ty, [0], [ty], False, "", const_expr, rounding_mode)
+
def unop_horiz(name, output_size, output_type, input_size, input_type,
const_expr):
opcode(name, output_size, output_type, [input_size], [input_type],
@@ -250,11 +254,13 @@ for src_t in [tint, tuint, tfloat, tbool]:
# Unary floating-point rounding operations.
-
unop("ftrunc", tfloat, "bit_size == 64 ? trunc(src0) : truncf(src0)")
unop("fceil", tfloat, "bit_size == 64 ? ceil(src0) : ceilf(src0)")
unop("ffloor", tfloat, "bit_size == 64 ? floor(src0) : floorf(src0)")
unop("ffract", tfloat, "src0 - (bit_size == 64 ? floor(src0) : floorf(src0))")
+unop_rounding_mode("ffract", tfloat, """bit_size == 64 ? _mesa_roundeven(src0
- floor(src0)) : _mesa_roundevenf(src0 - floorf(src0))""", "_rtne")
+unop_rounding_mode("ffract", tfloat, "src0 - (bit_size == 64 ? floor(src0) :
floorf(src0))", "_rtz")
+
unop("fround_even", tfloat, "bit_size == 64 ? _mesa_roundeven(src0) :
_mesa_roundevenf(src0)")
unop("fquantize2f16", tfloat, "(fabs(src0) < ldexpf(1.0, -14)) ?
copysignf(0.0f, src0) : _mesa_half_to_float(_mesa_float_to_half(src0))")
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 16/44] nir/constant_expressions: take into account rounding mode to convert from float to float16 destinations
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_constant_expressions.py | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/compiler/nir/nir_constant_expressions.py
b/src/compiler/nir/nir_constant_expressions.py
index e79590f8359..0b3da1b21ac 100644
--- a/src/compiler/nir/nir_constant_expressions.py
+++ b/src/compiler/nir/nir_constant_expressions.py
@@ -64,6 +64,7 @@ template = """\
#include "util/rounding.h" /* for _mesa_roundeven */
#include "util/half_float.h"
#include "util/bigmath.h"
+#include "util/double.h"
#include "nir_constant_expressions.h"
/**
@@ -370,7 +371,11 @@ struct ${type}${width}_vec {
## Sanitize the C value to a proper NIR 0/-1 bool
_dst_val.${get_const_field(output_type)}[_i] = -(int)dst;
% elif output_type == "float16":
-_dst_val.u16[_i] = _mesa_float_to_half(dst);
+% if "rtz" in op.rounding_mode:
+ _dst_val.u16[_i] = _mesa_float_to_float16_rtz(dst);
+% else:
+ _dst_val.u16[_i] = _mesa_float_to_float16_rtne(dst);
+% endif
% else:
_dst_val.${get_const_field(output_type)}[_i] = dst;
% endif
@@ -414,7 +419,11 @@ struct ${type}${width}_vec {
## Sanitize the C value to a proper NIR 0/-1 bool
_dst_val.${get_const_field(output_type)}[${k}] =
-(int)dst.${"xyzw"[k]};
% elif output_type == "float16":
-_dst_val.u16[${k}] = _mesa_float_to_half(dst.${"xyzw"[k]});
+% if "rtz" in op.rounding_mode:
+ _dst_val.u16[${k}] =
_mesa_float_to_float16_rtz(dst.${"xyzw"[k]});
+% else:
+ _dst_val.u16[${k}] =
_mesa_float_to_float16_rtne(dst.${"xyzw"[k]});
+% endif
% else:
_dst_val.${get_const_field(output_type)}[${k}] = dst.${"xyzw"[k]};
% endif
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 13/44] nir: add new ldexp opcodes taking into account rounding mode
According to Vulkan spec, the new execution modes affect only
correctly rounded SPIR-V instructions, which is the case for ldexp.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_opcodes.py | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index 7b45d38f460..d0087d350a8 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -772,6 +772,20 @@ if (!isnormal(dst))
dst = copysignf(0.0f, src0);
""", "")
+opcode("ldexp_rtne", 0, tfloat, [0, 0], [tfloat, tint32], False, "", """
+dst = (bit_size == 64) ? _mesa_roundeven(ldexp(src0, src1)) :
_mesa_roundevenf(ldexpf(src0, src1));
+/* flush denormals to zero. */
+if (!isnormal(dst))
+ dst = copysignf(0.0f, src0);
+""", "_rtne")
+
+opcode("ldexp_rtz", 0, tfloat, [0, 0], [tfloat, tint32], False, "", """
+dst = (bit_size == 64) ? ldexp(src0, src1) : ldexpf(src0, src1);
+/* flush denormals to zero. */
+if (!isnormal(dst))
+ dst = copysignf(0.0f, src0);
+""", "_rtz")
+
# Combines the first component of each input to make a 2-component vector.
binop_horiz("vec2", 2, tuint, 1, tuint, 1, tuint, """
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 07/44] spirv/glsl450: fix reflect(denorm, denorm) FTZ = 0.0 case
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/spirv/vtn_glsl450.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index a6d2c5fdd07..b0092bcb2ad 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -671,13 +671,18 @@ handle_glsl450_alu(struct vtn_builder *b, enum GLSLstd450
entrypoint,
src[0], nir_fneg(nb, src[0]));
return;
- case GLSLstd450Reflect:
+ case GLSLstd450Reflect: {
/* I - 2 * dot(N, I) * N */
- val->ssa->def =
+ nir_ssa_def *reflect =
nir_fsub(nb, src[0], nir_fmul(nb, NIR_IMM_FP(nb, 2.0),
- nir_fmul(nb, nir_fdot(nb, src[0], src[1]),
- src[1])));
+ nir_fmul(nb, nir_fdot(nb, src[0],
src[1]),
+src[1])));
+ nir_ssa_def *zero = NIR_IMM_FP(nb, 0.0);
+ val->ssa->def = nir_bcsel(nb, nir_iand(nb,
+nir_feq(nb, src[0], zero),
+nir_feq(nb, src[1], zero)), zero,
reflect);
return;
+ }
case GLSLstd450Refract: {
nir_ssa_def *I = src[0];
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 06/44] spirv/glsl450: fix atan2(x, x) case
If x < 0 -> atan2(x, x) = -3*pi/4. If x > 0 -> atan2(x, x) = pi/4. Signed-off-by: Samuel Iglesias Gonsálvez --- src/compiler/spirv/vtn_glsl450.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c index 21a2464d5e7..a6d2c5fdd07 100644 --- a/src/compiler/spirv/vtn_glsl450.c +++ b/src/compiler/spirv/vtn_glsl450.c @@ -35,6 +35,7 @@ #define M_PIf ((float) M_PI) #define M_PI_2f ((float) M_PI_2) #define M_PI_4f ((float) M_PI_4) +#define M_minus_3PI_4f ((float) -3*M_PI_4) static nir_ssa_def * build_mat2_det(nir_builder *b, nir_ssa_def *col[2]) @@ -381,12 +382,16 @@ build_atan2(nir_builder *b, nir_ssa_def *y, nir_ssa_def *x) * continuous along the whole positive y = 0 half-line, so it won't affect * the result significantly. */ - nir_ssa_def *result = nir_bcsel(b, nir_flt(b, nir_fmin(b, y, rcp_scaled_t), zero), + nir_ssa_def *atan2 = nir_bcsel(b, nir_flt(b, nir_fmin(b, y, rcp_scaled_t), zero), nir_fneg(b, arc), arc); nir_ssa_def *is_xy_zero = nir_iand(b, nir_feq(b, x, zero), nir_feq(b, y, zero)); - return nir_bcsel(b, is_xy_zero, zero, result); + nir_ssa_def *res_equal = nir_bcsel(b, nir_feq(b, x, y), + nir_bcsel(b, nir_flt(b, x, zero), nir_imm_floatN_t(b, M_minus_3PI_4f, bit_size), nir_imm_floatN_t(b, M_PI_4f, bit_size)), + atan2); + nir_ssa_def *res = nir_bcsel(b, is_xy_zero, zero, res_equal); + return res; } static nir_ssa_def * -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 25/44] spirv/nir: add rounding mode support for GLSLstd450Modf opcode
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/spirv/vtn_glsl450.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c
index e9b1b0b8fec..8128ed346af 100644
--- a/src/compiler/spirv/vtn_glsl450.c
+++ b/src/compiler/spirv/vtn_glsl450.c
@@ -616,9 +616,20 @@ handle_glsl450_alu(struct vtn_builder *b, enum GLSLstd450
entrypoint,
case GLSLstd450Modf: {
nir_ssa_def *sign = nir_fsign(nb, src[0]);
nir_ssa_def *abs = nir_fabs(nb, src[0]);
- val->ssa->def = nir_fmul(nb, sign, nir_ffract(nb, abs));
- nir_store_deref(nb, vtn_nir_deref(b, w[6]),
- nir_fmul(nb, sign, nir_ffloor(nb, abs)), 0xf);
+
+ if (nir_is_rounding_mode_rtne(execution_mode,
glsl_get_bit_size(dest_type))) {
+ val->ssa->def = nir_fmul_rtne(nb, sign, nir_ffract(nb, abs));
+ nir_store_deref(nb, vtn_nir_deref(b, w[6]),
+ nir_fmul_rtne(nb, sign, nir_ffloor(nb, abs)), 0xf);
+ } else if (nir_is_rounding_mode_rtz(execution_mode,
glsl_get_bit_size(dest_type))) {
+ val->ssa->def = nir_fmul_rtz(nb, sign, nir_ffract(nb, abs));
+ nir_store_deref(nb, vtn_nir_deref(b, w[6]),
+ nir_fmul_rtz(nb, sign, nir_ffloor(nb, abs)), 0xf);
+ } else {
+ val->ssa->def = nir_fmul(nb, sign, nir_ffract(nb, abs));
+ nir_store_deref(nb, vtn_nir_deref(b, w[6]),
+ nir_fmul(nb, sign, nir_ffloor(nb, abs)), 0xf);
+ }
return;
}
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 21/44] spirv/nir: add rounding mode support for fadd, fsub, fmul
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/spirv/vtn_alu.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index 848fbbdb07c..881a9bab314 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -220,17 +220,37 @@ vtn_nir_alu_op_for_spirv_opcode(struct vtn_builder *b,
* used for implementing greater-than and less-than-or-equal.
*/
*swap = false;
+ unsigned float_controls =
+ b->shader->info.shader_float_controls_execution_mode;
switch (opcode) {
case SpvOpSNegate:return nir_op_ineg;
case SpvOpFNegate:return nir_op_fneg;
case SpvOpNot:return nir_op_inot;
case SpvOpIAdd: return nir_op_iadd;
- case SpvOpFAdd: return nir_op_fadd;
+ case SpvOpFAdd:
+ if (nir_is_rounding_mode_rtne(float_controls, src_bit_size))
+ return nir_op_fadd_rtne;
+ else if (nir_is_rounding_mode_rtz(float_controls, src_bit_size))
+ return nir_op_fadd_rtz;
+ else
+ return nir_op_fadd;
case SpvOpISub: return nir_op_isub;
- case SpvOpFSub: return nir_op_fsub;
+ case SpvOpFSub:
+ if (nir_is_rounding_mode_rtne(float_controls, src_bit_size))
+ return nir_op_fsub_rtne;
+ else if (nir_is_rounding_mode_rtz(float_controls, src_bit_size))
+ return nir_op_fsub_rtz;
+ else
+ return nir_op_fsub;
case SpvOpIMul: return nir_op_imul;
- case SpvOpFMul: return nir_op_fmul;
+ case SpvOpFMul:
+ if (nir_is_rounding_mode_rtne(float_controls, src_bit_size))
+ return nir_op_fmul_rtne;
+ else if (nir_is_rounding_mode_rtz(float_controls, src_bit_size))
+ return nir_op_fmul_rtz;
+ else
+ return nir_op_fmul;
case SpvOpUDiv: return nir_op_udiv;
case SpvOpSDiv: return nir_op_idiv;
case SpvOpFDiv: return nir_op_fdiv;
@@ -329,8 +349,6 @@ vtn_nir_alu_op_for_spirv_opcode(struct vtn_builder *b,
}
src_type |= src_bit_size;
dst_type |= dst_bit_size;
- unsigned float_controls =
- b->shader->info.shader_float_controls_execution_mode;
nir_rounding_mode rounding_mode =
nir_get_rounding_mode_from_float_controls(float_controls,
dst_type);
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 22/44] spirv/nir: add rounding mode support for SpvOpVectorTimesScalar and SpvOpMatrixTimesScalar
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/spirv/vtn_alu.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index 881a9bab314..06320adf152 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -145,8 +145,16 @@ mat_times_scalar(struct vtn_builder *b,
for (unsigned i = 0; i < glsl_get_matrix_columns(mat->type); i++) {
if (glsl_base_type_is_integer(glsl_get_base_type(mat->type)))
dest->elems[i]->def = nir_imul(>nb, mat->elems[i]->def, scalar);
- else
- dest->elems[i]->def = nir_fmul(>nb, mat->elems[i]->def, scalar);
+ else {
+ unsigned bit_size = scalar->bit_size;
+ unsigned rounding_mode =
b->shader->info.shader_float_controls_execution_mode;
+ if (nir_is_rounding_mode_rtne(rounding_mode, bit_size))
+dest->elems[i]->def = nir_fmul_rtne(>nb, mat->elems[i]->def,
scalar);
+ else if (nir_is_rounding_mode_rtz(rounding_mode, bit_size))
+dest->elems[i]->def = nir_fmul_rtz(>nb, mat->elems[i]->def,
scalar);
+ else
+dest->elems[i]->def = nir_fmul(>nb, mat->elems[i]->def, scalar);
+ }
}
return dest;
@@ -516,10 +524,18 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
nir_fabs(>nb, nir_fddy_coarse(>nb,
src[0])));
break;
- case SpvOpVectorTimesScalar:
+ case SpvOpVectorTimesScalar: {
+ unsigned bit_size = glsl_get_bit_size(type);
+ unsigned rounding_mode =
b->shader->info.shader_float_controls_execution_mode;
/* The builder will take care of splatting for us. */
- val->ssa->def = nir_fmul(>nb, src[0], src[1]);
+ if (nir_is_rounding_mode_rtne(rounding_mode, bit_size))
+ val->ssa->def = nir_fmul_rtne(>nb, src[0], src[1]);
+ else if (nir_is_rounding_mode_rtz(rounding_mode, bit_size))
+ val->ssa->def = nir_fmul_rtz(>nb, src[0], src[1]);
+ else
+ val->ssa->def = nir_fmul(>nb, src[0], src[1]);
break;
+ }
case SpvOpIsNan:
val->ssa->def = nir_fne(>nb, src[0], src[0]);
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 20/44] spirv/nir: add rounding mode support for floating-point conversions
v2:
- Fixed bug in rounding modes for conversion ops, it was not considering
the rounding mode of the destination data type.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir.h | 16
src/compiler/spirv/vtn_alu.c | 14 +-
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index cbc5bcff7d3..d57cabfcfa1 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -943,6 +943,22 @@ nir_is_rounding_mode_rtz(unsigned execution_mode, unsigned
bit_size)
return false;
}
+static inline nir_rounding_mode
+nir_get_rounding_mode_from_float_controls(unsigned execution_mode,
+ nir_alu_type type)
+{
+ if (nir_alu_type_get_base_type(type) != nir_type_float)
+ return nir_rounding_mode_undef;
+
+ unsigned bit_size = nir_alu_type_get_type_size(type);
+ if (nir_is_rounding_mode_rtz(execution_mode, bit_size))
+ return nir_rounding_mode_rtz;
+ if (nir_is_rounding_mode_rtne(execution_mode, bit_size))
+ return nir_rounding_mode_rtne;
+
+ return nir_rounding_mode_undef;
+}
+
typedef enum {
NIR_OP_IS_COMMUTATIVE = (1 << 0),
NIR_OP_IS_ASSOCIATIVE = (1 << 1),
diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index f910630acfb..848fbbdb07c 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -329,7 +329,12 @@ vtn_nir_alu_op_for_spirv_opcode(struct vtn_builder *b,
}
src_type |= src_bit_size;
dst_type |= dst_bit_size;
- return nir_type_conversion_op(src_type, dst_type,
nir_rounding_mode_undef);
+ unsigned float_controls =
+ b->shader->info.shader_float_controls_execution_mode;
+ nir_rounding_mode rounding_mode =
+ nir_get_rounding_mode_from_float_controls(float_controls,
+ dst_type);
+ return nir_type_conversion_op(src_type, dst_type, rounding_mode);
}
/* Derivatives: */
case SpvOpDPdx: return nir_op_fddx;
@@ -589,8 +594,15 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
nir_alu_type src_alu_type =
nir_get_nir_type_for_glsl_type(vtn_src[0]->type);
nir_alu_type dst_alu_type = nir_get_nir_type_for_glsl_type(type);
nir_rounding_mode rounding_mode = nir_rounding_mode_undef;
+ unsigned float_controls =
b->shader->info.shader_float_controls_execution_mode;
vtn_foreach_decoration(b, val, handle_rounding_mode, _mode);
+
+ if (rounding_mode == nir_rounding_mode_undef && float_controls) {
+ rounding_mode =
+nir_get_rounding_mode_from_float_controls(float_controls,
+ src_alu_type);
+ }
nir_op op = nir_type_conversion_op(src_alu_type, dst_alu_type,
rounding_mode);
val->ssa->def = nir_build_alu(>nb, op, src[0], src[1], NULL, NULL);
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 17/44] nir/algebraic: disable inexact optimizations if SHADER_SIGNED_ZERO_INF_NAN_PRESERVE is enabled
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_algebraic.py | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/compiler/nir/nir_algebraic.py
b/src/compiler/nir/nir_algebraic.py
index fe9d1051e67..9aa1b1928b8 100644
--- a/src/compiler/nir/nir_algebraic.py
+++ b/src/compiler/nir/nir_algebraic.py
@@ -686,7 +686,7 @@ static const struct transform
${pass_name}_${opcode}_xforms[] = {
static bool
${pass_name}_block(nir_builder *build, nir_block *block,
- const bool *condition_flags)
+ const bool *condition_flags, unsigned execution_mode)
{
bool progress = false;
@@ -697,13 +697,15 @@ ${pass_name}_block(nir_builder *build, nir_block *block,
nir_alu_instr *alu = nir_instr_as_alu(instr);
if (!alu->dest.dest.is_ssa)
continue;
-
+ unsigned bit_size = alu->dest.dest.ssa.bit_size;
switch (alu->op) {
% for opcode in sorted(opcode_xforms.keys()):
case nir_op_${opcode}:
for (unsigned i = 0; i < ARRAY_SIZE(${pass_name}_${opcode}_xforms);
i++) {
const struct transform *xform = &${pass_name}_${opcode}_xforms[i];
if (condition_flags[xform->condition_offset] &&
+!(xform->search->inexact &&
+
nir_is_float_control_signed_zero_inf_nan_preserve(execution_mode, bit_size)) &&
nir_replace_instr(build, alu, xform->search, xform->replace)) {
progress = true;
break;
@@ -720,7 +722,7 @@ ${pass_name}_block(nir_builder *build, nir_block *block,
}
static bool
-${pass_name}_impl(nir_function_impl *impl, const bool *condition_flags)
+${pass_name}_impl(nir_function_impl *impl, const bool *condition_flags,
unsigned execution_mode)
{
bool progress = false;
@@ -728,7 +730,7 @@ ${pass_name}_impl(nir_function_impl *impl, const bool
*condition_flags)
nir_builder_init(, impl);
nir_foreach_block_reverse(block, impl) {
- progress |= ${pass_name}_block(, block, condition_flags);
+ progress |= ${pass_name}_block(, block, condition_flags,
execution_mode);
}
if (progress) {
@@ -750,6 +752,7 @@ ${pass_name}(nir_shader *shader)
bool progress = false;
bool condition_flags[${len(condition_list)}];
const nir_shader_compiler_options *options = shader->options;
+ const unsigned execution_mode =
shader->info.shader_float_controls_execution_mode;
(void) options;
% for index, condition in enumerate(condition_list):
@@ -758,7 +761,7 @@ ${pass_name}(nir_shader *shader)
nir_foreach_function(function, shader) {
if (function->impl)
- progress |= ${pass_name}_impl(function->impl, condition_flags);
+ progress |= ${pass_name}_impl(function->impl, condition_flags,
execution_mode);
}
return progress;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 08/44] util: added float to float16 conversions with RTZ and RTNE
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/util/half_float.c | 74 +++
src/util/half_float.h | 7
2 files changed, 81 insertions(+)
diff --git a/src/util/half_float.c b/src/util/half_float.c
index 63aec5c5c14..5fdcb20045b 100644
--- a/src/util/half_float.c
+++ b/src/util/half_float.c
@@ -125,6 +125,80 @@ _mesa_float_to_half(float val)
return result;
}
+uint16_t
+_mesa_float_to_float16_rtz(float val)
+{
+ const fi_type fi = {val};
+ const int flt_m = fi.i & 0x7f;
+ const int flt_e = (fi.i >> 23) & 0xff;
+ const int flt_s = (fi.i >> 31) & 0x1;
+ int s, e, m = 0;
+ uint16_t result;
+
+ /* sign bit */
+ s = flt_s;
+
+ /* handle special cases */
+ if ((flt_e == 0) && (flt_m == 0)) {
+ /* zero */
+ /* m = 0; - already set */
+ e = 0;
+ }
+ else if ((flt_e == 0) && (flt_m != 0)) {
+ /* denorm -- denorm float maps to 0 half */
+ /* m = 0; - already set */
+ e = 0;
+ }
+ else if ((flt_e == 0xff) && (flt_m == 0)) {
+ /* infinity */
+ /* m = 0; - already set */
+ e = 31;
+ }
+ else if ((flt_e == 0xff) && (flt_m != 0)) {
+ /* NaN */
+ m = 1;
+ e = 31;
+ }
+ else {
+ /* regular number */
+ const int new_exp = flt_e - 127;
+ if (new_exp < -14) {
+ /* The float32 lies in the range (0.0, min_normal16) and is rounded
+ * to a nearby float16 value. The result will be either zero,
subnormal,
+ * or normal.
+ */
+ e = 0;
+ m = truncf((1 << 24) * fabsf(fi.f));
+ }
+ else if (new_exp > 15) {
+ /* map this value to infinity */
+ /* m = 0; - already set */
+ e = 31;
+ }
+ else {
+ /* The float32 lies in the range
+ * [min_normal16, max_normal16 + max_step16)
+ * and is rounded to a nearby float16 value. The result will be
+ * either normal or infinite.
+ */
+ e = new_exp + 15;
+ m = truncf(flt_m / (float) (1 << 13));
+ }
+ }
+
+ assert(0 <= m && m <= 1024);
+ if (m == 1024) {
+ /* The float32 was rounded upwards into the range of the next exponent,
+ * so bump the exponent. This correctly handles the case where f32
+ * should be rounded up to float16 infinity.
+ */
+ ++e;
+ m = 0;
+ }
+
+ result = (s << 15) | (e << 10) | m;
+ return result;
+}
/**
* Convert a 2-byte half float to a 4-byte float.
diff --git a/src/util/half_float.h b/src/util/half_float.h
index 01557424735..df90802bf34 100644
--- a/src/util/half_float.h
+++ b/src/util/half_float.h
@@ -39,6 +39,13 @@ uint16_t _mesa_float_to_half(float val);
float _mesa_half_to_float(uint16_t val);
uint8_t _mesa_half_to_unorm8(uint16_t v);
uint16_t _mesa_uint16_div_64k_to_half(uint16_t v);
+uint16_t _mesa_float_to_float16_rtz(float val);
+
+static inline uint16_t
+_mesa_float_to_float16_rtne(float val)
+{
+ return _mesa_float_to_half(val);
+}
static inline bool
_mesa_half_is_negative(uint16_t h)
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 14/44] nir: add new fdot* opcodes taking into account rounding mode
According to Vulkan spec, the new execution modes affect only
correctly rounded SPIR-V instructions, which includes FaceForward.
FaceForward is lowered into fdot* instructions.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_builder.h | 32 +++
src/compiler/nir/nir_lower_alu_to_scalar.c | 9 +
src/compiler/nir/nir_opcodes.py| 45 +-
3 files changed, 67 insertions(+), 19 deletions(-)
diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
index 2a36eb3c91b..4c5f044aaf2 100644
--- a/src/compiler/nir/nir_builder.h
+++ b/src/compiler/nir/nir_builder.h
@@ -521,6 +521,38 @@ nir_fdot(nir_builder *build, nir_ssa_def *src0,
nir_ssa_def *src1)
return NULL;
}
+static inline nir_ssa_def *
+nir_fdot_rtne(nir_builder *build, nir_ssa_def *src0, nir_ssa_def *src1)
+{
+ assert(src0->num_components == src1->num_components);
+ switch (src0->num_components) {
+ case 1: return nir_fmul_rtne(build, src0, src1);
+ case 2: return nir_fdot2_rtne(build, src0, src1);
+ case 3: return nir_fdot3_rtne(build, src0, src1);
+ case 4: return nir_fdot4_rtne(build, src0, src1);
+ default:
+ unreachable("bad component size");
+ }
+
+ return NULL;
+}
+
+static inline nir_ssa_def *
+nir_fdot_rtz(nir_builder *build, nir_ssa_def *src0, nir_ssa_def *src1)
+{
+ assert(src0->num_components == src1->num_components);
+ switch (src0->num_components) {
+ case 1: return nir_fmul_rtz(build, src0, src1);
+ case 2: return nir_fdot2_rtz(build, src0, src1);
+ case 3: return nir_fdot3_rtz(build, src0, src1);
+ case 4: return nir_fdot4_rtz(build, src0, src1);
+ default:
+ unreachable("bad component size");
+ }
+
+ return NULL;
+}
+
static inline nir_ssa_def *
nir_bany_inequal(nir_builder *b, nir_ssa_def *src0, nir_ssa_def *src1)
{
diff --git a/src/compiler/nir/nir_lower_alu_to_scalar.c
b/src/compiler/nir/nir_lower_alu_to_scalar.c
index 9b175878c15..2ed4098d59b 100644
--- a/src/compiler/nir/nir_lower_alu_to_scalar.c
+++ b/src/compiler/nir/nir_lower_alu_to_scalar.c
@@ -91,6 +91,12 @@ lower_alu_instr_scalar(nir_alu_instr *instr, nir_builder *b)
case name##4: \
lower_reduction(instr, chan, merge, b); \
return true;
+#define LOWER_REDUCTION_ROUNDING(name, chan, merge, rounding)\
+ case name##2_##rounding: \
+ case name##3_##rounding: \
+ case name##4_##rounding: \
+ lower_reduction(instr, chan, merge, b); \
+ return true;
switch (instr->op) {
case nir_op_vec4:
@@ -198,6 +204,9 @@ lower_alu_instr_scalar(nir_alu_instr *instr, nir_builder *b)
return false;
LOWER_REDUCTION(nir_op_fdot, nir_op_fmul, nir_op_fadd);
+ LOWER_REDUCTION_ROUNDING(nir_op_fdot, nir_op_fmul_rtne,
nir_op_fadd_rtne, rtne);
+ LOWER_REDUCTION_ROUNDING(nir_op_fdot, nir_op_fmul_rtz, nir_op_fadd_rtz,
rtz);
+
LOWER_REDUCTION(nir_op_ball_fequal, nir_op_feq, nir_op_iand);
LOWER_REDUCTION(nir_op_ball_iequal, nir_op_ieq, nir_op_iand);
LOWER_REDUCTION(nir_op_bany_fnequal, nir_op_fne, nir_op_ior);
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index d0087d350a8..21f6569c888 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -474,7 +474,7 @@ def binop_horiz(name, out_size, out_type, src1_size,
src1_type, src2_size,
False, "", const_expr, "")
def binop_reduce(name, output_size, output_type, src_type, prereduce_expr,
- reduce_expr, final_expr):
+ reduce_expr, final_expr, rounding_mode):
def final(src):
return final_expr.format(src= "(" + src + ")")
def reduce_(src0, src1):
@@ -485,15 +485,15 @@ def binop_reduce(name, output_size, output_type,
src_type, prereduce_expr,
src1 = prereduce("src0.y", "src1.y")
src2 = prereduce("src0.z", "src1.z")
src3 = prereduce("src0.w", "src1.w")
- opcode(name + "2", output_size, output_type,
+ opcode(name + "2" + rounding_mode, output_size, output_type,
[2, 2], [src_type, src_type], False, commutative,
- final(reduce_(src0, src1)), "")
- opcode(name + "3", output_size, output_type,
+ final(reduce_(src0, src1)), rounding_mode)
+ opcode(name + "3"+ rounding_mode, output_size, output_type,
[3, 3], [src_type, src_type], False, commutative,
- final(reduce_(reduce_(src0, src1), src2)), "")
- opcode(name + "4", output_size, output_type,
+ final(reduce_(reduce_(src0, src1), src2)), rounding_mode)
+ opcode(name + "4" + rounding_mode, output_size, output_type,
[4, 4], [src_type, src_type], False, commutative,
- final(reduce_(reduce_(src0, src1), reduce_(src2, src3))), "")
+
[Mesa-dev] [PATCH v3 10/44] nir: add rounding mode support to Opcode class in nir_opcodes.py
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir.h| 3 ++
src/compiler/nir/nir_opcodes.py | 90 ---
src/compiler/nir/nir_opcodes_c.py | 4 +-
3 files changed, 52 insertions(+), 45 deletions(-)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index a84c46507e2..cbc5bcff7d3 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -995,6 +995,9 @@ typedef struct {
/* Whether this represents a numeric conversion opcode */
bool is_conversion;
+
+ /* Shader float controls mode */
+ nir_rounding_mode rounding_mode;
} nir_op_info;
extern const nir_op_info nir_op_infos[nir_num_opcodes];
diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py
index dc4cd9ac63d..21f6ee6f742 100644
--- a/src/compiler/nir/nir_opcodes.py
+++ b/src/compiler/nir/nir_opcodes.py
@@ -33,7 +33,8 @@ class Opcode(object):
NOTE: this must be kept in sync with nir_op_info
"""
def __init__(self, name, output_size, output_type, input_sizes,
-input_types, is_conversion, algebraic_properties, const_expr):
+input_types, is_conversion, algebraic_properties, const_expr,
+rounding_mode):
"""Parameters:
- name is the name of the opcode (prepend nir_op_ for the enum name)
@@ -74,6 +75,7 @@ class Opcode(object):
assert isinstance(is_conversion, bool)
assert isinstance(algebraic_properties, str)
assert isinstance(const_expr, str)
+ assert isinstance(rounding_mode, str)
assert len(input_sizes) == len(input_types)
assert 0 <= output_size <= 4
for size in input_sizes:
@@ -88,6 +90,7 @@ class Opcode(object):
self.input_types = input_types
self.is_conversion = is_conversion
self.algebraic_properties = algebraic_properties
+ self.rounding_mode = rounding_mode
self.const_expr = const_expr
# helper variables for strings
@@ -141,22 +144,22 @@ associative = "associative "
opcodes = {}
def opcode(name, output_size, output_type, input_sizes, input_types,
- is_conversion, algebraic_properties, const_expr):
+ is_conversion, algebraic_properties, const_expr, rounding_mode):
assert name not in opcodes
opcodes[name] = Opcode(name, output_size, output_type, input_sizes,
input_types, is_conversion, algebraic_properties,
- const_expr)
+ const_expr, rounding_mode)
-def unop_convert(name, out_type, in_type, const_expr):
- opcode(name, 0, out_type, [0], [in_type], False, "", const_expr)
+def unop_convert(name, out_type, in_type, const_expr, rounding_mode):
+ opcode(name, 0, out_type, [0], [in_type], False, "", const_expr,
rounding_mode)
def unop(name, ty, const_expr):
- opcode(name, 0, ty, [0], [ty], False, "", const_expr)
+ opcode(name, 0, ty, [0], [ty], False, "", const_expr, "")
def unop_horiz(name, output_size, output_type, input_size, input_type,
const_expr):
opcode(name, output_size, output_type, [input_size], [input_type],
- False, "", const_expr)
+ False, "", const_expr, "")
def unop_reduce(name, output_size, output_type, input_type, prereduce_expr,
reduce_expr, final_expr):
@@ -177,8 +180,8 @@ def unop_reduce(name, output_size, output_type, input_type,
prereduce_expr,
unop_horiz(name + "4", output_size, output_type, 4, input_type,
final(reduce_(reduce_(src0, src1), reduce_(src2, src3
-def unop_numeric_convert(name, out_type, in_type, const_expr):
- opcode(name, 0, out_type, [0], [in_type], True, "", const_expr)
+def unop_numeric_convert(name, out_type, in_type, const_expr, rnd_mode):
+ opcode(name, 0, out_type, [0], [in_type], True, "", const_expr, rnd_mode)
# These two move instructions differ in what modifiers they support and what
# the negate modifier means. Otherwise, they are identical.
@@ -223,12 +226,11 @@ for src_t in [tint, tuint, tfloat, tbool]:
for rnd_mode in rnd_modes:
unop_numeric_convert("{0}2{1}{2}{3}".format(src_t[0],
dst_t[0],
bit_size,
rnd_mode),
- dst_t + str(bit_size), src_t, "src0")
+ dst_t + str(bit_size), src_t, "src0",
rnd_mode)
else:
conv_expr = "src0 != 0" if dst_t == tbool else "src0"
unop_numeric_convert("{0}2{1}{2}".format(src_t[0], dst_t[0],
bit_size),
- dst_t + str(bit_size), src_t, conv_expr)
-
+ dst_t + str(bit_size), src_t, conv_expr, ""
[Mesa-dev] [PATCH v3 19/44] nir/algebraic: add lowerings for ldexp with rounding modes
---
src/compiler/nir/nir_opt_algebraic.py | 70 +++
1 file changed, 70 insertions(+)
diff --git a/src/compiler/nir/nir_opt_algebraic.py
b/src/compiler/nir/nir_opt_algebraic.py
index 3800db1da20..3384c9c2e67 100644
--- a/src/compiler/nir/nir_opt_algebraic.py
+++ b/src/compiler/nir/nir_opt_algebraic.py
@@ -890,10 +890,80 @@ def ldexp(f, exp, bits):
pow2_2 = fexp2i(('isub', exp, ('ishr', exp, 1)), bits)
return ('fmul', ('fmul', f, pow2_1), pow2_2)
+def ldexp_rtne(f, exp, bits):
+ # First, we clamp exp to a reasonable range. The maximum possible range
+ # for a normal exponent is [-126, 127] and, throwing in denormals, you get
+ # a maximum range of [-149, 127]. This means that we can potentially have
+ # a swing of +-276. If you start with FLT_MAX, you actually have to do
+ # ldexp(FLT_MAX, -278) to get it to flush all the way to zero. The GLSL
+ # spec, on the other hand, only requires that we handle an exponent value
+ # in the range [-126, 128]. This implementation is *mostly* correct; it
+ # handles a range on exp of [-252, 254] which allows you to create any
+ # value (including denorms if the hardware supports it) and to adjust the
+ # exponent of any normal value to anything you want.
+ if bits == 16:
+ exp = ('imin', ('imax', exp, -28), 30)
+ elif bits == 32:
+ exp = ('imin', ('imax', exp, -252), 254)
+ elif bits == 64:
+ exp = ('imin', ('imax', exp, -2044), 2046)
+ else:
+ assert False
+
+ # Now we compute two powers of 2, one for exp/2 and one for exp-exp/2.
+ # (We use ishr which isn't the same for -1, but the -1 case still works
+ # since we use exp-exp/2 as the second exponent.) While the spec
+ # technically defines ldexp as f * 2.0^exp, simply multiplying once doesn't
+ # work with denormals and doesn't allow for the full swing in exponents
+ # that you can get with normalized values. Instead, we create two powers
+ # of two and multiply by them each in turn. That way the effective range
+ # of our exponent is doubled.
+ pow2_1 = fexp2i(('ishr', exp, 1), bits)
+ pow2_2 = fexp2i(('isub', exp, ('ishr', exp, 1)), bits)
+ return ('fmul_rtne', ('fmul_rtne', f, pow2_1), pow2_2)
+
+def ldexp_rtz(f, exp, bits):
+ # First, we clamp exp to a reasonable range. The maximum possible range
+ # for a normal exponent is [-126, 127] and, throwing in denormals, you get
+ # a maximum range of [-149, 127]. This means that we can potentially have
+ # a swing of +-276. If you start with FLT_MAX, you actually have to do
+ # ldexp(FLT_MAX, -278) to get it to flush all the way to zero. The GLSL
+ # spec, on the other hand, only requires that we handle an exponent value
+ # in the range [-126, 128]. This implementation is *mostly* correct; it
+ # handles a range on exp of [-252, 254] which allows you to create any
+ # value (including denorms if the hardware supports it) and to adjust the
+ # exponent of any normal value to anything you want.
+ if bits == 16:
+ exp = ('imin', ('imax', exp, -28), 30)
+ elif bits == 32:
+ exp = ('imin', ('imax', exp, -252), 254)
+ elif bits == 64:
+ exp = ('imin', ('imax', exp, -2044), 2046)
+ else:
+ assert False
+
+ # Now we compute two powers of 2, one for exp/2 and one for exp-exp/2.
+ # (We use ishr which isn't the same for -1, but the -1 case still works
+ # since we use exp-exp/2 as the second exponent.) While the spec
+ # technically defines ldexp as f * 2.0^exp, simply multiplying once doesn't
+ # work with denormals and doesn't allow for the full swing in exponents
+ # that you can get with normalized values. Instead, we create two powers
+ # of two and multiply by them each in turn. That way the effective range
+ # of our exponent is doubled.
+ pow2_1 = fexp2i(('ishr', exp, 1), bits)
+ pow2_2 = fexp2i(('isub', exp, ('ishr', exp, 1)), bits)
+ return ('fmul_rtz', ('fmul_rtz', f, pow2_1), pow2_2)
+
optimizations += [
(('ldexp@16', 'x', 'exp'), ldexp('x', 'exp', 16), 'options->lower_ldexp'),
(('ldexp@32', 'x', 'exp'), ldexp('x', 'exp', 32), 'options->lower_ldexp'),
(('ldexp@64', 'x', 'exp'), ldexp('x', 'exp', 64), 'options->lower_ldexp'),
+ (('ldexp_rtne@16', 'x', 'exp'), ldexp_rtne('x', 'exp', 16),
'options->lower_ldexp'),
+ (('ldexp_rtne@32', 'x', 'exp'), ldexp_rtne('x', 'exp', 32),
'options->lower_ldexp'),
+ (('ldexp_rtne@64', 'x', 'exp'), ldexp_rtne('x', 'exp', 64),
'options->lower_ldexp'),
+ (('ldexp_rtz@16', 'x', 'exp'), ldexp_rtz('x', 'exp', 16),
'options->lower_ldexp'),
+ (('ldexp_rtz@32', 'x', 'exp'), ldexp_rtz('x', 'exp', 32),
'options->lower_ldexp'),
+ (('ldexp_rtz@64', 'x', 'exp'), ldexp_rtz('x', 'exp', 64),
'options->lower_ldexp'),
]
# Unreal Engine 4 demo applications open-codes bitfieldReverse()
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
[Mesa-dev] [PATCH v3 02/44] spirv/nir: keep track of SPV_KHR_shader_float_controls execution modes
v2:
- Add support for rounding modes for each floating point bit size.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/shader_enums.h | 20 +++
src/compiler/shader_info.h| 3 +++
src/compiler/spirv/spirv_to_nir.c | 41 +++
3 files changed, 64 insertions(+)
diff --git a/src/compiler/shader_enums.h b/src/compiler/shader_enums.h
index 1dff01484b5..4dbfe715e21 100644
--- a/src/compiler/shader_enums.h
+++ b/src/compiler/shader_enums.h
@@ -768,6 +768,26 @@ enum compare_func
COMPARE_FUNC_ALWAYS,
};
+enum shader_float_controls
+{
+ SHADER_DEFAULT_FLOAT_CONTROL_MODE = 0x,
+ SHADER_DENORM_PRESERVE_FP16 = 0x0001,
+ SHADER_DENORM_PRESERVE_FP32 = 0x0002,
+ SHADER_DENORM_PRESERVE_FP64 = 0x0004,
+ SHADER_DENORM_FLUSH_TO_ZERO_FP16= 0x0008,
+ SHADER_DENORM_FLUSH_TO_ZERO_FP32= 0x0010,
+ SHADER_DENORM_FLUSH_TO_ZERO_FP64= 0x0020,
+ SHADER_SIGNED_ZERO_INF_NAN_PRESERVE_FP16= 0x0040,
+ SHADER_SIGNED_ZERO_INF_NAN_PRESERVE_FP32= 0x0080,
+ SHADER_SIGNED_ZERO_INF_NAN_PRESERVE_FP64= 0x0100,
+ SHADER_ROUNDING_MODE_RTE_FP16 = 0x0200,
+ SHADER_ROUNDING_MODE_RTE_FP32 = 0x0400,
+ SHADER_ROUNDING_MODE_RTE_FP64 = 0x0800,
+ SHADER_ROUNDING_MODE_RTZ_FP16 = 0x1000,
+ SHADER_ROUNDING_MODE_RTZ_FP32 = 0x2000,
+ SHADER_ROUNDING_MODE_RTZ_FP64 = 0x4000,
+};
+
#ifdef __cplusplus
} /* extern "C" */
#endif
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index 45fb00a9cfe..d37dc52be61 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -144,6 +144,9 @@ typedef struct shader_info {
/** Was this shader linked with any transform feedback varyings? */
bool has_transform_feedback_varyings;
+ /* SPV_KHR_shader_float_controls: execution mode for floating point ops */
+ unsigned shader_float_controls_execution_mode;
+
union {
struct {
/* Which inputs are doubles */
diff --git a/src/compiler/spirv/spirv_to_nir.c
b/src/compiler/spirv/spirv_to_nir.c
index dea36b839a6..3f23e799431 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3933,6 +3933,47 @@ vtn_handle_execution_mode(struct vtn_builder *b, struct
vtn_value *entry_point,
vtn_assert(b->shader->info.stage == MESA_SHADER_FRAGMENT);
break;
+ case SpvExecutionModeDenormPreserve:
+ switch (mode->literals[0]) {
+ case 16: b->shader->info.shader_float_controls_execution_mode |=
SHADER_DENORM_PRESERVE_FP16; break;
+ case 32: b->shader->info.shader_float_controls_execution_mode |=
SHADER_DENORM_PRESERVE_FP32; break;
+ case 64: b->shader->info.shader_float_controls_execution_mode |=
SHADER_DENORM_PRESERVE_FP64; break;
+ default: vtn_fail("Floating point type not supported");
+ }
+ break;
+ case SpvExecutionModeDenormFlushToZero:
+ switch (mode->literals[0]) {
+ case 16: b->shader->info.shader_float_controls_execution_mode |=
SHADER_DENORM_FLUSH_TO_ZERO_FP16; break;
+ case 32: b->shader->info.shader_float_controls_execution_mode |=
SHADER_DENORM_FLUSH_TO_ZERO_FP32; break;
+ case 64: b->shader->info.shader_float_controls_execution_mode |=
SHADER_DENORM_FLUSH_TO_ZERO_FP64; break;
+ default: vtn_fail("Floating point type not supported");
+ }
+ break;
+ case SpvExecutionModeSignedZeroInfNanPreserve:
+ switch (mode->literals[0]) {
+ case 16: b->shader->info.shader_float_controls_execution_mode |=
SHADER_SIGNED_ZERO_INF_NAN_PRESERVE_FP16; break;
+ case 32: b->shader->info.shader_float_controls_execution_mode |=
SHADER_SIGNED_ZERO_INF_NAN_PRESERVE_FP32; break;
+ case 64: b->shader->info.shader_float_controls_execution_mode |=
SHADER_SIGNED_ZERO_INF_NAN_PRESERVE_FP64; break;
+ default: vtn_fail("Floating point type not supported");
+ }
+ break;
+ case SpvExecutionModeRoundingModeRTE:
+ switch (mode->literals[0]) {
+ case 16: b->shader->info.shader_float_controls_execution_mode |=
SHADER_ROUNDING_MODE_RTE_FP16; break;
+ case 32: b->shader->info.shader_float_controls_execution_mode |=
SHADER_ROUNDING_MODE_RTE_FP32; break;
+ case 64: b->shader->info.shader_float_controls_execution_mode |=
SHADER_ROUNDING_MODE_RTE_FP64; break;
+ default: vtn_fail("Floating point type not supported");
+ }
+ break;
+ case SpvExecutionModeRoundingModeRTZ:
+ switch (mode->literals[0]) {
+ case 16: b->shader->info.shader_float_controls_execution_mode |=
SHADER_ROUNDING_MODE_RTZ_FP16; break;
+ case 32: b->shader->info.shader_float_controls_execution_mode |=
SHADER_ROUNDING_MODE_RTZ_FP3
[Mesa-dev] [PATCH v3 04/44] nir: add support for flushing to zero denorm constants
v2:
- Refactor conditions and shared function (Connor)
- Move code to nir_eval_const_opcode() (Connor)
- Don't flush to zero on fquantize2f16
From Vulkan spec, VK_KHR_shader_float_controls section:
"3) Do denorm and rounding mode controls apply to OpSpecConstantOp?
RESOLVED: Yes, except when the opcode is OpQuantizeToF16."
v3:
- Fix bit size (Connor)
- Fix execution mode on nir_loop_analize (Connor)
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir_constant_expressions.h | 3 +-
src/compiler/nir/nir_constant_expressions.py | 71 ++--
src/compiler/nir/nir_loop_analyze.c | 22 +++---
src/compiler/nir/nir_opt_constant_folding.c | 15 +++--
src/compiler/spirv/spirv_to_nir.c| 3 +-
5 files changed, 90 insertions(+), 24 deletions(-)
diff --git a/src/compiler/nir/nir_constant_expressions.h
b/src/compiler/nir/nir_constant_expressions.h
index 1d6bbbc25d3..a2d416abc45 100644
--- a/src/compiler/nir/nir_constant_expressions.h
+++ b/src/compiler/nir/nir_constant_expressions.h
@@ -31,6 +31,7 @@
#include "nir.h"
nir_const_value nir_eval_const_opcode(nir_op op, unsigned num_components,
- unsigned bit_size, nir_const_value *src);
+ unsigned bit_size, nir_const_value *src,
+ unsigned float_controls_execution_mode);
#endif /* NIR_CONSTANT_EXPRESSIONS_H */
diff --git a/src/compiler/nir/nir_constant_expressions.py
b/src/compiler/nir/nir_constant_expressions.py
index 505cdd8baae..e79590f8359 100644
--- a/src/compiler/nir/nir_constant_expressions.py
+++ b/src/compiler/nir/nir_constant_expressions.py
@@ -66,6 +66,37 @@ template = """\
#include "util/bigmath.h"
#include "nir_constant_expressions.h"
+/**
+ * Checks if the provided value is a denorm and flushes it to zero.
+*/
+static nir_const_value
+constant_denorm_flush_to_zero(nir_const_value value, unsigned index, unsigned
bit_size)
+{
+ switch(bit_size) {
+ case 64:
+ if (value.u64[index] < 0x0010)
+ value.u64[index] = 0;
+ if (value.u64[index] & 0x8000 &&
+ !(value.u64[index] & 0x7ff0))
+ value.u64[index] = 0x8000;
+ break;
+ case 32:
+ if (value.u32[index] < 0x0080)
+ value.u32[index] = 0;
+ if (value.u32[index] & 0x8000 &&
+ !(value.u32[index] & 0x7f80))
+ value.u32[index] = 0x8000;
+ break;
+ case 16:
+ if (value.u16[index] < 0x0400)
+ value.u16[index] = 0;
+ if (value.u16[index] & 0x8000 &&
+ !(value.u16[index] & 0x7c00))
+ value.u16[index] = 0x8000;
+ }
+ return value;
+}
+
/**
* Evaluate one component of packSnorm4x8.
*/
@@ -260,7 +291,7 @@ struct ${type}${width}_vec {
% endfor
% endfor
-<%def name="evaluate_op(op, bit_size)">
+<%def name="evaluate_op(op, bit_size, execution_mode)">
<%
output_type = type_add_size(op.output_type, bit_size)
input_types = [type_add_size(type_, bit_size) for type_ in op.input_types]
@@ -343,6 +374,18 @@ struct ${type}${width}_vec {
% else:
_dst_val.${get_const_field(output_type)}[_i] = dst;
% endif
+
+ % if op.name != "fquantize2f16" and type_base_type(output_type) ==
"float":
+% if type_has_size(output_type):
+ if (execution_mode &
SHADER_DENORM_FLUSH_TO_ZERO_FP${type_size(output_type)}) {
+ _dst_val = constant_denorm_flush_to_zero(_dst_val, _i,
${type_size(output_type)});
+ }
+% else:
+ if (execution_mode & SHADER_DENORM_FLUSH_TO_ZERO_FP${bit_size})
{
+ _dst_val = constant_denorm_flush_to_zero(_dst_val, _i,
bit_size);
+ }
+%endif
+ % endif
}
% else:
## In the non-per-component case, create a struct dst with
@@ -375,6 +418,18 @@ struct ${type}${width}_vec {
% else:
_dst_val.${get_const_field(output_type)}[${k}] = dst.${"xyzw"[k]};
% endif
+
+ % if op.name != "fquantize2f16" and type_base_type(output_type) ==
"float":
+% if type_has_size(output_type):
+ if (execution_mode &
SHADER_DENORM_FLUSH_TO_ZERO_FP${type_size(output_type)}) {
+ _dst_val = constant_denorm_flush_to_zero(_dst_val, ${k},
${type_size(output_type)});
+ }
+% else:
+ if (execution_mode & SHADER_DENORM_FLUSH_TO_ZERO_FP${bit_size})
{
+ _dst_val = constant_denorm_flush_to_zero(_dst_val, ${k},
bit_size);
+ }
+% endif
+ % endif
% endfor
% endif
@@ -383,7 +438,8 @@ struct ${typ
[Mesa-dev] [PATCH v3 05/44] spirv/glsl450: fix atan2(0, 0) lowering
We were returning 3*pi/4 when we should return 0.0 according to IEEE 754. Signed-off-by: Samuel Iglesias Gonsálvez --- src/compiler/spirv/vtn_glsl450.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/compiler/spirv/vtn_glsl450.c b/src/compiler/spirv/vtn_glsl450.c index 04807700b72..21a2464d5e7 100644 --- a/src/compiler/spirv/vtn_glsl450.c +++ b/src/compiler/spirv/vtn_glsl450.c @@ -381,8 +381,12 @@ build_atan2(nir_builder *b, nir_ssa_def *y, nir_ssa_def *x) * continuous along the whole positive y = 0 half-line, so it won't affect * the result significantly. */ - return nir_bcsel(b, nir_flt(b, nir_fmin(b, y, rcp_scaled_t), zero), -nir_fneg(b, arc), arc); + nir_ssa_def *result = nir_bcsel(b, nir_flt(b, nir_fmin(b, y, rcp_scaled_t), zero), + nir_fneg(b, arc), arc); + nir_ssa_def *is_xy_zero = nir_iand(b, + nir_feq(b, x, zero), + nir_feq(b, y, zero)); + return nir_bcsel(b, is_xy_zero, zero, result); } static nir_ssa_def * -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 03/44] nir: add auxiliary functions to detect if a mode is enabled
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/nir/nir.h | 66 ++
1 file changed, 66 insertions(+)
diff --git a/src/compiler/nir/nir.h b/src/compiler/nir/nir.h
index 740c64d2a94..a84c46507e2 100644
--- a/src/compiler/nir/nir.h
+++ b/src/compiler/nir/nir.h
@@ -877,6 +877,72 @@ nir_get_nir_type_for_glsl_type(const struct glsl_type
*type)
nir_op nir_type_conversion_op(nir_alu_type src, nir_alu_type dst,
nir_rounding_mode rnd);
+static inline bool
+nir_is_float_control_signed_zero_inf_nan_preserve(unsigned execution_mode,
unsigned bit_size)
+{
+ switch(bit_size) {
+ case 16:
+ if (execution_mode & SHADER_SIGNED_ZERO_INF_NAN_PRESERVE_FP16)
+ return true;
+ break;
+ case 32:
+ if (execution_mode & SHADER_SIGNED_ZERO_INF_NAN_PRESERVE_FP32)
+ return true;
+ break;
+ case 64:
+ if (execution_mode & SHADER_SIGNED_ZERO_INF_NAN_PRESERVE_FP64)
+ return true;
+ break;
+ default:
+ break;
+ }
+ return false;
+}
+
+static inline bool
+nir_is_rounding_mode_rtne(unsigned execution_mode, unsigned bit_size)
+{
+ switch(bit_size) {
+ case 16:
+ if (execution_mode & SHADER_ROUNDING_MODE_RTE_FP16)
+ return true;
+ break;
+ case 32:
+ if (execution_mode & SHADER_ROUNDING_MODE_RTE_FP32)
+ return true;
+ break;
+ case 64:
+ if (execution_mode & SHADER_ROUNDING_MODE_RTE_FP64)
+ return true;
+ break;
+ default:
+ break;
+ }
+ return false;
+}
+
+static inline bool
+nir_is_rounding_mode_rtz(unsigned execution_mode, unsigned bit_size)
+{
+ switch(bit_size) {
+ case 16:
+ if (execution_mode & SHADER_ROUNDING_MODE_RTZ_FP16)
+ return true;
+ break;
+ case 32:
+ if (execution_mode & SHADER_ROUNDING_MODE_RTZ_FP32)
+ return true;
+ break;
+ case 64:
+ if (execution_mode & SHADER_ROUNDING_MODE_RTZ_FP64)
+ return true;
+ break;
+ default:
+ break;
+ }
+ return false;
+}
+
typedef enum {
NIR_OP_IS_COMMUTATIVE = (1 << 0),
NIR_OP_IS_ASSOCIATIVE = (1 << 1),
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 00/44] VK_KHR_shader_float_controls implementation for ANV
Hello,
This is the third version of the VK_KHR_shader_float_controls implementation
for Intel's Vulkan driver, ANV.
You can clone this branch by executing this command:
$ git clone -b siglesias/VK_KHR_shader_float_controls-v3 \
https://github.com/Igalia/mesa.git
Remember that this branch depends on VK_KHR_shader_float16_int8 patches
that are under review.
The changes from v2 are:
- Fixed handling of rounding, signed zero, inf and NAN preserve modes
for different daya types.
- Added rounding mode support for more opcodes that are correctly rounded:
fadd, fsub, fmul, ldexp, Fract, {Matrix,Vector}TimesScalar, ModF,
FaceForward. The rest are not implemented as it makes no sense in my
opinion: fabs, fsign, ftrunc, fmax, fmin, fclamp, step, ffloor, roundEven,
round (implementation-specific), fceil, frexp. Let me know if I should
implement support for more operations.
- Addressed v2 feedback: move some code from nir_constant_expressions.py to
nir_opcodes.py, fix bug in nir_constant_expressions.py related to bit_size,
fix bug in nir_loop_analyze.c related to float controls mode usage.
- Fixed several bugs found while working on this v3.
Thanks,
Sam
Samuel Iglesias Gonsálvez (44):
spirv: check support for SPV_KHR_shader_float_controls capabilities
spirv/nir: keep track of SPV_KHR_shader_float_controls execution modes
nir: add auxiliary functions to detect if a mode is enabled
nir: add support for flushing to zero denorm constants
spirv/glsl450: fix atan2(0,0) lowering
spirv/glsl450: fix atan2(x, x) case
spirv/glsl450: fix reflect(denorm, denorm) FTZ = 0.0 case
util: added float to float16 conversions with RTZ and RTNE
util: add fp64 -> fp32 conversion support for RTNE and RTZ rounding
modes
nir: add rounding mode support to Opcode class in nir_opcodes.py
nir: add new floating point conversion opcodes taking into account
rounding mode
nir: add new fadd,fsub,fmul opcodes taking into account rounding mode
nir: add new ldexp opcodes taking into account rounding mode
nir: add new fdot* opcodes taking into account rounding mode
nir: add new ffract opcodes taking into account rounding mode
nir/constant_expressions: take into account rounding mode to convert
from float to float16 destinations
nir/algebraic: disable inexact optimizations if
SHADER_SIGNED_ZERO_INF_NAN_PRESERVE is enabled
nir/algebraic: add optimizations for fadd, fsub and fmul with rounding
mode
nir/algebraic: add lowerings for ldexp with rounding modes
spirv/nir: add rounding mode support for floating-point conversions
spirv/nir: add rounding mode support for fadd, fsub, fmul
spirv/nir: add rounding mode support for SpvOpVectorTimesScalar and
SpvOpMatrixTimesScalar
spirv/nir: add rounding mode support for GLSLstd450Ldexp
spirv/nir: add rounding mode support for FaceForward opcode
spirv/nir: add rounding mode support for GLSLstd450Modf opcode
spirv/nir: add rounding mode support for GLSLstd450Fract opcode
nir: fix denorms in unpack_half_1x16()
nir: fix denorm flush-to-zero in sqrt's lowering at
nir_lower_double_ops
nir: fix fmin/fmax support for doubles
intel/nir: call nir_opt_constant_folding before
brw_nir_apply_trig_workarounds
i965/fs: add nir_op_f2f*_{rtne,rtz}
i965/fs: add nir_op_ffract_{rtne,rtz} support
i965/fs/nir: check that fdot*_{rtne,rtz} was properly lowered
i965/fs/nir: add nir_op_unpack_half_2x16_split_*_flush_to_zero
i965/fs/generator: add support to set floating points modes in control
register
i965/fs: define emit_shader_float_controls_execution_mode() and aux
functions
i965/fs: emit shader float controls execution modes as first
instruction of shaders
i965/fs: set rounding mode when emitting affected conversion
instructions
i965/fs: set rounding mode when emitting the respective fadd and fmul
instructions
i965/fs: remove brw_rounding_mode() and use brw_float_controls_mode()
instead
i965/fs: add support for shader float control to
remove_extra_rounding_modes()
anv: add support for
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR
anv: enable support for SPV_KHR_shader_float_controls capabilities
anv: enable VK_KHR_shader_float_controls extension
src/compiler/nir/nir.h | 85
src/compiler/nir/nir_algebraic.py| 13 +-
src/compiler/nir/nir_builder.h | 32 +++
src/compiler/nir/nir_constant_expressions.h | 3 +-
src/compiler/nir/nir_constant_expressions.py | 97 -
src/compiler/nir/nir_loop_analyze.c | 22 +-
src/compiler/nir/nir_lower_alu_to_scalar.c | 20 +-
src/compiler/nir/nir_lower_double_ops.c | 9 +-
src/compiler/nir/nir_opcodes.py | 201 +--
src/compiler/nir/nir_opcodes_c.py| 8 +-
src/compiler/nir/nir_opt_algebraic.py| 143 +
src/compiler/nir/nir_opt_constant_folding.c | 15 +-
src/compiler/shader_enum
[Mesa-dev] [PATCH v3 01/44] spirv: check support for SPV_KHR_shader_float_controls capabilities
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/compiler/shader_info.h| 1 +
src/compiler/spirv/spirv_to_nir.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/src/compiler/shader_info.h b/src/compiler/shader_info.h
index e9d887a8f4b..45fb00a9cfe 100644
--- a/src/compiler/shader_info.h
+++ b/src/compiler/shader_info.h
@@ -55,6 +55,7 @@ struct spirv_supported_capabilities {
bool physical_storage_buffer_address;
bool post_depth_coverage;
bool runtime_descriptor_array;
+ bool shader_float_controls;
bool shader_viewport_index_layer;
bool stencil_export;
bool storage_8bit;
diff --git a/src/compiler/spirv/spirv_to_nir.c
b/src/compiler/spirv/spirv_to_nir.c
index c99e2a3edf0..dea36b839a6 100644
--- a/src/compiler/spirv/spirv_to_nir.c
+++ b/src/compiler/spirv/spirv_to_nir.c
@@ -3720,6 +3720,13 @@ vtn_handle_preamble_instruction(struct vtn_builder *b,
SpvOp opcode,
case SpvCapabilitySampleMaskPostDepthCoverage:
spv_check_supported(post_depth_coverage, cap);
+
+ case SpvCapabilityDenormFlushToZero:
+ case SpvCapabilityDenormPreserve:
+ case SpvCapabilitySignedZeroInfNanPreserve:
+ case SpvCapabilityRoundingModeRTE:
+ case SpvCapabilityRoundingModeRTZ:
+ spv_check_supported(shader_float_controls, cap);
break;
case SpvCapabilityPhysicalStorageBufferAddressesEXT:
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 04/29] nir: add support for flushing to zero denorm constants
On 30/01/2019 16:18, Connor Abbott wrote:
>
>
> On Tue, Dec 18, 2018 at 11:35 AM Samuel Iglesias Gonsálvez
> mailto:sigles...@igalia.com>> wrote:
>
> v2:
> - Refactor conditions and shared function (Connor)
> - Move code to nir_eval_const_opcode() (Connor)
> - Don't flush to zero on fquantize2f16
> From Vulkan spec, VK_KHR_shader_float_controls section:
>
> "3) Do denorm and rounding mode controls apply to OpSpecConstantOp?
>
> RESOLVED: Yes, except when the opcode is OpQuantizeToF16."
>
> Signed-off-by: Samuel Iglesias Gonsálvez <mailto:sigles...@igalia.com>>
> ---
> src/compiler/nir/nir_constant_expressions.h | 3 +-
> src/compiler/nir/nir_constant_expressions.py | 65 ++--
> src/compiler/nir/nir_loop_analyze.c | 7 ++-
> src/compiler/nir/nir_opt_constant_folding.c | 15 ++---
> src/compiler/spirv/spirv_to_nir.c | 3 +-
> 5 files changed, 75 insertions(+), 18 deletions(-)
>
> diff --git a/src/compiler/nir/nir_constant_expressions.h
> b/src/compiler/nir/nir_constant_expressions.h
> index 1d6bbbc25d3..a2d416abc45 100644
> --- a/src/compiler/nir/nir_constant_expressions.h
> +++ b/src/compiler/nir/nir_constant_expressions.h
> @@ -31,6 +31,7 @@
> #include "nir.h"
>
> nir_const_value nir_eval_const_opcode(nir_op op, unsigned
> num_components,
> - unsigned bit_size,
> nir_const_value *src);
> + unsigned bit_size,
> nir_const_value *src,
> + unsigned
> float_controls_execution_mode);
>
> #endif /* NIR_CONSTANT_EXPRESSIONS_H */
> diff --git a/src/compiler/nir/nir_constant_expressions.py
> b/src/compiler/nir/nir_constant_expressions.py
> index 505cdd8baae..dc2132df0d0 100644
> --- a/src/compiler/nir/nir_constant_expressions.py
> +++ b/src/compiler/nir/nir_constant_expressions.py
> @@ -66,6 +66,37 @@ template = """\
> #include "util/bigmath.h"
> #include "nir_constant_expressions.h"
>
> +/**
> + * Checks if the provided value is a denorm and flushes it to zero.
> +*/
> +static nir_const_value
> +constant_denorm_flush_to_zero(nir_const_value value, unsigned
> index, unsigned bit_size)
> +{
> + switch(bit_size) {
> + case 64:
> + if (value.u64[index] < 0x0010)
> + value.u64[index] = 0;
> + if (value.u64[index] & 0x8000 &&
> + !(value.u64[index] & 0x7ff0))
> + value.u64[index] = 0x8000;
> + break;
> + case 32:
> + if (value.u32[index] < 0x0080)
> + value.u32[index] = 0;
> + if (value.u32[index] & 0x8000 &&
> + !(value.u32[index] & 0x7f80))
> + value.u32[index] = 0x8000;
> + break;
> + case 16:
> + if (value.u16[index] < 0x0400)
> + value.u16[index] = 0;
> + if (value.u16[index] & 0x8000 &&
> + !(value.u16[index] & 0x7c00))
> + value.u16[index] = 0x8000;
> + }
> + return value;
> +}
> +
> /**
> * Evaluate one component of packSnorm4x8.
> */
> @@ -260,7 +291,7 @@ struct ${type}${width}_vec {
> % endfor
> % endfor
>
> -<%def name="evaluate_op(op, bit_size)">
> +<%def name="evaluate_op(op, bit_size, execution_mode)">
> <%
> output_type = type_add_size(op.output_type, bit_size)
> input_types = [type_add_size(type_, bit_size) for type_ in
> op.input_types]
> @@ -277,6 +308,14 @@ struct ${type}${width}_vec {
> <% continue %>
> %endif
>
> + % for k in range(op.input_sizes[j]):
> + % if op.name <http://op.name> != "fquantize2f16" and
> bit_size > 8 and op.input_types[j] == "float":
>
>
> This condition doesn't seem right. It may happen to work, but it isn't
> following NIR principles on ALU instructions. Each NIR opcode has an
> output type (given by op.output_type) and input types for each source
> (given by op.input_types). Each type may be sized, like "float32", or
> unsized like "float". All unsized inputs/outputs must have the same bit
> size at runtime. The bit_size here is the common bitsize for
> inputs/outp
Re: [Mesa-dev] [PATCH v2 14/29] nir: fix constant expressions for rounding mode conversions
On 30/01/2019 16:29, Connor Abbott wrote:
> I think maybe it would be better if we put all this in nir_opcodes.py
> instead. Again, I'd like to make sure that for every opcode, what it
> does is right next to the definition instead of buried in
> nir_constant_expressions.py.
>
OK, I'll do it.
> Also, I don't see anywhere in the series where you handle different
> rounding modes for fadd, fsub, fmul, etc.
>
Right, I did it only for the conversions. I will handle the rounding
modes for all the correctly rounded SPIR-V instructions in nir_opcodes.py.
Thanks for your feedback.
Sam
> On Tue, Dec 18, 2018 at 11:35 AM Samuel Iglesias Gonsálvez
> mailto:sigles...@igalia.com>> wrote:
>
> Signed-off-by: Samuel Iglesias Gonsálvez <mailto:sigles...@igalia.com>>
> ---
> src/compiler/nir/nir_constant_expressions.py | 46 +---
> 1 file changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/src/compiler/nir/nir_constant_expressions.py
> b/src/compiler/nir/nir_constant_expressions.py
> index dc2132df0d0..84cf819e921 100644
> --- a/src/compiler/nir/nir_constant_expressions.py
> +++ b/src/compiler/nir/nir_constant_expressions.py
> @@ -64,6 +64,7 @@ template = """\
> #include "util/rounding.h" /* for _mesa_roundeven */
> #include "util/half_float.h"
> #include "util/bigmath.h"
> +#include "util/double.h"
> #include "nir_constant_expressions.h"
>
> /**
> @@ -324,7 +325,15 @@ struct ${type}${width}_vec {
> % elif input_types[j] == "float16":
> _mesa_half_to_float(_src[${j}].u16[${k}]),
> % else:
> - _src[${j}].${get_const_field(input_types[j])}[${k}],
> + % if ("rtne" in op.rounding_mode) and ("float" in
> input_types[j]) and ("int" in output_type):
> + % if "float32" in input_types[j]:
> +
> _mesa_roundevenf(_src[${j}].${get_const_field(input_types[j])}[${k}]),
> + % else:
> +
> _mesa_roundeven(_src[${j}].${get_const_field(input_types[j])}[${k}]),
> + % endif
> + % else:
> + _src[${j}].${get_const_field(input_types[j])}[${k}],
> + % endif
> % endif
> % endfor
> % for k in range(op.input_sizes[j], 4):
> @@ -353,8 +362,27 @@ struct ${type}${width}_vec {
> const float src${j} =
> _mesa_half_to_float(_src[${j}].u16[_i]);
> % else:
> - const ${input_types[j]}_t src${j} =
> - _src[${j}].${get_const_field(input_types[j])}[_i];
> + % if ("rtne" in op.rounding_mode) and ("float" in
> input_types[j]) and ("int" in output_type):
> + % if "float32" in input_types[j]:
> + const ${input_types[j]}_t src${j} =
> +
> _mesa_roundevenf(_src[${j}].${get_const_field(input_types[j])}[_i]);
> + % else:
> + const ${input_types[j]}_t src${j} =
> +
> _mesa_roundeven(_src[${j}].${get_const_field(input_types[j])}[_i]);
> +
> + % endif
> + % elif ("float64" in input_types[j]) and ("float32"
> in output_type):
> + % if ("rtz" in op.rounding_mode):
> + const ${input_types[j]}_t src${j} =
> +
>
> _mesa_double_to_float_rtz(_src[${j}].${get_const_field(input_types[j])}[_i]);
> + % else:
> + const ${input_types[j]}_t src${j} =
> +
>
> _mesa_double_to_float_rtne(_src[${j}].${get_const_field(input_types[j])}[_i]);
> + % endif
> + % else:
> + const ${input_types[j]}_t src${j} =
> + _src[${j}].${get_const_field(input_types[j])}[_i];
> + % endif
> % endif
> % endfor
>
> @@ -378,7 +406,11 @@ struct ${type}${width}_vec {
> ## Sanitize the C value to a proper NIR 0/-1 bool
> _dst_val.${get_const_field(output_type)}[_i] = -(int)dst;
> % elif output_type == "float16":
> - _dst_val.u16[_i] = _mesa_float_to_half(dst);
> + % if "rtz&qu
[Mesa-dev] [PATCH] anv: gen9 doesn't support fast clear on single-sampled SRGB buffers
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108911 Signed-off-by: Samuel Iglesias Gonsálvez --- Lionel, I have doubts if this is only for gen9 or it should be gen9+. Can you confirm on gen10 if the sRGB bug is happening there and if this fixes it? (You would need to adapt the GEN_GEN == 9 to >=). src/intel/vulkan/genX_cmd_buffer.c | 4 1 file changed, 4 insertions(+) diff --git a/src/intel/vulkan/genX_cmd_buffer.c b/src/intel/vulkan/genX_cmd_buffer.c index 93b5269c6ba..cb08ef8df1e 100644 --- a/src/intel/vulkan/genX_cmd_buffer.c +++ b/src/intel/vulkan/genX_cmd_buffer.c @@ -324,6 +324,10 @@ color_attachment_compute_aux_usage(struct anv_device * device, break; } + /* Gen9 doesn't support fast clear on single-sampled SRGB buffers */ + if (GEN_GEN == 9 && isl_format_is_srgb(iview->planes[0].isl.format) && iview->image->samples == 1) + att_state->fast_clear = false; + /* Potentially, we could do partial fast-clears but doing so has crazy * alignment restrictions. It's easier to just restrict to full size * fast clears for now. -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 20/29] i965/fs/nir: add nir_op_unpack_half_2x16_split_*_flush_to_zero
The denorm mode is set in the control register, no need to do something else.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs_nir.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/intel/compiler/brw_fs_nir.cpp
b/src/intel/compiler/brw_fs_nir.cpp
index 11afd4b5f3b..d9376e92220 100644
--- a/src/intel/compiler/brw_fs_nir.cpp
+++ b/src/intel/compiler/brw_fs_nir.cpp
@@ -1453,10 +1453,12 @@ fs_visitor::nir_emit_alu(const fs_builder ,
nir_alu_instr *instr)
unreachable("not reached: should be handled by lower_packing_builtins");
case nir_op_unpack_half_2x16_split_x:
+ case nir_op_unpack_half_2x16_split_x_flush_to_zero:
inst = bld.emit(FS_OPCODE_UNPACK_HALF_2x16_SPLIT_X, result, op[0]);
inst->saturate = instr->dest.saturate;
break;
case nir_op_unpack_half_2x16_split_y:
+ case nir_op_unpack_half_2x16_split_y_flush_to_zero:
inst = bld.emit(FS_OPCODE_UNPACK_HALF_2x16_SPLIT_Y, result, op[0]);
inst->saturate = instr->dest.saturate;
break;
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 27/29] anv: add support for VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/vulkan/anv_device.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 67ea86c4b66..1b57e7b56f5 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -1245,6 +1245,37 @@ void anv_GetPhysicalDeviceProperties2(
properties->quadOperationsInAllStages = VK_TRUE;
break;
}
+ case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_FLOAT_CONTROLS_PROPERTIES_KHR : {
+ VkPhysicalDeviceFloatControlsPropertiesKHR *properties = (void *)ext;
+ properties->separateDenormSettings = true;
+ properties->separateRoundingModeSettings = false;
+
+ /* Broadwell does not support HF denorms and there are restrictions
+ * other gens. According to Kabylake's PRM:
+ *
+ * "math - Extended Math Function
+ * [...]
+ * Restriction : Half-float denorms are always retained."
+ */
+ properties->shaderDenormFlushToZeroFloat16 = false;
+ properties->shaderDenormPreserveFloat16 = pdevice->info.gen > 8;
+ properties->shaderRoundingModeRTEFloat16 = true;
+ properties->shaderRoundingModeRTZFloat16 = true;
+ properties->shaderSignedZeroInfNanPreserveFloat16 = true;
+
+ properties->shaderDenormFlushToZeroFloat32 = true;
+ properties->shaderDenormPreserveFloat32 = true;
+ properties->shaderRoundingModeRTEFloat32 = true;
+ properties->shaderRoundingModeRTZFloat32 = true;
+ properties->shaderSignedZeroInfNanPreserveFloat32 = true;
+
+ properties->shaderDenormFlushToZeroFloat64 = true;
+ properties->shaderDenormPreserveFloat64 = true;
+ properties->shaderRoundingModeRTEFloat64 = true;
+ properties->shaderRoundingModeRTZFloat64 = true;
+ properties->shaderSignedZeroInfNanPreserveFloat64 = true;
+ break;
+ }
case
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VERTEX_ATTRIBUTE_DIVISOR_PROPERTIES_EXT: {
VkPhysicalDeviceVertexAttributeDivisorPropertiesEXT *props =
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 22/29] i965/fs: define emit_shader_float_controls_execution_mode() and aux functions
We need this function to emit code that setups the control register later with
the defined execution mode for the shader.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs.h | 1 +
src/intel/compiler/brw_fs_visitor.cpp | 52 +++
2 files changed, 53 insertions(+)
diff --git a/src/intel/compiler/brw_fs.h b/src/intel/compiler/brw_fs.h
index f79f8554fb9..3f38faf94bb 100644
--- a/src/intel/compiler/brw_fs.h
+++ b/src/intel/compiler/brw_fs.h
@@ -187,6 +187,7 @@ public:
void emit_gen6_gather_wa(uint8_t wa, fs_reg dst);
fs_reg resolve_source_modifiers(const fs_reg );
void emit_discard_jump();
+ void emit_shader_float_controls_execution_mode();
bool opt_peephole_sel();
bool opt_peephole_csel();
bool opt_peephole_predicated_break();
diff --git a/src/intel/compiler/brw_fs_visitor.cpp
b/src/intel/compiler/brw_fs_visitor.cpp
index 51a0ca2374a..2da06cf78d0 100644
--- a/src/intel/compiler/brw_fs_visitor.cpp
+++ b/src/intel/compiler/brw_fs_visitor.cpp
@@ -198,6 +198,58 @@ fs_visitor::emit_interpolation_setup_gen4()
abld.emit(SHADER_OPCODE_RCP, this->pixel_w, wpos_w);
}
+static unsigned
+brw_rnd_mode_from_nir(unsigned mode, unsigned *mask)
+{
+ unsigned brw_mode = 0;
+ *mask = 0;
+
+ if (mode & SHADER_ROUNDING_MODE_RTZ) {
+ brw_mode |= BRW_RND_MODE_RTZ << BRW_CR0_RND_MODE_SHIFT;
+ *mask |= BRW_CR0_RND_MODE_MASK;
+ }
+ if (mode & SHADER_ROUNDING_MODE_RTE) {
+ brw_mode |= BRW_RND_MODE_RTNE << BRW_CR0_RND_MODE_SHIFT;
+ *mask |= BRW_CR0_RND_MODE_MASK;
+ }
+ if (mode & SHADER_DENORM_PRESERVE_FP16) {
+ brw_mode |= BRW_CR0_FP16_DENORM_PRESERVE;
+ *mask |= BRW_CR0_FP16_DENORM_PRESERVE;
+ }
+ if (mode & SHADER_DENORM_PRESERVE_FP32) {
+ brw_mode |= BRW_CR0_FP32_DENORM_PRESERVE;
+ *mask |= BRW_CR0_FP32_DENORM_PRESERVE;
+ }
+ if (mode & SHADER_DENORM_PRESERVE_FP64) {
+ brw_mode |= BRW_CR0_FP64_DENORM_PRESERVE;
+ *mask |= BRW_CR0_FP64_DENORM_PRESERVE;
+ }
+ if (mode & SHADER_DENORM_FLUSH_TO_ZERO_FP16)
+ *mask |= BRW_CR0_FP16_DENORM_PRESERVE;
+ if (mode & SHADER_DENORM_FLUSH_TO_ZERO_FP32)
+ *mask |= BRW_CR0_FP32_DENORM_PRESERVE;
+ if (mode & SHADER_DENORM_FLUSH_TO_ZERO_FP64)
+ *mask |= BRW_CR0_FP64_DENORM_PRESERVE;
+ if (mode == SHADER_DEFAULT_FLOAT_CONTROL_MODE)
+ *mask |= BRW_CR0_RND_MODE_MASK;
+
+ return brw_mode;
+}
+
+void
+fs_visitor::emit_shader_float_controls_execution_mode()
+{
+ unsigned execution_mode =
this->nir->info.shader_float_controls_execution_mode;
+ if (execution_mode == SHADER_DEFAULT_FLOAT_CONTROL_MODE)
+ return;
+
+ fs_builder abld = bld.annotate("shader floats control execution mode");
+ unsigned mask = 0;
+ unsigned mode = brw_rnd_mode_from_nir(execution_mode, );
+ abld.emit(SHADER_OPCODE_FLOAT_CONTROL_MODE, bld.null_reg_ud(),
+ brw_imm_d(mode), brw_imm_d(mask));
+}
+
/** Emits the interpolation for the varying inputs. */
void
fs_visitor::emit_interpolation_setup_gen6()
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 19/29] i965/fs: add nir_op_f2f*_{rtne,rtz}
This way, we can implement its support later if SPIR-V supports it. Right now, the RTZ, RTNE support in SPIR-V in FPRoundingMode only applies to f2f16 conversions. Signed-off-by: Samuel Iglesias Gonsálvez --- src/intel/compiler/brw_fs_nir.cpp | 4 1 file changed, 4 insertions(+) diff --git a/src/intel/compiler/brw_fs_nir.cpp b/src/intel/compiler/brw_fs_nir.cpp index d957d248fbd..11afd4b5f3b 100644 --- a/src/intel/compiler/brw_fs_nir.cpp +++ b/src/intel/compiler/brw_fs_nir.cpp @@ -789,6 +789,8 @@ fs_visitor::nir_emit_alu(const fs_builder , nir_alu_instr *instr) inst->saturate = instr->dest.saturate; break; + case nir_op_f2f64_rtne: + case nir_op_f2f64_rtz: case nir_op_f2f64: case nir_op_f2i64: case nir_op_f2u64: @@ -908,6 +910,8 @@ fs_visitor::nir_emit_alu(const fs_builder , nir_alu_instr *instr) } /* Fallthrough */ + case nir_op_f2f32_rtne: + case nir_op_f2f32_rtz: case nir_op_f2f32: case nir_op_f2i32: case nir_op_f2u32: -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 28/29] anv: enable support for SPV_KHR_shader_float_controls capabilities
Signed-off-by: Samuel Iglesias Gonsálvez --- src/intel/vulkan/anv_pipeline.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c index c303ba321c3..2781b8f0ee0 100644 --- a/src/intel/vulkan/anv_pipeline.c +++ b/src/intel/vulkan/anv_pipeline.c @@ -145,6 +145,7 @@ anv_shader_compile_to_nir(struct anv_pipeline *pipeline, .min_lod = true, .multiview = true, .variable_pointers = true, + .shader_float_controls = device->instance->physicalDevice.info.gen >= 8, .storage_16bit = device->instance->physicalDevice.info.gen >= 8, .int16 = device->instance->physicalDevice.info.gen >= 8, .float16 = device->instance->physicalDevice.info.gen >= 8, -- 2.19.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 21/29] i965/fs/generator: add support to set floating points modes in control register
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_eu.h | 4
src/intel/compiler/brw_eu_defines.h | 10 ++
src/intel/compiler/brw_eu_emit.c| 26 +
src/intel/compiler/brw_fs_generator.cpp | 8 +++-
src/intel/compiler/brw_shader.cpp | 3 +++
5 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_eu.h b/src/intel/compiler/brw_eu.h
index 9f1ca769bd3..2309d3b10d8 100644
--- a/src/intel/compiler/brw_eu.h
+++ b/src/intel/compiler/brw_eu.h
@@ -677,6 +677,10 @@ void
brw_rounding_mode(struct brw_codegen *p,
enum brw_rnd_mode mode);
+void
+brw_float_controls_mode(struct brw_codegen *p,
+unsigned mode, unsigned mask);
+
/***
* brw_eu_util.c:
*/
diff --git a/src/intel/compiler/brw_eu_defines.h
b/src/intel/compiler/brw_eu_defines.h
index affe977835b..3b5c4fbb220 100644
--- a/src/intel/compiler/brw_eu_defines.h
+++ b/src/intel/compiler/brw_eu_defines.h
@@ -412,6 +412,7 @@ enum opcode {
SHADER_OPCODE_TYPED_SURFACE_WRITE_LOGICAL,
SHADER_OPCODE_RND_MODE,
+ SHADER_OPCODE_FLOAT_CONTROL_MODE,
/**
* Byte scattered write/read opcodes.
@@ -1314,6 +1315,15 @@ enum PACKED brw_rnd_mode {
BRW_RND_MODE_UNSPECIFIED, /* Unspecified rounding mode */
};
+#define BRW_CR0_FP64_DENORM_PRESERVE (1 << 6)
+#define BRW_CR0_FP32_DENORM_PRESERVE (1 << 7)
+#define BRW_CR0_FP16_DENORM_PRESERVE (1 << 10)
+
+#define BRW_CR0_FP_MODE_MASK (BRW_CR0_FP64_DENORM_PRESERVE | \
+ BRW_CR0_FP32_DENORM_PRESERVE | \
+ BRW_CR0_FP16_DENORM_PRESERVE | \
+ BRW_CR0_RND_MODE_MASK << BRW_CR0_RND_MODE_SHIFT)
+
/* MDC_DS - Data Size Message Descriptor Control Field
* Skylake PRM, Volume 2d, page 129
*
diff --git a/src/intel/compiler/brw_eu_emit.c b/src/intel/compiler/brw_eu_emit.c
index 81474ae24f2..c3d53bc1f2a 100644
--- a/src/intel/compiler/brw_eu_emit.c
+++ b/src/intel/compiler/brw_eu_emit.c
@@ -3696,3 +3696,29 @@ brw_rounding_mode(struct brw_codegen *p,
brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
}
}
+
+/* TODO: Refactor brw_rounding_mode() to use this. */
+void
+brw_float_controls_mode(struct brw_codegen *p,
+unsigned mode, unsigned mask)
+{
+ brw_inst *inst = brw_AND(p, brw_cr0_reg(0), brw_cr0_reg(0),
+brw_imm_ud(~mask));
+ brw_inst_set_exec_size(p->devinfo, inst, BRW_EXECUTE_1);
+
+ /* From the Skylake PRM, Volume 7, page 760:
+* "Implementation Restriction on Register Access: When the control
+* register is used as an explicit source and/or destination, hardware
+* does not ensure execution pipeline coherency. Software must set the
+* thread control field to ‘switch’ for an instruction that uses
+* control register as an explicit operand."
+*/
+ brw_inst_set_thread_control(p->devinfo, inst, BRW_THREAD_SWITCH);
+
+ if (mode) {
+ brw_inst *inst_or = brw_OR(p, brw_cr0_reg(0), brw_cr0_reg(0),
+ brw_imm_ud(mode));
+ brw_inst_set_exec_size(p->devinfo, inst_or, BRW_EXECUTE_1);
+ brw_inst_set_thread_control(p->devinfo, inst_or, BRW_THREAD_SWITCH);
+ }
+}
diff --git a/src/intel/compiler/brw_fs_generator.cpp
b/src/intel/compiler/brw_fs_generator.cpp
index a5f93f20938..675baa3db52 100644
--- a/src/intel/compiler/brw_fs_generator.cpp
+++ b/src/intel/compiler/brw_fs_generator.cpp
@@ -2422,7 +2422,13 @@ fs_generator::generate_code(const cfg_t *cfg, int
dispatch_width)
case SHADER_OPCODE_RND_MODE:
assert(src[0].file == BRW_IMMEDIATE_VALUE);
- brw_rounding_mode(p, (brw_rnd_mode) src[0].d);
+ brw_rounding_mode(p, (enum brw_rnd_mode) src[0].d);
+ break;
+
+ case SHADER_OPCODE_FLOAT_CONTROL_MODE:
+ assert(src[0].file == BRW_IMMEDIATE_VALUE);
+ assert(src[1].file == BRW_IMMEDIATE_VALUE);
+ brw_float_controls_mode(p, src[0].d, src[1].d);
break;
default:
diff --git a/src/intel/compiler/brw_shader.cpp
b/src/intel/compiler/brw_shader.cpp
index d6ff6b92627..aa4eb3ae6c2 100644
--- a/src/intel/compiler/brw_shader.cpp
+++ b/src/intel/compiler/brw_shader.cpp
@@ -509,6 +509,8 @@ brw_instruction_name(const struct gen_device_info *devinfo,
enum opcode op)
case SHADER_OPCODE_RND_MODE:
return "rnd_mode";
+ case SHADER_OPCODE_FLOAT_CONTROL_MODE:
+ return "float_control_mode";
}
unreachable("not reached");
@@ -1053,6 +1055,7 @@ backend_instruction::has_side_effects() const
case TCS_OPCODE_URB_WRITE:
case TCS_OPCODE_RELEASE_INPUT:
case SHADER_OPCODE_RND_MODE:
+ case SHADER_OPCODE_FLOAT_CONTROL_MODE:
return true;
default:
return eo
[Mesa-dev] [PATCH v2 18/29] intel/nir: call nir_opt_constant_folding before brw_nir_apply_trig_workarounds
If we have fsin or fcos trigonometric operations with constant values as inputs,
we will multiply the result by 0.7 in brw_nir_apply_trig_workarounds,
making the result wrong. Running nir_opt_constant_folding before, we will
calculate correctly the result for these trignometric ops.
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_nir.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_nir.c b/src/intel/compiler/brw_nir.c
index 3b4d25213f5..2debce72db2 100644
--- a/src/intel/compiler/brw_nir.c
+++ b/src/intel/compiler/brw_nir.c
@@ -665,8 +665,10 @@ brw_preprocess_nir(const struct brw_compiler *compiler,
nir_shader *nir)
/* See also brw_nir_trig_workarounds.py */
if (compiler->precise_trig &&
- !(devinfo->gen >= 10 || devinfo->is_kabylake))
+ !(devinfo->gen >= 10 || devinfo->is_kabylake)) {
+ OPT(nir_opt_constant_folding);
OPT(brw_nir_apply_trig_workarounds);
+ }
static const nir_lower_tex_options tex_options = {
.lower_txp = ~0,
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 26/29] i965/fs: add support for shader float control to remove_extra_rounding_modes()
The remove_extra_rounding_modes() optimization will remove duplicated
rounding mode changes.
v2:
- Fix bug in the rounding mode change (Alejandro)
Signed-off-by: Samuel Iglesias Gonsálvez
---
src/intel/compiler/brw_fs.cpp | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/src/intel/compiler/brw_fs.cpp b/src/intel/compiler/brw_fs.cpp
index 0ccff00dd4c..69a4a8debfe 100644
--- a/src/intel/compiler/brw_fs.cpp
+++ b/src/intel/compiler/brw_fs.cpp
@@ -3457,9 +3457,16 @@ bool
fs_visitor::remove_extra_rounding_modes()
{
bool progress = false;
+ unsigned execution_mode =
this->nir->info.shader_float_controls_execution_mode;
+
+ brw_rnd_mode base_mode = BRW_RND_MODE_UNSPECIFIED;
+ if (execution_mode & SHADER_ROUNDING_MODE_RTE)
+ base_mode = BRW_RND_MODE_RTNE;
+ if (execution_mode & SHADER_ROUNDING_MODE_RTZ)
+ base_mode = BRW_RND_MODE_RTZ;
foreach_block (block, cfg) {
- brw_rnd_mode prev_mode = BRW_RND_MODE_UNSPECIFIED;
+ brw_rnd_mode prev_mode = base_mode;
foreach_inst_in_block_safe (fs_inst, inst, block) {
if (inst->opcode == SHADER_OPCODE_RND_MODE) {
--
2.19.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
