[Mesa-dev] r600g: hyperz support
Ok so this time it should be it. Following patch seems to behave properly. I am still in process of checking again that they don't regress anything, i should be done monday or tuesday. If there is no objection by them i will commit them. Note that you need kernel patch for those and that by default hyperz get enabled you can disable it by setting R600_HYPERZ=0 env variable. On perf side quick benchmark shows improvement from 2% to 10% depending on the benchmark and on the GPU. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] r600g: hyperz
So this patch serie add hyperz but does not enable it by default. I think i addressed all comment in v9 for htile. I am also asking to include the flushing rework as without it hyperz lockup with thing such as gears. So with both patch most application should be fine with hyperz, but application that switch depth are the most likely to trigger lockup. From regression pov the 2 patch doesn't seems to regress anything according to piglit (r6xx,r7xx,evergreen). However, enabling hyperz lead to some rendering issue with evergreen and lightmark, but as i can't run piglit regression without lockup i haven't tracked down exactly what (my guess is that it's related to hyper-stencil). Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: hyperz
On Fri, Jul 13, 2012 at 8:11 PM, Jerome Glisse j.gli...@gmail.com wrote: On Fri, Jul 13, 2012 at 8:08 PM, Marek Olšák mar...@gmail.com wrote: Hi Jerome, I couldn't open the patch, because freedesktop.org doesn't seem to work for me today, it always times out. Anyway, non-working code shouldn't be merged into Mesa master, because it decreases the quality of the driver and is a pain to maintain. As as I said in another email, merging non-working code on purpose is a very bad idea. Please don't do it. Marek Code works, no regression, but if you enable hyperz get ready to experience lockup, likelyhood depends on what you are doing. So no i don't consider this a non working code. It does work and doesn't regress. Is it just 6xx/7xx that locks or also evergreen? Also even if we don't turn on hyperz, it probably makes sense to always have an htile buffer bound as the htile cache (and backing htile buffer) is used for Z/S compression, culling, fast ops, etc. in addition to HiZ/S if a Z or S buffer is bound. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: hyperz
On Sat, Jul 14, 2012 at 9:56 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Fri, Jul 13, 2012 at 8:11 PM, Jerome Glisse j.gli...@gmail.com wrote: On Fri, Jul 13, 2012 at 8:08 PM, Marek Olšák mar...@gmail.com wrote: Hi Jerome, I couldn't open the patch, because freedesktop.org doesn't seem to work for me today, it always times out. Anyway, non-working code shouldn't be merged into Mesa master, because it decreases the quality of the driver and is a pain to maintain. As as I said in another email, merging non-working code on purpose is a very bad idea. Please don't do it. Marek Code works, no regression, but if you enable hyperz get ready to experience lockup, likelyhood depends on what you are doing. So no i don't consider this a non working code. It does work and doesn't regress. Is it just 6xx/7xx that locks or also evergreen? Also even if we don't turn on hyperz, it probably makes sense to always have an htile buffer bound as the htile cache (and backing htile buffer) is used for Z/S compression, culling, fast ops, etc. in addition to HiZ/S if a Z or S buffer is bound. Alex Just enabling htile surface is enough to trigger the lockup, thus we can't bind the htile buffer. Quite frankly i don't know how much evergreen is an issue, i pretty much stuck with r6xx/r7xx as they were always locking up with my test case. Thought i have been able to lockup evergreen but i did have the feeling that it was lot less likely to happen. Basicly to trigger the lockup you have to switch btw a lot of depth surface/htile surface, if you just have a single depth buffer you will be fine. Thus most use case will just work properly. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] r600g: hyperz
So this patch add hyperz but does not enable it. I have been working on that for the last 7 month i just fail at not making it lockup. Same time i would prefer having this code upstream so i don't have to rebase. I try to match fglrx sync flush pattern but that would basicly mean rewritting the whole r600g. So here is a cleanup of r600g flushing i have been working on to try to fix lockup, but no success there (slightly improve thing i think but when it comes to lockup it's hard to have a metric on how more likely they are to happen or not) http://people.freedesktop.org/~glisse/0002-r600g-simplify-and-fix-flushing-and-synchronization.patch So if the feature doesn't lockup you will see on average 5% increase in performance. Anyway off to work on something else. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: hyperz
Hi Jerome, I couldn't open the patch, because freedesktop.org doesn't seem to work for me today, it always times out. Anyway, non-working code shouldn't be merged into Mesa master, because it decreases the quality of the driver and is a pain to maintain. As as I said in another email, merging non-working code on purpose is a very bad idea. Please don't do it. Marek On Fri, Jul 13, 2012 at 8:30 PM, j.gli...@gmail.com wrote: So this patch add hyperz but does not enable it. I have been working on that for the last 7 month i just fail at not making it lockup. Same time i would prefer having this code upstream so i don't have to rebase. I try to match fglrx sync flush pattern but that would basicly mean rewritting the whole r600g. So here is a cleanup of r600g flushing i have been working on to try to fix lockup, but no success there (slightly improve thing i think but when it comes to lockup it's hard to have a metric on how more likely they are to happen or not) http://people.freedesktop.org/~glisse/0002-r600g-simplify-and-fix-flushing-and-synchronization.patch So if the feature doesn't lockup you will see on average 5% increase in performance. Anyway off to work on something else. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: hyperz
On Fri, Jul 13, 2012 at 8:08 PM, Marek Olšák mar...@gmail.com wrote: Hi Jerome, I couldn't open the patch, because freedesktop.org doesn't seem to work for me today, it always times out. Anyway, non-working code shouldn't be merged into Mesa master, because it decreases the quality of the driver and is a pain to maintain. As as I said in another email, merging non-working code on purpose is a very bad idea. Please don't do it. Marek Code works, no regression, but if you enable hyperz get ready to experience lockup, likelyhood depends on what you are doing. So no i don't consider this a non working code. It does work and doesn't regress. Cheers, Jerome ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
