Testcase es2_info from mesa-progs. Backtrace #0 0x00007f57f76c773c in create_drm_screen (name=<value optimized out>, fd=7) at egl.c:322 #1 0x00007f57f76cfad4 in x11_create_dri2_display (dpy=0x1d2f010, event_handler=0x7f57f7902390, user_data=0x1d3b040) at x11/native_dri2.c:714 #2 0x00007f57f76c91c6 in native_create_display (dpy=0x1d2f010, event_handler=0x7f57f7902390, user_data=0x1d3b040) at x11/native_x11.c:42 #3 0x00007f57f76c81e0 in egl_g3d_initialize (drv=<value optimized out>, dpy=0x1d3b040, major=<value optimized out>, minor=<value optimized out>) at common/egl_g3d.c:498 #4 0x00007f57f8e777f1 in _eglMatchDriver (dpy=<value optimized out>, use_probe=<value optimized out>) at egldriver.c:580 #5 0x00007f57f8e7186a in eglInitialize (dpy=0x1d3b040, major=0x7fff1f24036c, minor=0x7fff1f240368) at eglapi.c:294 #6 0x00000000004013d2 in main (argc=1, argv=0x7fff1f240488) at es2_info.c:259 317 318 static struct pipe_screen * 319 create_drm_screen(const char *name, int fd) 320 { 321 struct pipe_module *pmod = get_pipe_module(name); 322 return (pmod && pmod->drmdd->create_screen) ? 323 pmod->drmdd->create_screen(fd) : NULL; 324 } 325 326 static struct pipe_screen * initial name is r300, the name should be radeon. it's a bit unknown why it returns (gdb) print *pmod $2 = {initialized = 1 '\001', name = 0x0, lib = 0x0, drmdd = 0x0, swrast_create_screen = 0} something this wrong.
load_pipe_module seems the culprit: (gdb) print pmod->drmdd->driver_name $5 = 0x7fca7adaf6e0 "radeon" (gdb) print pmod->name $6 = 0x25b4140 "r300" 158 _eglSearchPathForEach(dlopen_pipe_module_cb, (void *) pmod); 159 if (pmod->lib) { 160 pmod->drmdd = (const struct drm_driver_descriptor *) 161 util_dl_get_proc_address(pmod->lib, "driver_descriptor"); 162 if (pmod->drmdd) { 163 if (pmod->drmdd->driver_name) { 164 /* driver name mismatch */ 165 if (strcmp(pmod->drmdd->driver_name, pmod->name) != 0) 166 pmod->drmdd = NULL; 167 }
Hmm. Could you enlighten me which DRI driver would libGL load on your system? r300_dri or radeon_dri? It seems should be r300_dri from a quick look at xorg-video-ati. But I am then curious why src/gallium/targets/dri-radeong builds radeon_dri instead r300_dri. I must miss something...
(In reply to comment #2) > Hmm. Could you enlighten me which DRI driver would libGL load on your system? > r300_dri or radeon_dri? It seems should be r300_dri from a quick look at > xorg-video-ati. But I am then curious why src/gallium/targets/dri-radeong > builds radeon_dri instead r300_dri. I must miss something... There are two 3D drivers for r300-r500 radeon hardware, the classic mesa r300 driver and the gallium r300 driver. At the moment the classic driver is the default, but that's likely to change soon.
hm what has this directly to do with DRI drivers? That code is executed after loading a pipe module, so lib/egl/pipe_radeon.so and not the dri stuff.. This error looks to me as if a symlink created from lib/egl/pipe_r300.so -> lib/egl/pipe_radeon.so. (I did the same think as i experienced propblems loading r300g pipe with egl/x11) my patches i send yesterday should have solved that: http://lists.freedesktop.org/archives/mesa-dev/2010-August/002385.html
(In reply to comment #4) > hm what has this directly to do with DRI drivers? Just tried to clarify the naming of the DRI drivers for AMD/ATI hardwares, which EGL follows. > That code is executed after loading a pipe module, so lib/egl/pipe_radeon.so > and not the dri stuff.. > This error looks to me as if a symlink created from lib/egl/pipe_r300.so -> > lib/egl/pipe_radeon.so. > (I did the same think as i experienced propblems loading r300g pipe with > egl/x11) > my patches i send yesterday should have solved that: > http://lists.freedesktop.org/archives/mesa-dev/2010-August/002385.html Yes, patch 1 & 3 look good to me http://lists.freedesktop.org/archives/mesa-dev/2010-August/002418.html I'd like to change KMS backend to ask for r300 or r600 when the DRM name is radeon instead of patch 2. Also, the name check at targets/egl/egl.c:165 should be removed. I don't have any radeon card to verify. How does it sound to you?
(In reply to comment #3) > (In reply to comment #2) > > Hmm. Could you enlighten me which DRI driver would libGL load on your system? > > r300_dri or radeon_dri? It seems should be r300_dri from a quick look at > > xorg-video-ati. But I am then curious why src/gallium/targets/dri-radeong > > builds radeon_dri instead r300_dri. I must miss something... > > There are two 3D drivers for r300-r500 radeon hardware, the classic mesa r300 > driver and the gallium r300 driver. At the moment the classic driver is the > default, but that's likely to change soon. I see that r300g has radeong_dri.so as its module name. Is it chosen automatically, or the users are supposed to $ ln -sf radeong_dri.so r300_dri.so ? I mean, before r300g becomes the default. BTW, targets/dri-radeong/SConscript disagrees with Makefile on the module name. It seems like a typo.
We plan to rename all occurences of radeong_dri and radeon_dri to r300_dri.
(In reply to comment #5) > (In reply to comment #4) > > hm what has this directly to do with DRI drivers? > Just tried to clarify the naming of the DRI drivers for AMD/ATI hardwares, > which EGL follows. > > That code is executed after loading a pipe module, so lib/egl/pipe_radeon.so > > and not the dri stuff.. > > This error looks to me as if a symlink created from lib/egl/pipe_r300.so -> > > lib/egl/pipe_radeon.so. > > (I did the same think as i experienced propblems loading r300g pipe with > > egl/x11) > > my patches i send yesterday should have solved that: > > http://lists.freedesktop.org/archives/mesa-dev/2010-August/002385.html > Yes, patch 1 & 3 look good to me > > http://lists.freedesktop.org/archives/mesa-dev/2010-August/002418.html > > I'd like to change KMS backend to ask for r300 or r600 when the DRM name is > radeon instead of patch 2. Also, the name check at targets/egl/egl.c:165 > should be removed. I don't have any radeon card to verify. How does it sound > to you? I've pushed patch 1 & 3. The selection of r300/r600 is done in KMS backend, as can be seen in 1288d5c39234e7c54ae2fbb81dd788c98c62a7b3. Please test if it fixes this bug.
Works for me =)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.