Re: [Dri-devel] [PATCH] R200 t_vertex conversion
Ian Romanick wrote:
This is what I have done so far to convert the R200 driver to use
t_vertex. It is only a conversion for SW TCL, and it's not quite
complete. I've managed to clean up all the crashes that I could find,
but I've only tested with gears, geartrain, and tunnel. There are some
known problems:
- The textures in tunnel are not quite right. They're sort of zig-zaggy.
- The colors of two of the gears in gears are swapped. The red gear is
blue and the blue gear is red. The green gear is correct.
I chopped out all of the _r200_render_stage stuff from r200_swtcl.c. It
is unused (due to bad interactions with UT2k3), and was only confusing
me. When this patch gets committed, that code can go back in, I think.
There are two hacks that I had to do to get things working. Neither of
these needed to be done by the i830 or savage drivers. First, I had to
add a viewport matrix that remains an identity matrix. This is
because the Radeon chips do the viewport transform in hardware.
tnl_dd/t_dd_vbtmp.h had the ability to handle hardware like this, but
t_vertex apparently does not.
Just specify that element as 'EMIT_4F' or 'EMIT_3F', rather than
'EMIT_4F_VIEWPORT'.
Second, I had to force TNL to always
produce project coordinates. Again, the Radeon hardware can do the
final projection in hardware almost all the time, but due to the way the
i830 and savage drivers use use tnl-vb.NdcPtr (actually VB-NdcPtr) I
couldn't see a way around this. I may just be missing something there.
I do have one other question that probably only Keith or Daniel can
answer. :) Can t_vertex replace the immediate-mode API code-gen in the
radeon and r200 drivers? It seems like it should be able to, but I'm
not sure I can see exactly how. Does the HW TCL side just need a
tnl_attr_map just like the SW TCL side? I think looking at the SW TCL
code for so long has fried my brain...
The immediate-mode codegen pretty much cuts out the tnl module altogether and
builds hardware vertices directly. The t_vertex.c code would be redundant in
that case. If you just mean using this logic to determine the vertex format,
I suppose it's possible, but you'll run into differences between what is
needed pre-TCL vs. what is being calculated here for vertices post-TCL.
In any case, I won't have a chance to look at this again in until
probably next Wednesday. If someone could pick this up and finish it
off, that would be cool. I think it's more important to get it done
soon than have my name in the commit log. :)
-#define IND (R200_XYZW_BIT|R200_RGBA_BIT|R200_SPEC_BIT)
-#define TAG(x) x##_wgfs
-#include tnl_dd/t_dd_vbtmp.h
+#define EMIT_PAD( N ) \
+do { \
+ rmesa-swtcl.vertex_attrs[rmesa-swtcl.vertex_attr_count].attrib = 0; \
+ rmesa-swtcl.vertex_attrs[rmesa-swtcl.vertex_attr_count].format = EMIT_PAD; \
+ rmesa-swtcl.vertex_attrs[rmesa-swtcl.vertex_attr_count].offset = (N); \
+ rmesa-swtcl.vertex_attr_count++; \
+} while (0)
-#define IND (R200_XYZW_BIT|R200_RGBA_BIT|R200_SPEC_BIT|\
- R200_TEX0_BIT)
-#define TAG(x) x##_wgfst0
-#include tnl_dd/t_dd_vbtmp.h
+static void r200SetVertexFormat( GLcontext *ctx )
+{
+ r200ContextPtr rmesa = R200_CONTEXT( ctx );
+ TNLcontext *tnl = TNL_CONTEXT(ctx);
+ struct vertex_buffer *VB = tnl-vb;
+ GLuint index = tnl-render_inputs;
+ int fmt_0;
+ int fmt_1;
+ GLboolean is_tiny = GL_TRUE;
-#define IND (R200_XYZW_BIT|R200_RGBA_BIT|R200_SPEC_BIT|\
- R200_TEX0_BIT|R200_PTEX_BIT)
-#define TAG(x) x##_wgfspt0
-#include tnl_dd/t_dd_vbtmp.h
-#define IND (R200_XYZW_BIT|R200_RGBA_BIT|R200_SPEC_BIT|\
- R200_TEX0_BIT|R200_TEX1_BIT)
-#define TAG(x) x##_wgfst0t1
-#include tnl_dd/t_dd_vbtmp.h
+ /* Important:
+*/
+ VB-AttribPtr[VERT_ATTRIB_POS] = VB-NdcPtr;
+ assert( VB-NdcPtr != NULL );
+ rmesa-swtcl.vertex_attr_count = 0;
-#define IND (R200_XYZW_BIT|R200_RGBA_BIT|R200_SPEC_BIT|\
- R200_TEX0_BIT|R200_TEX1_BIT|R200_PTEX_BIT)
-#define TAG(x) x##_wgfspt0t1
-#include tnl_dd/t_dd_vbtmp.h
+ fmt_0 = R200_VTX_XY | R200_VTX_Z0;
+ fmt_1 = 0;
+ /* EMIT_ATTR's must be in order as they tell t_vertex.c how to
+* build up a hardware vertex.
+*/
+ if (index (_TNL_BITS_TEX_ANY | _TNL_BIT_COLOR1 | _TNL_BIT_FOG)) {
+ EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_4F_VIEWPORT, R200_VTX_W0 );
+ is_tiny = GL_FALSE;
+ }
+ else {
+ EMIT_ATTR( _TNL_ATTRIB_POS, EMIT_3F_VIEWPORT, 0 );
+ }
Here specifically -- if you don't want to do viewport transform in sw, don't
tell t_vertex.c to EMIT_xF_VIEWPORT.
Also - I'm not sure why you feel that COLOR1 or FOG (vertex fog, right?)
require the W coordinate, though certainly the old code did work that way,
this new code will differ from the old code in other respects so why maintain
this old limitiation?
-/***
- * Initialization
-
Re: [Dri-devel] DRI/Xfree86 Merge
On Sat, Apr 17, 2004 at 01:18:49AM +0200, Michel Dänzer wrote: On Sat, 2004-04-17 at 00:00, Alan Hourihane wrote: I could merge in XFree86 4.3.99.902 which is before the license change Are you sure? AFAIK David applied the new license (or at least a similarly controversial one) to some files before it was publicly announced. Yes, I'm positive that 4.3.99.902 is unencumbered. and closer to what X.Org went with for now. That will bring us closer to both trees. And then we can delay a decision until things have settled on both sides of the pond, and see where the land lies. Assuming it's really clear, I'm fine with your proposal, although I don't see XFree86 suddenly changing their mind... I'm not talking about them changing their mind, just on how things are panning out. Alan. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sad, 2004-04-17 at 06:44, Ryan Underwood wrote: 3) Neither of these is ok, must go into non-free because binary-only firmware doesnt meet DFSG (no source) regardless of its license. Either whole driver must go into non-free, or a crippled driver is provided in main and a userspace loader in non-free to add the missing functionality. This is the answer I was given by lawyers. The analogy they use is an interesting but sensible one. If I add a chapter to a book it is clearly a derivative work, if I bundle the one work with a second pamphlet containing the chapter I wrote then it is not. 3 is a rather zealous approach, but seemed to be the approach that the do-ers on this issue are taking. I sympathize with the idealists on I don't think its zealots so much as appropriate legal practice. In the Linux case we now have a good hotplug firmware loading interface and drivers can practically ask for specific firmware. It also reduces the unswappable kernel size --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, 2004-04-17 at 07:44, Ryan Underwood wrote: On Sat, Apr 17, 2004 at 03:03:04AM +0200, Michel Dnzer wrote: It allows for the microcode to be updated without replacing the kernel, which is not a bad thing anyway. But changing the microcode would change the driver-chip interface anyway. So you'd have to update the driver too. Keeping the driver and the userspace loader in sync might be...erm.. painful. If a userspace approach to firmware loading is pursued, perhaps a better approach is like the modprobe approach. When the XFree86 driver for a piece of hardware initializes, it would do a kernel probe for the firmware for this device, corresponding to the particular version of the driver that is running. The kernel would call a firmware loading binary (like it calls /sbin/modprobe or whatever is in that /proc entry) telling it what driver is asking and what version of the driver. Based on that information, the userspace loader can decide which version of the microcode to load up. If that version is not available, exit with failure and the kernel should then return failure to the application, so it knows that the proper microcode that particular driver version was written against was unable to be found, and to disable features which would require a loaded microcode. I don't think such a complicated scheme is needed? Just encode the microcode version in the filename and try to load any supported version, from most to least preferred? I mostly agree with your other points. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] R200 t_vertex conversion
Ian Romanick wrote: This is what I have done so far to convert the R200 driver to use t_vertex. It is only a conversion for SW TCL, and it's not quite complete. I've managed to clean up all the crashes that I could find, but I've only tested with gears, geartrain, and tunnel. There are some known problems: - The textures in tunnel are not quite right. They're sort of zig-zaggy. - The colors of two of the gears in gears are swapped. The red gear is blue and the blue gear is red. The green gear is correct. I chopped out all of the _r200_render_stage stuff from r200_swtcl.c. It is unused (due to bad interactions with UT2k3), and was only confusing me. When this patch gets committed, that code can go back in, I think. There are two hacks that I had to do to get things working. Neither of these needed to be done by the i830 or savage drivers. First, I had to add a viewport matrix that remains an identity matrix. This is because the Radeon chips do the viewport transform in hardware. tnl_dd/t_dd_vbtmp.h had the ability to handle hardware like this, but t_vertex apparently does not. Second, I had to force TNL to always produce project coordinates. Again, the Radeon hardware can do the final projection in hardware almost all the time, but due to the way the i830 and savage drivers use use tnl-vb.NdcPtr (actually VB-NdcPtr) I couldn't see a way around this. I may just be missing something there. Ah, ok. I see the problem. Basically this has to do with the fact that choosing the hw vertex format has gone from being something (normally) done ahead of time, prior to actually running the tnl pipeline, to something done after that, and based on its results. The only problem is that by this time, the pipeline has run, and it's too late to decide whether or not to calculate projected coordinates. Oh well, it's not too hard to do that ahead of time. Keith --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Build problems on FreeBSD
I can't get a current version of the DRI cvs to build on FreeBSD any more: cd ./config/makedepend make -f Makefile.proto bootstrap Makefile.proto, line 30: Need an operator Makefile.proto, line 81: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/home/adamk/FreeBSD/xc/xc. This happens almost immediately. Any ideas? Adam --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 09:36:24AM +0100, Alan Cox wrote: This is the answer I was given by lawyers. The analogy they use is an interesting but sensible one. If I add a chapter to a book it is clearly a derivative work, if I bundle the one work with a second pamphlet containing the chapter I wrote then it is not. It seems digging up some case law on the matter would be better than using analogies. Firmware could already be considered to be the pamphlet that is bundled with the book (the driver) because the firmware is not part of the driver in terms of functionality; it happens to be bundled with the driver because that is the most convenient way to get it into the hardware. Execution of the driver code never reaches the firmware and could not because it is not encoded in the instruction set of the host that the driver is running on. Of course, if the legal advice you refer to was specifically aimed at the firmware scenario, where you have a blob of who-knows-what that does not execute on the host embedded into a driver binary, then I'm not one to argue with that. I don't think its zealots so much as appropriate legal practice. In the Linux case we now have a good hotplug firmware loading interface and drivers can practically ask for specific firmware. It also reduces the unswappable kernel size Sure. I won't argue with people that are making the existing systems more flexible. My beef is mainly that a lot of people are considering sourceless firmware to be outside the DFSG, which amounts to an inconvenience to users for a dubious political gain. But that is off-topic for dri-devel probably. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, Apr 17, 2004 at 03:33:16PM +0200, Michel Dänzer wrote: I don't think such a complicated scheme is needed? Just encode the microcode version in the filename and try to load any supported version, from most to least preferred? I think that's what I meant. Point being, have the kernel call out to a userspace loader on the driver's behalf, instead of the user running a loader like Nathaniel's in an init script or something. I was also reminding folks of the importance of versioning of the driver vs the firmware, because one of his comments seemed to imply that you could upgrade the microcode to a new version without changes to the driver. This is not always true because the command interface may change from revision to revision of the microcode. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2004-04-16 at 23:02, Nathanael Nerode wrote: Michel Dänzer wrote: On Thu, 2004-04-15 at 22:00, Nathanael Nerode wrote: This is a diff for drivers/char/drm to make r128 use userland-loadable firmware. Sigh, is this really necessary? :\ It allows for the microcode to be updated without replacing the kernel, which is not a bad thing anyway. I'm not sure it ever has changed or will change... we both know the background of this; IMHO it's an inconvenience for users for little or no gain of freedom. I know the firmware is not all that large but every page counts. Freeing it from the mod will reduce it's memory foot print. Though your right there is little or no gain of freedom. __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build problems on FreeBSD
Never mind Stupid mistake on my part. Adam On Sat, 17 Apr 2004, Adam K Kirchhoff wrote: I can't get a current version of the DRI cvs to build on FreeBSD any more: cd ./config/makedepend make -f Makefile.proto bootstrap Makefile.proto, line 30: Need an operator Makefile.proto, line 81: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/home/adamk/FreeBSD/xc/xc. This happens almost immediately. Any ideas? Adam --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sad, 2004-04-17 at 19:40, Ryan Underwood wrote: Of course, if the legal advice you refer to was specifically aimed at the firmware scenario, where you have a blob of who-knows-what that does not execute on the host embedded into a driver binary, then I'm not one to argue with that. It was specifically in response to the question about firmware, and whether it would be better if firmware was seperated. I don't know of any direct case law on embedding firmware and at what point it isn't mere aggregation --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Convert r128 driver in linux kernel 2.6 to use userland firmware loading
On Sat, 2004-04-17 at 20:46, Ryan Underwood wrote: On Sat, Apr 17, 2004 at 03:33:16PM +0200, Michel Dnzer wrote: I don't think such a complicated scheme is needed? Just encode the microcode version in the filename and try to load any supported version, from most to least preferred? I think that's what I meant. Point being, have the kernel call out to a userspace loader on the driver's behalf, instead of the user running a loader like Nathaniel's in an init script or something. My understanding is that the firmware loader interface he uses works similar to your description, via hotplug events. I was also reminding folks of the importance of versioning of the driver vs the firmware, because one of his comments seemed to imply that you could upgrade the microcode to a new version without changes to the driver. This is not always true because the command interface may change from revision to revision of the microcode. Indeed, the microcode should definitely be versioned. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Makefiles in the drm module
On Wed, 2004-04-14 at 16:19, Keith Whitwell wrote:
Michel Dnzer wrote:
Does anything speak against repo-moving Makefile.{bsd,linux} to
Makefile?
I can't think of any reason not to.
Turns out a simple repo-move doesn't work for Makefile.linux as it
contains some Makefile juggling hacks. The attached diff shows the
difference between Makefile.linux and the new Makefile which I'm going
to commit soon, unless someone objects.
Given this, I'm leaving Makefile.bsd to someone who can test it.
Also, should I try to fix up the snapshot scripts, or leave that to the
people dealing with the snapshots?
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
--- ../drm-apply/linux/Makefile.linux 2004-04-12 07:27:36.0 +0200
+++ linux/Makefile 2004-04-18 01:38:05.821198111 +0200
@@ -6,7 +6,7 @@
# platforms in a flexible way by David Dawes. It's not clear, however,
# that this approach is simpler than the old one.
#
-# The purpose of this Makefile.linux file is to handle setting up everything
+# The purpose of this Makefile is to handle setting up everything
# needed for an out-of-kernel source build. Makefile.kernel contains
# everything required for in-kernel source builds. It is included into
# this file, so none of that should be duplicated here.
@@ -18,17 +18,17 @@
# By default, the build is done against the running linux kernel source.
# To build against a different kernel source tree, set LINUXDIR:
#
-#make -f Makefile.linux LINUXDIR=/path/to/kernel/source
+#make LINUXDIR=/path/to/kernel/source
#
# To build only some modules, either set DRM_MODULES to the list of modules,
# or specify the modules as targets:
#
-#make -f Makefile.linux r128.o radeon.o
+#make r128.o radeon.o
#
# or:
#
-#make -f Makefile.linux DRM_MODULES=r128 radeon
+#make DRM_MODULES=r128 radeon
#
SHELL=/bin/sh
@@ -157,24 +157,10 @@ ifeq ($(CLEANCONFIG),y)
CLEANFILES += $(LINUXDIR)/.config .config $(LINUXDIR)/tmp_include_depends
endif
-# The Makefile renaming hack is required because the standard kernel build,
-# especially 2.5.52 and later, explicitly references the Makefile by the
-# name Makefile. For builds prior to 2.5.52, the name GNUmakefile could
-# have been used.
-
all: modules
modules: includes
- @if test -f Makefile cmp -s Makefile Makefile.linux; then : ; \
- else \
- if [ -e Makefile ]; then \
- (set -x; mv -f Makefile Makefile._xx_); fi; \
- (set -x; ln -s Makefile.linux Makefile); fi
make -C $(LINUXDIR) $(GETCONFIG) SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules
- @if cmp -s Makefile Makefile.linux; then \
- (set -x; rm -f Makefile); \
- if [ -e Makefile._xx_ ]; then \
- (set -x; mv -f Makefile._xx_ Makefile); fi; fi
ifeq ($(HEADERFROMBOOT),1)
@@ -241,7 +227,7 @@ clean cleandir:
rm -f $(CLEANFILES)
$(MODULE_LIST)::
- make -f Makefile.linux DRM_MODULES=$@ modules
+ make DRM_MODULES=$@ modules
# Build test utilities
[Dri-devel] Questions about current status of DRI
Hi guys, I've been busy for a while, but summer is approaching with the possibility of some spare time, so I have several questions about current status of DRI: 1. I could not find a link to the newer ViewCVS interface on the website - does it exist ? 2. Is anyone working on accelerated 3d for newer Radeons (R300, etc) ? 3. Can anyone tell me what changes are required in order to enable idle DRI for R300 and above ? (I.e. DRM module starts up, 2d commands go through DRM , but Mesa driver does software rendering). This is a question about DRI architecture, not hardware. I.e. if part of this functionality involves hardware that's changed in R300 it also falls in idle category. 4. Are there any examples of user-space applications accessing DRM, the same way Mesa driver does, but (hopefully) simpler ? I might have some success in figuring out CP sequences and present the result as a user-space library, but I doubt I will have time to dig inside Mesa. 5. I remember there was someone working to merge current GATOS code into DRI - did these changes made it into DRI CVS ? thank you very much ! Vladimir Dergachev --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Finally looking at the DRI SMP issues - Yahooo! (fps 30-31 fps up)!
On Fri, Apr 16, 2004 at 11:35:14AM -0700, Ian Romanick wrote: The r200 is the clear bottleneck, now What we need next is the TMU3 patch...;-) I'm still trying to work through the t_vertex conversion. That should help some too. Of course, Quake3 only uses 2 TMUs anyway. I'll post what I have for the t_vertex conversion (working or not!) later today. Maybe someone will be able to see what I'm doing wrong... QuakeForge uses 3 tmus for map rendering (wall textures + lightmap + fullbrights) if available. Bill -- Leave others their otherness. -- Aratak --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Questions about current status of DRI
On Sun, 2004-04-18 at 03:19, Vladimir Dergachev wrote: 1. I could not find a link to the newer ViewCVS interface on the website - does it exist ? http://dri.freedesktop.org/cgi-bin/cvsweb/dri/ 2. Is anyone working on accelerated 3d for newer Radeons (R300, etc) ? Not that I know of. 3. Can anyone tell me what changes are required in order to enable idle DRI for R300 and above ? (I.e. DRM module starts up, 2d commands go through DRM , but Mesa driver does software rendering). The infamous CP microcode is needed. AFAIK, Benjamin Herrenschmidt got it from ATI. 4. Are there any examples of user-space applications accessing DRM, the same way Mesa driver does, but (hopefully) simpler ? I don't know of any. I might have some success in figuring out CP sequences and present the result as a user-space library, but I doubt I will have time to dig inside Mesa. We have the docs, no need to guess... note that unprivileged user space processes can't emit CP commands directly but can only use higher level ioctls geared towards the 3D driver. May I ask what goal you are trying to achieve? 5. I remember there was someone working to merge current GATOS code into DRI - did these changes made it into DRI CVS ? The GATOS DRM doesn't have anything that needs merging, does it? For the other code, the DRI tree isn't the right target IMHO. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Questions about current status of DRI
On Saturday 17 April 2004 20:19, Vladimir Dergachev wrote: 4. Are there any examples of user-space applications accessing DRM, the same way Mesa driver does, but (hopefully) simpler ? I might have some success in figuring out CP sequences and present the result as a user-space library, but I doubt I will have time to dig inside Mesa. tests/drmstat.c in the drm/ module perhaps? (It strikes me that those won't build at all right now since they've been moved...) - ajax --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI/Xfree86 Merge
On Sat, 2004-04-17 at 07:54, Alan Hourihane wrote: On Sat, Apr 17, 2004 at 01:18:49AM +0200, Michel Dänzer wrote: On Sat, 2004-04-17 at 00:00, Alan Hourihane wrote: I could merge in XFree86 4.3.99.902 which is before the license change Are you sure? AFAIK David applied the new license (or at least a similarly controversial one) to some files before it was publicly announced. Yes, I'm positive that 4.3.99.902 is unencumbered. I'm pretty sure the autoconfig work, under the X-Oz license (nearly identical to the problematic one), was in at that point. -- Donnie Berkholz Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] Questions about current status of DRI
On Sun, 18 Apr 2004, Michel [ISO-8859-1] Dnzer wrote: On Sun, 2004-04-18 at 03:19, Vladimir Dergachev wrote: 1. I could not find a link to the newer ViewCVS interface on the website - does it exist ? http://dri.freedesktop.org/cgi-bin/cvsweb/dri/ Thank you ! 3. Can anyone tell me what changes are required in order to enable idle DRI for R300 and above ? (I.e. DRM module starts up, 2d commands go through DRM , but Mesa driver does software rendering). The infamous CP microcode is needed. AFAIK, Benjamin Herrenschmidt got it from ATI. I might have it too, though one can never tell whether it works without experiment (i.e. it might just be a copy of R200 microcode). I might have some success in figuring out CP sequences and present the result as a user-space library, but I doubt I will have time to dig inside Mesa. We have the docs, no need to guess... note that unprivileged user space processes can't emit CP commands directly but can only use higher level ioctls geared towards the 3D driver. May I ask what goal you are trying to achieve? Well, I wanted to make an example app that exercises as many 3d related capability as possible. With the hope that once this is published people with more knowledge of Mesa internals would be tempted to make a real driver. Also, it is possible to access CP fifo via MMIO registers - if I remember this right. That was going to be my second choice, with the preference of connecting to DRM module directly. 5. I remember there was someone working to merge current GATOS code into DRI - did these changes made it into DRI CVS ? The GATOS DRM doesn't have anything that needs merging, does it? For the other code, the DRI tree isn't the right target IMHO. No, I meant the code that makes TV-in work. I was incredibly busy this year and did not have time to start porting to 4.4.0 codebase. best Vladimir Dergachev -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Questions about current status of DRI
The infamous CP microcode is needed. AFAIK, Benjamin Herrenschmidt got it from ATI. the BeOS driver has some r300 microcode in its sources... http://www.bebits.com/appver/2938 download the r5 source at look at CPMicroCode.h in the file... no idea what it is of course it might be 2d only or something wierd.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Questions about current status of DRI
On Sun, 18 Apr 2004, Dave Airlie wrote: The infamous CP microcode is needed. AFAIK, Benjamin Herrenschmidt got it from ATI. the BeOS driver has some r300 microcode in its sources... http://www.bebits.com/appver/2938 download the r5 source at look at CPMicroCode.h in the file... no idea what it is of course it might be 2d only or something wierd.. Yep, it matches the code I see in the DDK. So it appears that the only thing left to get 3d working is to find/verify packets for CP engine. best Vladimir Dergachev Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
