On 13/11/13 16:42, Ferry Huberts wrote:
The link in
http://cgit.freedesktop.org/mesa/mesa/diff/docs/index.html?id=9976a176ae62d53e8ad0c0f934d207e22ac41e85
is wrong, points to 9.2.2 i.s.o. 9.2.3
ah, and here as well
http://cgit.freedesktop.org/mesa/mesa/diff/docs/relnotes.html?id
The link in
http://cgit.freedesktop.org/mesa/mesa/diff/docs/index.html?id=9976a176ae62d53e8ad0c0f934d207e22ac41e85
is wrong, points to 9.2.2 i.s.o. 9.2.3
--
Ferry Huberts
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http
On 22/04/13 21:03, Brian Paul wrote:
> On 04/22/2013 12:17 PM, Ferry Huberts wrote:
>>
>>
>> On 22/04/13 19:38, Brian Paul wrote:
>>> MapBufferRange was present twice. MapBuffer was missing.
>>>
>>> Note: This is a candidate for the stable branch
);
It's already here
> COPY_DISPATCH(UnmapBuffer);
> - COPY_DISPATCH(MapBufferRange);
> + COPY_DISPATCH(MapBuffer);
> COPY_DISPATCH(MapBufferRange);
Maybe 'UnmapBufferRange'?
> COPY_DISPATCH(ObjectPurgeableAP
't make things worse...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Ferry Huberts
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.
On 29-06-12 21:03, Stéphane Marchesin wrote:
I'll send a revert for those, is there a way to do it without
reverting the rest of the series?
yeah, just revert the commit you want and then via 'amend' take out the
parts you don't want to revert (git gui is nice for doi
On 24-12-11 14:45, Brian Paul wrote:
> On Fri, Dec 23, 2011 at 1:19 PM, Matt Turner wrote:
>> The (swrast, i965, gallium, r600g) tuples are inconsistent and
>> confusing. If swrast, i965, and gallium support something, let's simply
>> say DONE without qualifying it.
>
> Hmm, I'm in favor of cle
tag naming convention)
>>
>> Hopefully someone can look at the bugs you've hit, get them fixed soon
>> and get a new Mesa release out with a version you can test against.
>
> Thanks!
> Benoit
> ___
> mesa-dev maili
- 0);
> + if (dst->target == PIPE_BUFFER && src->target == PIPE_BUFFER) {
> + memcpy(dst_map, src_map, w);
this will not work if dst_map and src_map overlap...
if you're sure that they never overlap: ok, else maybe use memmove?
things that
> are never going to change after initialization.
yeah, that was my point.
the table is only _a_ solution.
a different solution I sometimes employ is to lazily determine the value
on first use and then keep it cached. that requires an extra state
variable howev
replaced by retrieving a
field from the structure, since the function only returns a constant
(dependent on the type of the card).
grtz
--
Ferry Huberts
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
very good idea: it's how I used to test ASIC designs with
C-model against register model. works perfectly and is invaluable for
finding regressions!
--
Ferry Huberts
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
12 matches
Mail list logo
