ports/graphics/dri + WITHOUT_NOUVEAU=YES: strange problem

Oliver Fromme olli at lurza.secnetix.de
Tue Sep 14 13:13:25 UTC 2010


Hi,

In order to get the latest DRI version with hardware 3D
support for my ATI Radeon HD 4250, I recompiled the dri
port with WITHOUT_NOUVEAU=YES.  It breaks thusly:

  |  radeon_screen.c: In function 'radeonCreateScreen':
  |  radeon_screen.c:1025: error: 'R600_SCRATCH_REG_OFFSET' undeclared (first use in this function)

The respective part of the source file is this:

  |  if (screen->chip_family < CHIP_FAMILY_R600)
  |      screen->scratch = (__volatile__ uint32_t *)
  |          ((GLubyte *)screen->status.map + RADEON_SCRATCH_REG_OFFSET);
  |  else
  |      screen->scratch = (__volatile__ uint32_t *)
  |          ((GLubyte *)screen->status.map + R600_SCRATCH_REG_OFFSET);

Now, I don't have the slightest idea where those constants
are supposed to come from.  Neither R600_SCRATCH_REG_OFFSET
nor RADEON_SCRATCH_REG_OFFSET are defined anywhere in the
dri source tree, nor in /usr/include.  They are, however,
both defined in src/sys/dev/drm/radeon_drm.h:

  |  #define RADEON_SCRATCH_REG_OFFSET       32
  |  #define R600_SCRATCH_REG_OFFSET         256

Then I made the following patch to the dri source:

--- src/mesa/drivers/dri/radeon/radeon_screen.c.orig    2009-12-22 03:31:19.000000000 +0100
+++ src/mesa/drivers/dri/radeon/radeon_screen.c 2010-09-09 10:36:55.000000000 +0200
@@ -76,6 +76,10 @@
  */
 #include "xmlpool.h"
+#ifndef R600_SCRATCH_REG_OFFSET
+#define R600_SCRATCH_REG_OFFSET        256
+#endif
+
 #define DRI_CONF_COMMAND_BUFFER_SIZE(def,min,max) \
 DRI_CONF_OPT_BEGIN_V(command_buffer_size,int,def, # min ":" # max ) \
 	DRI_CONF_DESC(en,"Size of command buffer (in KB)") \

With that patch, the port compiles and works (after adding
the PCI ID of my ATI Radeon HD 4250, but that's a different
story).  I still don't know where RADEON_SCRATCH_REG_OFFSET
does come from.  It's not defined in any included file, as
far as i can see.

Does someone have an explanation for this?
Or maybe even provide a clean fix instead of that quick-hack?

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"What is this talk of 'release'?  We do not make software 'releases'.
Our software 'escapes', leaving a bloody trail of designers and quality
assurance people in its wake."


More information about the freebsd-x11 mailing list