Acked-by: Marek Olšák <marek.ol...@amd.com> Marek
On Sat, Aug 9, 2014 at 7:52 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote: > So... can I get a review on this? It's the last bit needed for ARB_gs5 > (well, except for the actual setting of the extension bit to 1) > > The only additional change I have in my local version is that instead of > > + inst->sampler_array_size = > + ir->sampler->as_dereference_array() > + ->array->variable_referenced()->type->length; > > I use ir->sampler->as_dereference_array()->array->type->array_size() > > I sent out a few piglits and they pass with the nvc0 driver on both > fermi and kepler hw (which do textures a little differently from one > another). > > -ilia > > > On Wed, Aug 6, 2014 at 12:02 PM, Marek Olšák <mar...@gmail.com> wrote: >> On Wed, Aug 6, 2014 at 5:53 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >>> pc->MaxAddressRegs = pc->MaxNativeAddressRegs = >>> _min(screen->get_shader_param(screen, sh, >>> PIPE_SHADER_CAP_MAX_ADDRS), >>> MAX_PROGRAM_ADDRESS_REGS); >>> >>> Not really sure what that's referring to... ARB_vp/fp or something? >> >> Yes, ARB_vp needs 1, ARB_fp doesn't support indirect addresing (expects 0). >> >>> >>> Anyways, this is definitely a bit of a violation of that. OTOH, so is >>> the indirect UBO indexing and indirect GS input access (assuming >>> that's allowed), since those would use ADDR[1] and every driver >>> (except nv30) returns 1, and sometimes 0 -- including >>> nv50/nvc0/r600/radeonsi. >>> >>> So... dunno what the proper way to proceed is. Fix drivers to claim >>> higher numbers? Continue the tradition of ignoring it and relying on >>> the fact that GPU's that don't support it also won't support the >>> features that cause it to get used? >> >> You don't have to worry about that for now. We can clean it up later. >> >> Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev