https://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #16 from Tobias Jakobi <liquid.acid(a)gmx.net> 2010-04-15 15:47:54 PDT ---
Yesterday I updated libdrm, mesa and xf86-video-ati to git master tip and also
pulled the latest stuff from drm-radeon-testing.
Issue is still there.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=23992
Lukasz Krotowski <lukasz.krotowski(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #8 from Lukasz Krotowski <lukasz.krotowski(a)gmail.com> 2010-04-15 10:45:40 PDT ---
Fixed in both git master and 7.8 …
[View More]with:
commit 6a5518861e541db76bae0fa69d1d025805d90f2c
Author: Maciej Cencora <m.cencora(a)gmail.com>
Date: Fri Apr 9 21:14:15 2010 +0200
r300: set proper vertex index limits also in non indexed mode
Fixes #27521, broken menus in UT2004 and broken water refraction in
Sauerbraten.
Closing.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[View Less]
Celestia 1.6.0 again shows corrupted rendering on planets, other parts
rendered correctly with the latest git pull on the nvfx-next-5 tree.
Yesterday's nvfx-next tree worked perfectly.
--
http://www.munted.org.uk
One very high maintenance cat living here.
On Thu, 2010-04-08 at 16:37 -0700, Jesse Barnes wrote:
> On Thu, 8 Apr 2010 18:38:03 -0400
> Alex Deucher <alexdeucher(a)gmail.com> wrote:
>
> > On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul <brianp(a)vmware.com> wrote:
> > >
> > > Unless there's some objection I'm going to subscribe everyone to the
> > > new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list.
> > > Probably in the next 24 hours.
> > >
> > &…
[View More]gt; Then, some of you may have to log into the mailman interface
> > > (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest
> > > mode, etc.
> > >
> > > -Brian
> >
> > Are there plans to move dri-devel as well?
>
> Yeah, I'm just getting the info for that now. But I don't think we
> have subscriber lists, so everyone will have to re-subscribe to the new
> list.
>
> I'll send out a note to dri-devel when it's all set.
Would you update <http://dri.freedesktop.org/wiki/MailingLists>? I tried
to do it myself, but I don't appear to be human enough to pass the
textcha and register an account.
Matthew W.S. Bell
[View Less]
On Sun, 2010-04-11 at 09:10 -0500, Robert Noland wrote:
> On Sat, 2010-04-10 at 19:30 +0100, Matthew W. S. Bell wrote:
> > On Mon, 2010-04-05 at 17:46 +1000, Dave Airlie wrote:
> > > Its probably not documented well anywhere, though I think the handles are
> > > 32-bit is written down somewhere.
> >
> > Ah sorry, I missed some.
>
> drm_handle_t is correct here...
No, drm_handle_t can be of a different size to void *; converting
between integers …
[View More]and pointers of different sizes causes a warning. To
eliminate the warning, the value first needs to be passed between
uintptr_t and void *, which are of the same size, and then converted to
drm_handle_t. The last part is implicit; the drm_handle_t casts are
irrelevant/useless.
Matthew
[View Less]
On Sun, Apr 11, 2010 at 8:12 PM, Jerome Glisse <glisse(a)freedesktop.org>wrote:
> On Sun, Apr 11, 2010 at 06:39:05AM +0200, Marek Olšák wrote:
> > Hi devs,
> >
> > The first attached patch fixes the calculation of mipmapped 3D texture
> sizes
> > in the CS checker, the 3rd dimension (depth) should be minified too. This
> > should probably go to 2.6.34.
> >
> > The second patch adds 2 new regs:
> > - VAP_ALT_NUM_VERTICES, along with an …
[View More]update to the CS checker.
> > - VAP_INDEX_OFFSET, I don't think this one needs to be tracked, because
> we
> > have min/max vertex index clamping, but I might be wrong.
> >
>
> I need to recheck but iirc VAP_INDEX_OFFSET doesn't count in the
> min max clipping ie we need to track it.
GL places index clamping prior to adding the index offset and if hw follows
this rule, there is nothing sane to be done. VAP_INDEX_OFFSET is completely
orthogonal to VAP_VF_MAX_VTX_INDX. The latter contains a minimum allowed
buffer-object size divided by a stride, having nothing to do with actual
indices. To support index offsets, we would have to check content of every
index buffer, which I am not a fan of. Opinions?
-Marek
[View Less]