On Friday, April 24, 2015 04:02:18 PM Rogovin, Kevin wrote: > > > Actually I realized that you add quite a bit of support to gen4-6 logic > > that > > _isn't_ used for gen7 and higher. In the last patch of the series you claim > > to enable this only for gen7 and higher - I'm confused. > > There are two reasons: > 1. Because atoms get reused all the time across generations, it is just > easier to use > the _mesa_geomety_* functions in any batch buffer builder that is concerned > about the geometry of the render target. It keeps the code consistent and > much > easier than checking what functions and atoms are directly or indirectly used > by > different Gens. However, blorp, blitting and a few others are left untouched > since > they want to talk about the buffer, not really 3D pipeline rasterization > things. > > 2. At first I was going to support pre Gen7 hardware with the series. However, > I do not have hardware on which to test it. In truth I want this to also run > on > pre-Gen7, but without testing on device, I cannot vouch for the patches. > I believe it should just work for pre Gen7 (by just tweaking the last patch > to > enable it on pre Gen7), but I would rather be careful than in this case. I > also > confess, it is a silly extension for pre Gen7 anyways... > > -Kevin
A couple of us chatted about this, and we all agreed that it's probably not useful to enable ARB_framebuffer_no_attachments on pre-Gen7. We don't expose atomics, SSBOs, or image load/store on those platforms (and probably won't), so the only way fragment shaders can output any data is via framebuffer writes. So I'd be inclined to just not touch the pre-Gen7 code at all.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
