On Wed, 30 Aug 2006 20:50:16 +0200 Rune Petersen <[EMAIL PROTECTED]> wrote:
> Aapo Tahkola wrote: > > On Sun, 13 Aug 2006 02:17:40 +0200 > > Rune Petersen <[EMAIL PROTECTED]> wrote: > > > >> Roland Scheidegger wrote: > >>> Rune Petersen wrote: > >>>> Roland Scheidegger wrote: > >>>>> Adam K Kirchhoff wrote: > >>>>>> Just thought I'd post some updated benchmarks of Doom3. These > >>>>>> were all run with the first timedemo at 640x480, and (for the > >>>>>> open source drivers) with ColorTiling turned on in the > >>>>>> xorg.conf file. I'll list all tests with the open source > >>>>>> drivers first: > >>>>>> > >>>>>> x700 + r300 (with arb renderer) - 5.5 FPS (There's not much > >>>>>> point in testing it with the r200 or arb2 renderers at the > >>>>>> moment.) > >>>>> What's the problem with arb2? > >>>> fragment.position input is not implemented yet. fglrx driver > >>>> parses it from VP to FP via a texcoord route. I've been hitting > >>>> my head on this for some time. Only got as far as only getting a > >>>> soft lockup which isn't very useful. > >>> That kinda makes sense. On r200 you could already pass vertex data > >>> to the fragment registers (but you couldn't use position as > >>> input), so the data was interpolated by the texcoord interpolator > >>> but texture lookup was disabled (see the ATI_fs spec / r200 dri > >>> implementation). At first sight looks like a similar mechanism > >>> might be used by r300 I guess, interpolating position or texcoords > >>> isn't too different is it? > >>> > >> I've had been looking into this, and the vertex shader is supplying > >> the position to the fragment shader as a texcoord, the only > >> apparent difference in shader setup between a position and a real > >> texcoord, is a real texcoord is supplied as input for the vertex > >> shader. > >> > >> > >> I would really like to capture the vertex program of > >> program/fp/tri-depth and the fglrx driver. > >> > >> But I'm betting the vertex shader is capable of writing to a > >> texcoord. All I need is a safe way for the vertex shader code to > >> know if the fragment shader needs the position. > >> > >> Any help with this would be great. > > > > Bug #8056 patch can do this. Take a look at > > r300_select_vertex_shader(). > > > Thank you. > > > About your patch: > > Can't reproduce your result with gearbox > [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range > check (reg=4e28 sz=1) > [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed It should be same as t->offset when the cube is drawn. > > > subtexrate: > The result is not too reliable with this, but at least it doesn't > crash =) There looks to be a mess up of src & dest. sometimes the src > is the teapot other times the root window. doSubRect cases will definitely fail. It would seem as if the clip rects would be relative to something else. Odd that it never crashes with default clip rects... -- Aapo Tahkola ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
