View previous topic :: View next topic |
Author |
Message |
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Mon May 17, 2004 12:45 pm Post subject: xorg-x11-6.8.2-r1 stable; link to xorg.conf for ffb/afb |
|
|
Current stable version of X for sparc is xorg-x11-6.8.2-r1. It offers the following:
- The directory /usr/X11R6/ is gone. All that remains is a symlink for compatibility reasons.
- Several new USE flags are available to help fine-tune what pieces of xorg are actually installed.
Please see the ChangeLog and the /usr/portage/profiles/use*desc files.
- It is now possible to build a true hardened xorg. Just USE='dlloader hardened ...' (assuming support in gcc). (In fact, dlloader is now default.)
- Further, if you have Creator (ffb) or Elite (afb) graphics, you must build with USE='dlloader' and add:
Code: |
Load "cfb"
Load "cfb32"
|
to your xorg.conf file.
For sample (working) xorg.conf files (kernels 2.4.x, 2.6.x) with Creator (ffb) or Elite (afb) graphics, please see http://dev.gentoo.org/~fmccor/docs/xorg/xorg.conf/xorg.conf.html
before posting a query about xorg.conf problems.
Also as of 08.xii.04, you must use the (deprecated) 'keyboard' driver if your kernel is 2.4.xx. I do not know when this will be fixed.
The reason for using 6.8.2-r1 and removing ebuild for 6.8.2 is a tiny (two line) security patch for XPM.
If you have an Elite (afb) frame buffer and want to know how to get the microcode to support it, please see the third paragraph at http://dev.gentoo.org/~fmccor/.
As noted above, 'dlloader' is the default, so you will need "USE='-dlloader'" if you do not want it. This is untested and not recommended, however, and not known to work one way or the other.
Feedback requested;
Last edited by Ferris on Fri Jun 10, 2005 11:53 am; edited 11 times in total |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Sat May 22, 2004 11:42 am Post subject: |
|
|
At the request of the herd responsible for xfree and xorg, this switch to xorg is now scheduled for Wednesday, the 26th of May.
This is to allow time for some improvements to the xorg ebuild so that the change from xfree
to xorg will be as seamless as possible (to paraphrase spyderous). |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Sat May 29, 2004 3:53 pm Post subject: |
|
|
The changes to xorg-x11 and friends seem to be in place. So they should lose their '~' tags on the 29th of May, assuming a good build first. |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Sat May 29, 2004 7:18 pm Post subject: |
|
|
x11-base/xorg-x11-6.7.0 has been marked stable for sparc.
This is not a mandatory upgrade from xfree, but it is recommended. Please consult the previous entries in this thread
for details. |
|
Back to top |
|
|
sfaulconer n00b
Joined: 06 Aug 2003 Posts: 48
|
Posted: Tue Jun 08, 2004 5:03 pm Post subject: DRM Capable? |
|
|
Anyone know if Creator3D cards are DRM capable, or do they suffer the poor libGL performance as well?
Thanks. _________________ SMF |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Mon Jun 14, 2004 11:07 am Post subject: |
|
|
Creator performance with xorg-x11 is identical to it's performance with xfree-4.3.0-r5, but you don't have to install the libGL patch by hand.
With Creator, the sunffb+kernel combination does DRM, but it goes indirect through X11 (the ffbdri module to do Mesa<--->ffb has never been finished, any version of X).
The Elite card seemingly is not DRM capable, ans with xorg, there are introduced as yet undetermined inefficiencies. One way or the other, these will be removed. |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Mon Jun 14, 2004 11:12 am Post subject: |
|
|
"Real soon now," i.e., today, 14 June 2004, xorg-x11-6.7.0-r1 will be marked stable for sparc.
This is only a security update as noted in bug #53226; only xdm is affected. |
|
Back to top |
|
|
je_fro Retired Dev
Joined: 14 Dec 2002 Posts: 236 Location: Republic of Texas
|
Posted: Tue Jun 22, 2004 10:58 am Post subject: Mesa worked like a charm.... |
|
|
I compiled Mesa-6.0.1, using the linux-sparc-ultra flag, copied libGL.so to the xorg directory noted above and fixed the symlinks. I'm running an Elite3D in a 2x300 U60. Now I get:
bash-2.05b$ glxgears
492 frames in 5.0 seconds = 98.400 FPS
493 frames in 5.0 seconds = 98.600 FPS
and my glxinfo is:
name of display: :0.0
display: :0 screen: 0
direct rendering: No
server glx vendor string: Brian Paul
server glx version string: 1.4 Mesa 6.0.1
server glx extensions:
GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer
client glx vendor string: Brian Paul
client glx version string: 1.4 Mesa 6.0.1
client glx extensions:
GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer
GLX extensions:
GLX_MESA_copy_sub_buffer, GLX_MESA_pixmap_colormap,
GLX_MESA_release_buffers, GLX_ARB_get_proc_address, GLX_EXT_visual_info,
GLX_EXT_visual_rating, GLX_SGI_video_sync, GLX_SGIX_fbconfig,
GLX_SGIX_pbuffer
OpenGL vendor string: Brian Paul
OpenGL renderer string: Mesa X11
OpenGL version string: 1.5 Mesa 6.0.1
OpenGL extensions:
GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging,
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query,
GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow,
GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp,
GL_ARB_texture_compression, GL_ARB_texture_cube_map,
GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3,
GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two,
GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object,
GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra,
GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture,
GL_EXT_depth_bounds_test, GL_EXT_draw_range_elements, GL_EXT_fog_coord,
GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels,
GL_EXT_paletted_texture, GL_EXT_point_parameters, GL_EXT_polygon_offset,
GL_EXT_rescale_normal, GL_EXT_secondary_color,
GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,
GL_EXT_shared_texture_palette, GL_EXT_stencil_two_side,
GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D,
GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp,
GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array,
GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3,
GL_ATI_texture_mirror_once, GL_HP_occlusion_test,
GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip,
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
GL_MESA_pack_invert, GL_MESA_program_debug, GL_MESA_resize_buffers,
GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square,
GL_NV_fragment_program, GL_NV_light_max_exponent, GL_NV_point_sprite,
GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program,
GL_NV_vertex_program1_1, GL_SGI_color_matrix, GL_SGI_color_table,
GL_SGI_texture_color_table, GL_SGIS_generate_mipmap,
GL_SGIS_pixel_texture, GL_SGIS_texture_border_clamp,
GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture,
GL_SGIX_pixel_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient,
GL_SUN_multi_draw_arrays
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x27 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 0 0 0 None
0x28 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None
0x29 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None
0x2a 24 tc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None
0x2b 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None
0x2c 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None
0x2d 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None
0x2e 24 dc 0 24 0 r y . 8 8 8 0 0 24 8 16 16 16 16 0 0 None
0x2f 8 pc 0 8 0 r y . 2 3 3 0 0 24 8 16 16 16 16 0 0 None
0x30 8 gs 0 8 0 r y . 2 3 3 0 0 24 8 16 16 16 16 0 0 None
0x31 8 sg 0 8 0 r y . 2 3 3 0 0 24 8 16 16 16 16 0 0 None
In short, YAY!!!! _________________ Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect.
--Linus Torvalds
My site with some gentoo config files:
http://je-fro.net/page.html |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Fri Jun 25, 2004 6:50 pm Post subject: |
|
|
That's exactly what you should see. As far as I can tell, that is probably about the best as Elite can do.
Right now, I am trying to figure out the cleanest way to get this performance either once again from X11 or from a resurrected mesa3d gentoo package. Right now, I am leaning toward the mesa3d approach because:
- It is more flexible;
- It requires fewest changes to existing packages (really, only opengl-update & a new media-libs/mesa-6.x since the one for
media-libs/mesa is effectively dead: it is a current ebuild, but it is hard masked and uses a very old
version of mesa);
- It gives you all of current mesa if you want it;
- It is really easy.
But of course, if we do that, then anyone wanting the best performance possible from afb+GL needs to make two installs.
Thoughts & comments welcome.
Thanks for the feedback.
Regards, |
|
Back to top |
|
|
GenTimJS Guru
Joined: 03 May 2003 Posts: 406 Location: NH, USA
|
Posted: Mon Aug 02, 2004 5:32 pm Post subject: |
|
|
I think for those of us on sparc, we are happy (very happy) when it can be made to "just work", as much as it "just works" on x86...
nothing would make me happier than actually getting ANY acceleration out of my creator3d, without the mess of manually splicing in binary code etc etc... if I have to take a few FPS performance hit for it to work easily, so be it ... if I wanted blazing 3d speed, I'd be using an x86 gaming box. _________________ -Tim Smith |
|
Back to top |
|
|
Drunkula Apprentice
Joined: 28 Jul 2003 Posts: 257 Location: Denton, TX - USA
|
Posted: Fri Aug 06, 2004 5:53 pm Post subject: |
|
|
Just got my U2 Enterprise with Creator 3D running. Had some difficulty with the keyboard (type 5). The kb section from my old xfree config didn't help. I had to change the Xkbrules (I think) from "xorg" to "sun". Come to think of it, that was after I emerged xorg-x11 so my previous config may have been changed.
After that it seems fine. But then again that box spends most of it's time outside of X! |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Tue Oct 05, 2004 1:40 pm Post subject: |
|
|
With xorg-x11-6.8.0-r1, the following should be noted:
- If you are using kernel 2.6.x, the keyboard driver is now 'kbd', and the rules are 'xorg';
- Performance for Elite3d (afb) and libGL is no longer degraded;
- libGL now can load the DRI module ffb_dri for Creator graphics. However, there is a reasonable chance
that it will not work properly: It is a work in progress. And, if you are using kernel-2.6.7,
this does not apply (kernel problem).
Correct behavior is very much application specific. If your application seems to fail,
run it with the environment variable LIBGL_ALWAYS_INDIRECT defined (e.g.,
LIBGL_ALWAYS_INDIRECT='yes', although 'no' will have the same effect --- it just has to be defined).
- A couple modules you might be loading (e.g., speedo) are no longer supplied. /var/log/Xorg.0.log will tell you; just remove them from xorg.conf.
- If you use the bitmap fonts, you probably want to build with USE='bitmap-fonts'. (Will do no harm in any case.)
If you are running any sort of Creator (ffb, ffb2, ffb2+), try libGL (DRI), and have problems,
we would appreciate a description of the failure (commenting here is fine).
{kernel-2.6.7 -- not you. We know dri for ffb does not get set up for 2.6.7.}
Regards, |
|
Back to top |
|
|
labrador Guru
Joined: 04 Oct 2003 Posts: 316
|
Posted: Fri Oct 08, 2004 2:38 pm Post subject: not clear on whether dri should work with 2.6 kernel and afb |
|
|
From your status updates I'm not sure what
I should expect to see for direct rendering status
from Xorg with 2.6 kernel and elite 3D m3.
I'm getting the afbinit to work now, and X runs OK.
glxinfo - Direct Rendering shows No, and glxgears runs about
96 FPS with software rendering. DRI was working
OK from a 2.4 kernel with Xorg prior to this.
I'm not using stuff from mesa sources, only gentoo. |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Fri Oct 08, 2004 4:06 pm Post subject: |
|
|
Sorry for the confusion.
No combination of xorg+Elite3D (-m3, -m6)=afb provides DRI. I do not know if the card is capable of it or not,
but neither the kernel driver nor the xorg driver (sunffb) supports it.
So, with xorg-x11-6.8.0, using libGL, you will have indirect rendering for Mesa (Direcr Rendering = NO),
but the performance is the best Mesa is capable of. (With 6.7.0, xorg+libGL +afb performance was severely degraded.)
My comments were directed to people using ffb, ffb2, ffb2+ (Creator in various forms) graphics. With 6.8.0 and kernel < 2.6.7,
direct rendering is available. But it is still fairly preliminary and incomplete.
Hope this helps, |
|
Back to top |
|
|
seto n00b
Joined: 09 Apr 2003 Posts: 25 Location: Switzerland
|
Posted: Wed Oct 13, 2004 9:16 pm Post subject: |
|
|
what is with kernel 2.6.7, actually?
something like the stuff below?
if that's the case, i can happily try out 2.6.9-rc2+ now
from ChangeLog-2.6.9-rc2:
<davem@nuts.davemloft.net>
[SPARC64]: Fix copyarea bug and set default flags in ffb driver.
- copyarea checking of src/dst y being equal was buggy.
- set optimal FBINFO flags for this device.
Signed-off-by: David S. Miller <davem@redhat.com>
<davem@nuts.davemloft.net>
[SPARC64]: Speed up ffb font rendering.
Render left to right instead of top to bottom.
This shaved a whole second off the:
time cat MAINTAINERS
benchmark.
Signed-off-by: David S. Miller <davem@redhat.com>
<airlied@starflyer.(none)>
drm: Sparc64 ffb compile fixes
Fixup ffb driver and interfaces it uses, also avoid bus_to_virt
on sparc, I'll look into using the proper APIs for the DRM soon.
Signed-off-by: Dave Airlie <airlied@linux.ie> |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Wed Oct 13, 2004 10:40 pm Post subject: |
|
|
I am not sure what the problems with kernel-2.6.7 are, except that there are several reasons
not to use it. ffb DRM (lack of) support is one of them.
I think that most kernel-2.6.xx kernels have problems, especially if you are running a multiprocessor system.
I suggest you ask around in the freenode #gentoo-sparc IRC channel for more specific
information.
Sorry I can't be more definite (or more positive). Any testing and feedback you can provide are helpful and welcome,
but I cannot guarantee you good results.
Regards,
Ferris |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Tue Dec 14, 2004 9:23 pm Post subject: |
|
|
As of 14 December 2004, xorg-x11-6.8.0-r4 has moved to ~sparc, but it is still masked.
If you wish to try it, before unmasking it, please review the (revised) head post in this thread,
then read the xorg-x11 ChangeLog. Also, you will want to examine the USE flags recognized by this version or xorg:
the list has been expanded to provide greater control over just which parts of
xorg are installed, which loader is used, and so on.
Comments and experiences welcome. |
|
Back to top |
|
|
Auka Tux's lil' helper
Joined: 01 Jul 2002 Posts: 110 Location: Germany
|
Posted: Sun Dec 26, 2004 7:15 pm Post subject: |
|
|
Ferris wrote: | As of 14 December 2004, xorg-x11-6.8.0-r4 has moved to ~sparc, but it is still masked. [...]
Comments and experiences welcome. |
Just upgraded my U5 to xorg-x11-6.8.0-r4 hardened (mach 64, dlloader) - worked fine out of the box! (quit in contrary to my hardened x86 ).
Great work!
PS: Anyone already got any experiences with the PGX32? Will probably give it a try during the next few days... |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Sun Dec 26, 2004 7:30 pm Post subject: |
|
|
Thanks for the positive feedback; that's always welcome.
xorg-x11-6.8.0-r4 has been unmasked since about 23.xii.04. Preliminary results suggest the following:
- If you use sunffb (Creator or Elite video), you will probably have to USE='dlloader ...' (experience suggests 'probably' == 'must');
- And if you use dlloader with sunffb, you must explicitly load these
modules:
Code: |
Load "cfb"
Load "cfb32"
|
Regards, |
|
Back to top |
|
|
Ferris Retired Dev
Joined: 13 Jan 2003 Posts: 426 Location: N. Virginia (USA)
|
Posted: Wed Jan 19, 2005 1:22 pm Post subject: |
|
|
All rebuilds are complete, and xorg-x11-6.8.0-r4 is moving to stable for sparc on 20 Jan. 2005.
Also, opengl-update-2.0_pre4-r1 will be marked stable because -r4 requires it if you USE=opengl.
At the same time, dlloader will become a default USE flag in all sparc profiles in portage/default-profiles/sparc.
Regards, |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|