btw, I think I've tracked down at least one of the rendercheck issues I was having. Which seems to be a pre-existing condition. The problem is a composite operation with xrgb src and a8 dst. Ends up generating a shader along the lines of:
0: TEX TEMP[0], IN[0], SAMP[0], 2D 1: MOV TEMP[0].w, IMM[..] 2: MOV OUT[0], TEMP[0].wwww 3: END in this case, my compiler optimizes out the texture fetch. But that causes a bit of confusion in freedreno because half the driver thinks there is a texture and sets things up accordingly. I'm not entirely sure if XA should detect this.. or if that should be fixed in the driver.. BR, -R On Thu, Apr 3, 2014 at 10:53 AM, Brian Paul <bri...@vmware.com> wrote: > On 04/03/2014 08:41 AM, Brian Paul wrote: >> >> On 04/03/2014 08:13 AM, Rob Clark wrote: >>> >>> On Thu, Apr 3, 2014 at 10:07 AM, Brian Paul <bri...@vmware.com> wrote: >>>> >>>> On 04/02/2014 11:17 PM, Thomas Hellstrom wrote: >>>>> >>>>> >>>>> On 04/01/2014 05:04 PM, Rob Clark wrote: >>>>>> >>>>>> >>>>>> From: Rob Clark <robcl...@freedesktop.org> >>>>>> >>>>>> Add support to property handle solid-fill src and/or mask. Without >>>>>> this >>>>>> we fallback to sw a lot for common things like text rendering. >>>>>> >>>>>> Signed-off-by: Rob Clark <robcl...@freedesktop.org> >>>>>> --- >>>>>> src/gallium/state_trackers/xa/xa_composite.c | 88 ++++---- >>>>>> src/gallium/state_trackers/xa/xa_priv.h | 7 +- >>>>>> src/gallium/state_trackers/xa/xa_renderer.c | 289 >>>>>> ++++++++++++++++----------- >>>>>> src/gallium/state_trackers/xa/xa_tgsi.c | 31 ++- >>>>>> 4 files changed, 242 insertions(+), 173 deletions(-) >>>>> >>>>> >>>>> >>>>> Rob, >>>>> While testing this patch it looks like we sometimes set two samplers, >>>>> and the first one is NULL. >>>>> The SVGA driver asserts on that condition. >>>>> We might need to move the active sampler to the first entry in that >>>>> case, and adjust tex coords and shader accordingly. >>>>> >>>>> I'll discuss with BrianP. >>>> >>>> >>>> >>>> I think the root problem is a disagreement between texture samplers and >>>> sampler views. If a texture sampler is non-null, the corresponding >>>> sampler >>>> view be should be non-null too, and vice versa. >>>> >>>> We're tripping over an assertion when a a sampler view is non-null >>>> but the >>>> corresponding sampler is NULL. >>> >>> >>> Right.. >>> >>> Well, I think it would be not to hard to make things always start with >>> SAMP[0], which would avoid this. But I am pretty fuzzy about whether >>> it is the driver or state tracker that is wrong here.. I started with >>> the assumption that it was just a freedreno bug, but if it causes >>> problem w/ vmware too, then maybe the state tracker is at fault. >> >> >> I believe the general policy is that drivers can assume they're being >> passed valid input and consistent state. State trackers shouldn't pass >> inconsistent state to drivers. >> >> In this case, the number of texture samplers and sampler views is >> inconsistent. The drivers could examine the current shader to determine >> which samplers/views are actually used (which might be a subset of what >> was specified by the state tracker). But that's extra work that all >> drivers would have to implement. It seems much more economical to take >> care of this in the state trackers. > > > Though, with the DX10-level SAMPLE instructions, samplers and sampler views > really are independent so the number could be different there. But with TEX > instructions, the numbers should be the same. > > -Brian > > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
