[Mesa-dev] TFP broken since 913d7c388d1167a6cb3ccb52eb50f4c4f183b033
sroland at vmware.com
Mon Jun 7 07:32:30 PDT 2010
On 07.06.2010 10:46, Dave Airlie wrote:
> On Sun, Jun 6, 2010 at 8:55 PM, Dave Airlie <airlied at gmail.com> wrote:
>> On Sun, Jun 6, 2010 at 5:02 PM, Dave Airlie <airlied at gmail.com> wrote:
>>> Since we ignore internal format TFP no longer works with the RGB case.
>>> So when you said it needs a sane fix, you also should have said it
>>> needs a regression fixed.
>>> I'll see if I can figure something out, TFP breaking so often is
>>> getting a bit tiresome.
>> Attached is my first attempt at this, but I've no idea if I'm going in
>> the wrong direction, some questions in the patch reproduced here:
> This makes gnome-shell work okay on r300g at least, so if we can
> figure out the correct answers for the questions I'd be happy.
> From talking to Jakob the any to any could be tricky for svga to do,
> so we should probably limit the st/mesa use of sampler views to the
> X<->A formats which should be doable.
I don't think it should be really any to any, unless I'm missing
something it should be only formats which have the same number of
channels and the same number of bits per channel (this is what the DX10
"typeless" formats are compatible with). That said, we might want to
introduce some cap bit for drivers which can't do that and only really
can handle X8->A8 and similar, this is functionality which should not be
needed by the mesa state tracker AFAICT.
More information about the mesa-dev