On Tue, 2010-01-19 at 20:18 +0100, Vignatti Tiago (Nokia-D/Helsinki)
wrote:
> Some drivers use DRI2 protocol but implement their own kernel rendering
> mananger. For these drivers, libdrm becomes useless.
>
> The only inconvenient right now to put libdrm optional to X server is
> concerning DRI2Au
Done. Took a little longer because I had to clone a clean tree so I could push
the patch... I have a lot of changes in my local Mesa that are not quite ready
to be pushed yet.
On 6/21/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I accidentally used |= instead of =. I&
Hi,
I accidentally used |= instead of =. I'll push the fix now.
Thanks for reporting the bug. :)
On 6/21/07, Panagiotis Papadakos <[EMAIL PROTECTED]> wrote:
> Hi everybody.
>
> I think that
> http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=commit;h=da1d9d97959bd1e4c8e359d28b4fd6cafdd4168a
> b
This looks like DTX or S3TC texture compression (which is partially broken); I
think there should be some more information on this on the list, and how to
disable it.
On 6/12/07, Mikko Rauhala <[EMAIL PROTECTED]> wrote:
> ti, 2007-06-12 kello 02:26 +0000, Oliver McFadden kirjoit
Hi,
I couldn't reproduce this with the latest Git of Mesa and DRM. Although R300
does have some lockup problems that get triggered after running UT2004 for a
while...
Try again using the latest Mesa and DRM from Git, and let me know if the texture
corruption problem still exists.
Thank you.
On
I think this register is the same on mobility and standard chips.
I still haven't figured it out yet, although airlied gave me a few pointers
about it.
I think that unless we can find some way to make the blob change it, it might
not be possible to determine what it does...
On 5/28/07, Martijn
Hi,
I was talking to airlied on #dri-devel about figuring out the R300_VAP_CNTL
(0x2080) register. He explained that it controls the vertex shader engine, but
other than that we don't really know. This register could be card dependent, so
I modified radeontool to dump it, and I'm posting here aski
My thoughts are, we should unify the really common stuff... but I don't think
it's possible to unify r200_tex.c and r300_tex.c. The hardware is different, and
the file would end up with an #ifdef on every 3rd line; it doesn't make sense
here.
Just for really common code it does.
I don't know what
Hi,
I have a few questions about the R300 driver. I'm just wondering about a couple
of things including the OPTIMIZE_ELTS code (r300_render.c) and
R300_VAP_INPUT_ROUTE_0_0 and R300_VAP_INPUT_ROUTE_1_0.
I cleaned up the OPTIMIZE_ELTS code to reduce duplication, and I verified that
both the optimiz
Talk is cheap. Show me the code.
Or in our case, specs... I'll get excited then. Until they do that this is just
ATI making wild claims.
On 5/11/07, Jacek Poplawski <[EMAIL PROTECTED]> wrote:
> http://www.0xdeadbeef.com/weblog/?p=288
>
> Probably nobody knows what does it mean, but maybe it's a
Done.
On 5/9/07, Brian Paul <[EMAIL PROTECTED]> wrote:
> If it's just dead code removal, go ahead.
>
> -Brian
>
> Oliver McFadden wrote:
> > Well both Keith and Jerome are okay with me removing the VTXFMT code, so
> > I'll go
> > ahead and do that
/07, Brian Paul <[EMAIL PROTECTED]> wrote:
> Oliver McFadden wrote:
> > I also think we might need to add _dri_warning/_dri_error because the
> _mesa
> > versions output "Mesa warning: %s" which implies to the user this is a
> Mesa
> > problem, not a DRI dri
Here is the patch.
On 5/9/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
I'd like some input on the VBO stuff in r300. In r300_context.h we have the
following.
/* KW: Disable this code. Driver should hook into vbo module
* directly, see i965 driver for example.
*/
ade a patch for this, but I'm not committing until I get the okay
from a few people.
Thanks.
On 5/9/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
> I also think we might need to add _dri_warning/_dri_error because the _mesa
> versions output "Mesa warning: %s" which im
ions... So maybe adding them to the common DRI code?
On 5/9/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I added the "not implemented yet" comment back, although there are other
> places
> that use 65535 so it could be some kind of hardware limit...
>
&g
Hi,
I added the "not implemented yet" comment back, although there are other places
that use 65535 so it could be some kind of hardware limit...
The only reason that I went with "camel case" r300FooBar names is because that's
what 90% of the driver uses; it's easier to change a few r300_foo_bar t
On 5/4/07, Jerome Glisse <[EMAIL PROTECTED]> wrote:
> There was a typo in my mail, i meaned lock not lockup
> when i was talking about apps sending data to gpu.
> And if multiple instance of glxgears are successfull
> to make the gpulockup this is because you are then
> sending megs of vertex to th
On 5/3/07, Zoltan Boszormenyi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> sorry for the crossposting, I don't know who to address.
>
> I am experimenting the new CFS scheduler on Linux
> and tried to start multiple glxgears to see whether
> they are really running smooth and have evenly
> distributed fram
I just updated the tool to (hopefully) calculate the AGP aperture address and
size dynamically. I'm using some code borrowed from REnouveau.
I haven't tested this yet, but it should work.
Again, if anyone is using this I'd like to get feedback on what features would
be useful. Currently I plan to
On 4/26/07, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Oliver & Dave,
>
> >
> > You maybe have missed out on #dri-devel on freenode irc, it works
> > reasonably well for getting insta-answers depending on timezone etc..
>
> Ah. I HAVE missed that. I'll have to hang out there. I usually have
> th
On 4/23/07, Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> >
> >> I just started reading the X code about 6 months ago, and the learning
> >> curve has been steep. My emails to dri-devel are answered now and
> >> again, and that is kinda frustrating when you want an answer NOW.
>
> You maybe have miss
On 4/23/07, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Awesome.
>
> As an aside, I would really like to make it easier for other people to
> hack on radeon & X.
> I've been fighting with my Radeon 200M for months, hacking when I have
> spare time.
I think we have similar goals here. I'm doing this
On 4/23/07, Phillip Ezolt <[EMAIL PROTECTED]> wrote:
> Oliver,
> I've been hacking on the RS480 (Radeon 200M) for a while, and Dave
> has (aweseomely) brought it to a point where it has the working GART,
> and a limping Mesa.
>
> Currently triangles are broken, and I have a very simple test case
I've previously filed a bug report (bug #10211) about the
R300_RB3D_DSTCACHE_CTLSTAT issue, however I couldn't prove the proposed patch
was correct. I've investigated this further and I can confirm that the blob
indeed writes 0xa to R300_RB3D_DSTCACHE_CTLSTAT before 3D operations, and 0x2
after 3D
On 3/18/07, Brian Paul <[EMAIL PROTECTED]> wrote:
> All the Glean tests that check for specific rendering results already
> have an error margin.
>
> Can you be more specific about which tests are failing and how the error
> margin might need to be changed?
>
> -Brian
I previously replied (but for
On 3/18/07, Nicolai Haehnle <[EMAIL PROTECTED]> wrote:
> I just realized I didn't send it to the list:
>
> There was yet another problem with reordering of instructions. The
> attached patch (which is against my earlier patch) should fix this.
I can confirm this fixes my problems with the first pa
Another thought; the same changed are probably needed for the vertprog code. I
think there are also a lot of bugs there.
On 3/18/07, Oliver McFadden <[EMAIL PROTECTED]> wrote:
> This patch seems to break one of my longer fragment programs. I believe this
> is
> because it&#
This patch seems to break one of my longer fragment programs. I believe this is
because it's running out of registers, but I haven't looked into it in detail
yet.
I think this patch should be committed, but directly followed by a patch to
reduce the number of registers used.
On 3/18/07, Nicolai
I notice some failures with the example tests (R300) that seem to just be
slight precision errors; I think you should add a margin for error because
usually the hardware will implement things in a faster, perhaps less precise
way.
This lower precision is still "good enough", though.
On 3/17/07,
This is very interesting and useful. Seems it's already showing some areas where
improvement is required in the R300 driver.
I'd suggest getting an account on freedesktop.org and a Git repository there. :)
Sourceforge is... less than reliable.
-
30 matches
Mail list logo
