[sisyphus] fglrx update

[sisyphus] fglrx update

[Ivan Adzhubey]

Доброго времени суток!

13 ноября вышел ATI Catalist 8.11 с поддержкой X.org/7.4. Поскольку в Сизифе 
уже давно 7.4, хорошо бы обновить fglrx_glx и ядерные модули.

--Иван

Re: [sisyphus] fglrx update

[Rusetsky Dmitry]

+1
Да очень хотелось-бы.
Ivan Adzhubey пишет:
> Доброго времени суток!
>
> 13 ноября вышел ATI Catalist 8.11 с поддержкой X.org/7.4. Поскольку в Сизифе 
> уже давно 7.4, хорошо бы обновить fglrx_glx и ядерные модули.
>
> --Иван
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sisyphus


-- 
С уважением,
Русецкий Дмитрий.

Re: [sisyphus] fglrx update

[Konstantin A. Lepikhov]

Hi Ivan!

Tuesday 02, at 09:36:48 PM you wrote:

> Доброго времени суток!
> 
> 13 ноября вышел ATI Catalist 8.11 с поддержкой X.org/7.4. Поскольку в Сизифе 
> уже давно 7.4, хорошо бы обновить fglrx_glx и ядерные модули.
> 
> --Иван
http://lakostis.livejournal.com/10234.html - превед мантейнеру xorg!

-- 
WBR et al.

Re: [sisyphus] fglrx update

[Ivan Adzhubey]

On Wednesday 03 December 2008 05:56:50 am Konstantin A. Lepikhov wrote:
> Hi Ivan!
>
> Tuesday 02, at 09:36:48 PM you wrote:
> > Доброго времени суток!
> >
> > 13 ноября вышел ATI Catalist 8.11 с поддержкой X.org/7.4. Поскольку в
> > Сизифе уже давно 7.4, хорошо бы обновить fglrx_glx и ядерные модули.
> >
> > --Иван
>
> http://lakostis.livejournal.com/10234.html - превед мантейнеру xorg!

А всем коллективом на поруки взять? Проблема давно назрела...

--Иван

Re: [sisyphus] fglrx update

[Afanasov Dmitry]

03.12.08, Ivan Adzhubey<iadzhubey@rics.bwh.harvard.edu> написал(а):
> On Wednesday 03 December 2008 05:56:50 am Konstantin A. Lepikhov wrote:
>  > Hi Ivan!
>  >
>  > Tuesday 02, at 09:36:48 PM you wrote:
>  > > Доброго времени суток!
>  > >
>  > > 13 ноября вышел ATI Catalist 8.11 с поддержкой X.org/7.4. Поскольку в
>  > > Сизифе уже давно 7.4, хорошо бы обновить fglrx_glx и ядерные модули.
>  > >
>  > > --Иван
>  >
>  > http://lakostis.livejournal.com/10234.html - превед мантейнеру xorg!
>
>
> А всем коллективом на поруки взять? Проблема давно назрела...
когда-то речь про xorg-compat шла...
-- 
С уважением
Афанасов Дмитрий

Re: [sisyphus] fglrx update

[Konstantin A. Lepikhov]

Hi Afanasov!

Wednesday 03, at 06:46:37 PM you wrote:

> 03.12.08, Ivan Adzhubey<iadzhubey@rics.bwh.harvard.edu> написал(а):
> > On Wednesday 03 December 2008 05:56:50 am Konstantin A. Lepikhov wrote:
> >  > Hi Ivan!
> >  >
> >  > Tuesday 02, at 09:36:48 PM you wrote:
> >  > > Доброго времени суток!
> >  > >
> >  > > 13 ноября вышел ATI Catalist 8.11 с поддержкой X.org/7.4. Поскольку в
> >  > > Сизифе уже давно 7.4, хорошо бы обновить fglrx_glx и ядерные модули.
> >  > >
> >  > > --Иван
> >  >
> >  > http://lakostis.livejournal.com/10234.html - превед мантейнеру xorg!
> >
> >
> > А всем коллективом на поруки взять? Проблема давно назрела...
> когда-то речь про xorg-compat шла...
Проще libdrm откатить.

-- 
WBR et al.

Re: [sisyphus] fglrx update

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 5117 bytes --]

On Wednesday 03 December 2008 19:16:32 Konstantin A. Lepikhov wrote:
> > >  > http://lakostis.livejournal.com/10234.html - превед мантейнеру xorg!
> > >
> > > А всем коллективом на поруки взять? Проблема давно назрела...
> >
> > когда-то речь про xorg-compat шла...
>
> Проще libdrm откатить.

чего конкретно ему не хватает в 2.4.1?
	common sonames:
libdrm.so.2	/usr/lib/libdrm.so.2.4.0	/usr/lib/libdrm.so.2.4.0
libdrm_intel.so.1	/usr/lib/libdrm_intel.so.1.0.0	/usr/lib/libdrm_intel.so.1.0.0

libdrm.so.2 definitions unchanged

--- libdrm-2.4.0-alt4/libdrm_intel.so.1	2008-12-04 11:27:13 +0300
+++ libdrm-2.4.1-alt2/libdrm_intel.so.1	2008-11-22 21:06:19 +0300
@@ -2,20 +2,31 @@
 _init	T
-dri_bo_alloc	T
-dri_bo_emit_reloc	T
-dri_bo_exec	T
-dri_bo_flink	T
-dri_bo_get_subdata	T
-dri_bo_get_tiling	T
-dri_bo_map	T
-dri_bo_pin	T
-dri_bo_reference	T
-dri_bo_set_tiling	T
-dri_bo_subdata	T
-dri_bo_unmap	T
-dri_bo_unpin	T
-dri_bo_unreference	T
-dri_bo_wait_rendering	T
-dri_bufmgr_check_aperture_space	T
-dri_bufmgr_destroy	T
-dri_bufmgr_set_debug	T
+drm_intel_bo_alloc	T
+drm_intel_bo_emit_reloc	T
+drm_intel_bo_exec	T
+drm_intel_bo_fake_alloc_static	T
+drm_intel_bo_fake_disable_backing_store	T
+drm_intel_bo_flink	T
+drm_intel_bo_gem_create_from_name	T
+drm_intel_bo_get_subdata	T
+drm_intel_bo_get_tiling	T
+drm_intel_bo_map	T
+drm_intel_bo_pin	T
+drm_intel_bo_reference	T
+drm_intel_bo_set_tiling	T
+drm_intel_bo_subdata	T
+drm_intel_bo_unmap	T
+drm_intel_bo_unpin	T
+drm_intel_bo_unreference	T
+drm_intel_bo_wait_rendering	T
+drm_intel_bufmgr_check_aperture_space	T
+drm_intel_bufmgr_destroy	T
+drm_intel_bufmgr_fake_contended_lock_take	T
+drm_intel_bufmgr_fake_evict_all	T
+drm_intel_bufmgr_fake_init	T
+drm_intel_bufmgr_fake_set_exec_callback	T
+drm_intel_bufmgr_fake_set_fence_callback	T
+drm_intel_bufmgr_fake_set_last_dispatch	T
+drm_intel_bufmgr_gem_enable_reuse	T
+drm_intel_bufmgr_gem_init	T
+drm_intel_bufmgr_set_debug	T
 drm_mmAllocMem	T
@@ -26,12 +37 @@
 drm_mmInit	T
-intel_bo_fake_alloc_static	T
-intel_bo_fake_disable_backing_store	T
-intel_bo_gem_create_from_name	T
-intel_bufmgr_fake_contended_lock_take	T
-intel_bufmgr_fake_evict_all	T
-intel_bufmgr_fake_init	T
-intel_bufmgr_fake_set_exec_callback	T
-intel_bufmgr_fake_set_fence_callback	T
-intel_bufmgr_fake_set_last_dispatch	T
-intel_bufmgr_gem_enable_reuse	T
-intel_bufmgr_gem_init	T

	29 symbols removed
T dri_bo_alloc
T dri_bo_emit_reloc
T dri_bo_exec
T dri_bo_flink
T dri_bo_get_subdata
T dri_bo_get_tiling
T dri_bo_map
T dri_bo_pin
T dri_bo_reference
T dri_bo_set_tiling
T dri_bo_subdata
T dri_bo_unmap
T dri_bo_unpin
T dri_bo_unreference
T dri_bo_wait_rendering
T dri_bufmgr_check_aperture_space
T dri_bufmgr_destroy
T dri_bufmgr_set_debug
T intel_bo_fake_alloc_static
T intel_bo_fake_disable_backing_store
T intel_bo_gem_create_from_name
T intel_bufmgr_fake_contended_lock_take
T intel_bufmgr_fake_evict_all
T intel_bufmgr_fake_init
T intel_bufmgr_fake_set_exec_callback
T intel_bufmgr_fake_set_fence_callback
T intel_bufmgr_fake_set_last_dispatch
T intel_bufmgr_gem_enable_reuse
T intel_bufmgr_gem_init

	29 symbols added
T drm_intel_bo_alloc
T drm_intel_bo_emit_reloc
T drm_intel_bo_exec
T drm_intel_bo_fake_alloc_static
T drm_intel_bo_fake_disable_backing_store
T drm_intel_bo_flink
T drm_intel_bo_gem_create_from_name
T drm_intel_bo_get_subdata
T drm_intel_bo_get_tiling
T drm_intel_bo_map
T drm_intel_bo_pin
T drm_intel_bo_reference
T drm_intel_bo_set_tiling
T drm_intel_bo_subdata
T drm_intel_bo_unmap
T drm_intel_bo_unpin
T drm_intel_bo_unreference
T drm_intel_bo_wait_rendering
T drm_intel_bufmgr_check_aperture_space
T drm_intel_bufmgr_destroy
T drm_intel_bufmgr_fake_contended_lock_take
T drm_intel_bufmgr_fake_evict_all
T drm_intel_bufmgr_fake_init
T drm_intel_bufmgr_fake_set_exec_callback
T drm_intel_bufmgr_fake_set_fence_callback
T drm_intel_bufmgr_fake_set_last_dispatch
T drm_intel_bufmgr_gem_enable_reuse
T drm_intel_bufmgr_gem_init
T drm_intel_bufmgr_set_debug

# template for libdrm_intel.so.1 version script
LIBDRM_2.4.1 {
    global:
	drm_intel_bo_alloc;
	drm_intel_bo_emit_reloc;
	drm_intel_bo_exec;
	drm_intel_bo_fake_alloc_static;
	drm_intel_bo_fake_disable_backing_store;
	drm_intel_bo_flink;
	drm_intel_bo_gem_create_from_name;
	drm_intel_bo_get_subdata;
	drm_intel_bo_get_tiling;
	drm_intel_bo_map;
	drm_intel_bo_pin;
	drm_intel_bo_reference;
	drm_intel_bo_set_tiling;
	drm_intel_bo_subdata;
	drm_intel_bo_unmap;
	drm_intel_bo_unpin;
	drm_intel_bo_unreference;
	drm_intel_bo_wait_rendering;
	drm_intel_bufmgr_check_aperture_space;
	drm_intel_bufmgr_destroy;
	drm_intel_bufmgr_fake_contended_lock_take;
	drm_intel_bufmgr_fake_evict_all;
	drm_intel_bufmgr_fake_init;
	drm_intel_bufmgr_fake_set_exec_callback;
	drm_intel_bufmgr_fake_set_fence_callback;
	drm_intel_bufmgr_fake_set_last_dispatch;
	drm_intel_bufmgr_gem_enable_reuse;
	drm_intel_bufmgr_gem_init;
	drm_intel_bufmgr_set_debug;
};

vim:ft=diff


-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] fglrx update

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

Hi Valery!

Thursday 04, at 11:30:46 AM you wrote:

> On Wednesday 03 December 2008 19:16:32 Konstantin A. Lepikhov wrote:
> > > >  > http://lakostis.livejournal.com/10234.html - превед мантейнеру xorg!
> > > >
> > > > А всем коллективом на поруки взять? Проблема давно назрела...
> > >
> > > когда-то речь про xorg-compat шла...
> >
> > Проще libdrm откатить.
> 
> чего конкретно ему не хватает в 2.4.1?
> 	common sonames:
> libdrm.so.2	/usr/lib/libdrm.so.2.4.0	/usr/lib/libdrm.so.2.4.0
> libdrm_intel.so.1	/usr/lib/libdrm_intel.so.1.0.0	/usr/lib/libdrm_intel.so.1.0.0
> 
> libdrm.so.2 definitions unchanged
> 
Уж точно не символов от intel. Ща пересоберу и скажу.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] fglrx update

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]

> Hi Valery!
> 
> Thursday 04, at 11:30:46 AM you wrote:
> 
> > On Wednesday 03 December 2008 19:16:32 Konstantin A. Lepikhov wrote:
> > > > >  > http://lakostis.livejournal.com/10234.html - превед мантейнеру xorg!
> > > > >
> > > > > А всем коллективом на поруки взять? Проблема давно назрела...
> > > >
> > > > когда-то речь про xorg-compat шла...
> > >
> > > Проще libdrm откатить.
> > 
> > чего конкретно ему не хватает в 2.4.1?
> > 	common sonames:
> > libdrm.so.2	/usr/lib/libdrm.so.2.4.0	/usr/lib/libdrm.so.2.4.0
> > libdrm_intel.so.1	/usr/lib/libdrm_intel.so.1.0.0	/usr/lib/libdrm_intel.so.1.0.0
> > 
> > libdrm.so.2 definitions unchanged
> > 
> Уж точно не символов от intel. Ща пересоберу и скажу.
Похоже все еще хуже - внутри блоба проверяется версия libdrm (по-крайней
мере, там есть вызов drmGetVersion), видимо версия прибита гвоздями.
Завтра скажу точнее, как проясню этот вопрос с разработчиками fglrx. 

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] fglrx update

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

> > Hi Valery!
> > 
> > Thursday 04, at 11:30:46 AM you wrote:
> > 
> > > On Wednesday 03 December 2008 19:16:32 Konstantin A. Lepikhov wrote:
> > > > > >  > http://lakostis.livejournal.com/10234.html - превед мантейнеру xorg!
> > > > > >
> > > > > > А всем коллективом на поруки взять? Проблема давно назрела...
> > > > >
> > > > > когда-то речь про xorg-compat шла...
> > > >
> > > > Проще libdrm откатить.
> > > 
> > > чего конкретно ему не хватает в 2.4.1?
> > > 	common sonames:
> > > libdrm.so.2	/usr/lib/libdrm.so.2.4.0	/usr/lib/libdrm.so.2.4.0
> > > libdrm_intel.so.1	/usr/lib/libdrm_intel.so.1.0.0	/usr/lib/libdrm_intel.so.1.0.0
> > > 
> > > libdrm.so.2 definitions unchanged
> > > 
> > Уж точно не символов от intel. Ща пересоберу и скажу.
> Похоже все еще хуже - внутри блоба проверяется версия libdrm (по-крайней
> мере, там есть вызов drmGetVersion), видимо версия прибита гвоздями.
> Завтра скажу точнее, как проясню этот вопрос с разработчиками fglrx. 
лог разговора (частично урезанный):
...
[18:19:24] <L.A. Kostis> I have one question about fglrx and their
relation with new xorg
[18:19:48] <L.A. Kostis> libdrm, if be more correct
[18:20:26] <xxxx> Ok ... 
[18:21:18] <L.A. Kostis> why fglrx have so strict requires for libdrm
version? for example, it works only with 2.4.0 and fail with 2.4.1
[18:24:22] <xxxx> I'm not sure what you're talking about. I know that we
started shipping with our own versions of libdrm and libdri recently. The
reason is that libdrm and libdri tend to change and invalidate assumptions
in our code. This was biting us in the "behind" especially while we
introduced multi-ASIC support. 
[18:26:26] <L.A. Kostis> so if someone wants to use fglrx must use shipped
libdrm/libdri?
[18:26:35] <L.A. Kostis> shipped w/ fglrx
[18:27:32] <xxxx> Yes. 
[18:28:10] <L.A. Kostis> Ok, thanks. It shed some light to this situation
:)
[18:29:23] <xxxx> The other reason is that we're supporting multiple X
versions. Shipping our own version of libdrm/libdri we can avoid lots of
conditional compilation and hacks trying to work with every version of
libdrm/libdri out there. 

Т.е. думайте сами, решайте сами. Видимо, придется систему костылей и
подпорок расширять и на libdri/libdrm в случае fglrx.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] fglrx update

[Aleksey Novodvorsky]

4 декабря 2008 г. 18:53 пользователь Konstantin A. Lepikhov
<lakostis@unsafe.ru> написал:
> [18:29:23] <xxxx> The other reason is that we're supporting multiple X
> versions. Shipping our own version of libdrm/libdri we can avoid lots of
> conditional compilation and hacks trying to work with every version of
> libdrm/libdri out there.

Нет слов. Никогда не буду покупать их карты.

Rgrds, Алексей

Re: [sisyphus] fglrx update

[Mikhail Gusarov]

Twas brillig at 22:21:25 04.12.2008 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:

 >> [18:29:23] <xxxx> The other reason is that we're supporting multiple
 >> X versions. Shipping our own version of libdrm/libdri we can avoid
 >> lots of conditional compilation and hacks trying to work with every
 >> version of libdrm/libdri out there.

 AN> Нет слов. Никогда не буду покупать их карты.

У них есть свой резон: X.org и сопутствующие проекты последние года два
сильно и быстро меняются. Так что с точки зрения проприетарного вендора
(гм, у меня был момент в биографии, когда я настоял на таскании с одной
софтиной libstdc++ и libgcc, чтобы не собираться на всём диапазоне gcc
2.95 .. gcc 3.4) - вполне экономически верное решение.

-- 

Re: [sisyphus] fglrx update

[Anton Farygin]

Mikhail Gusarov пишет:
> Twas brillig at 22:21:25 04.12.2008 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:
> 
>  >> [18:29:23] <xxxx> The other reason is that we're supporting multiple
>  >> X versions. Shipping our own version of libdrm/libdri we can avoid
>  >> lots of conditional compilation and hacks trying to work with every
>  >> version of libdrm/libdri out there.
> 
>  AN> Нет слов. Никогда не буду покупать их карты.
> 
> У них есть свой резон: X.org и сопутствующие проекты последние года два
> сильно и быстро меняются. Так что с точки зрения проприетарного вендора
> (гм, у меня был момент в биографии, когда я настоял на таскании с одной
> софтиной libstdc++ и libgcc, чтобы не собираться на всём диапазоне gcc
> 2.95 .. gcc 3.4) - вполне экономически верное решение.

Одно только непонятно - почему таких проблем нет у nVidia...

Хотя, тоже переодически вылезает, но в гораздо меньшем маштабе.

Re: [sisyphus] fglrx update

[Mikhail Gusarov]

Twas brillig at 22:24:40 04.12.2008 UTC+03 when rider@altlinux.com did gyre and gimble:

 AF> Одно только непонятно - почему таких проблем нет у nVidia...

Потому что они не используют DRI? :)

-- 

Re: [sisyphus] fglrx update

[Led]

On Thursday, 04 December 2008 21:24:40 Anton Farygin wrote:
> Mikhail Gusarov пишет:
> > Twas brillig at 22:21:25 04.12.2008 UTC+03 when a.e.nvdv@gmail.com did 
gyre and gimble:
> >  >> [18:29:23] <xxxx> The other reason is that we're supporting multiple
> >  >> X versions. Shipping our own version of libdrm/libdri we can avoid
> >  >> lots of conditional compilation and hacks trying to work with every
> >  >> version of libdrm/libdri out there.
> >
> >  AN> Нет слов. Никогда не буду покупать их карты.
> >
> > У них есть свой резон: X.org и сопутствующие проекты последние года два
> > сильно и быстро меняются. Так что с точки зрения проприетарного вендора
> > (гм, у меня был момент в биографии, когда я настоял на таскании с одной
> > софтиной libstdc++ и libgcc, чтобы не собираться на всём диапазоне gcc
> > 2.95 .. gcc 3.4) - вполне экономически верное решение.
>
> Одно только непонятно - почему таких проблем нет у nVidia...

Потому что nVidia не использует libdrm/dri, а таскает свои велосипеды

> Хотя, тоже переодически вылезает, но в гораздо меньшем маштабе.

Не знаю, что значит "не такие масштабы", но то, что сейчас у меня nvidia 
вместо битмаповых шрифтов показывает чёрную размазню (абсольтно нечитаемую), 
ИМХО более, чем достаточно :(

-- 
Led

Re: [sisyphus] fglrx update

[Aleksey Novodvorsky]

4 декабря 2008 г. 22:25 пользователь Mikhail Gusarov
<dottedmag@altlinux.org> написал:
>
> Twas brillig at 22:21:25 04.12.2008 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:
>
>  >> [18:29:23] <xxxx> The other reason is that we're supporting multiple
>  >> X versions. Shipping our own version of libdrm/libdri we can avoid
>  >> lots of conditional compilation and hacks trying to work with every
>  >> version of libdrm/libdri out there.
>
>  AN> Нет слов. Никогда не буду покупать их карты.
>
> У них есть свой резон:
Конечно. И он как раз описан. Потому и не буду.

Rgrds, Алексей

Re: [sisyphus] fglrx update

[Konstantin A. Lepikhov]

Hi Mikhail!

Friday 05, at 01:25:01 AM you wrote:

> 
> Twas brillig at 22:21:25 04.12.2008 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:
> 
>  >> [18:29:23] <xxxx> The other reason is that we're supporting multiple
>  >> X versions. Shipping our own version of libdrm/libdri we can avoid
>  >> lots of conditional compilation and hacks trying to work with every
>  >> version of libdrm/libdri out there.
> 
>  AN> Нет слов. Никогда не буду покупать их карты.
> 
> У них есть свой резон: X.org и сопутствующие проекты последние года два
> сильно и быстро меняются. Так что с точки зрения проприетарного вендора
> (гм, у меня был момент в биографии, когда я настоял на таскании с одной
> софтиной libstdc++ и libgcc, чтобы не собираться на всём диапазоне gcc
> 2.95 .. gcc 3.4) - вполне экономически верное решение.
ls /opt/games/quake4/lib*
/opt/games/quake4/libgcc_s.so.1
/opt/games/quake4/libSDL-1.2.id.so.0
/opt/games/quake4/libstdc++.so.5
/opt/games/quake4/libstdc++.so.6

И никто не жужжит :)

-- 
WBR et al.

Re: [sisyphus] fglrx update

[Stanislav Ievlev]

On Fri, Dec 05, 2008 at 01:25:01AM +0600, Mikhail Gusarov wrote:
> 
> Twas brillig at 22:21:25 04.12.2008 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:
> 
>  >> [18:29:23] <xxxx> The other reason is that we're supporting multiple
>  >> X versions. Shipping our own version of libdrm/libdri we can avoid
>  >> lots of conditional compilation and hacks trying to work with every
>  >> version of libdrm/libdri out there.
> 
>  AN> Нет слов. Никогда не буду покупать их карты.
> 
> У них есть свой резон: X.org и сопутствующие проекты последние года два
> сильно и быстро меняются. Так что с точки зрения проприетарного вендора
> (гм, у меня был момент в биографии, когда я настоял на таскании с одной
> софтиной libstdc++ и libgcc, чтобы не собираться на всём диапазоне gcc
> 2.95 .. gcc 3.4) - вполне экономически верное решение.
Xorg действительно весьма творческий проект, но непонятно почему они не
сделали тогда уж libdrm_ati по аналогии с libdrm_intel. Вечно эти
проприатерные программисты что-то недистрибутивное придумывают :(

Re: [sisyphus] fglrx update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Fri, Dec 05, 2008 at 10:55:51AM +0300, Stanislav Ievlev wrote:
> On Fri, Dec 05, 2008 at 01:25:01AM +0600, Mikhail Gusarov wrote:
> > 
> > Twas brillig at 22:21:25 04.12.2008 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:
> > 
> >  >> [18:29:23] <xxxx> The other reason is that we're supporting multiple
> >  >> X versions. Shipping our own version of libdrm/libdri we can avoid
> >  >> lots of conditional compilation and hacks trying to work with every
> >  >> version of libdrm/libdri out there.
> > 
> >  AN> Нет слов. Никогда не буду покупать их карты.
> > 
> > У них есть свой резон: X.org и сопутствующие проекты последние года два
> > сильно и быстро меняются. Так что с точки зрения проприетарного вендора
> > (гм, у меня был момент в биографии, когда я настоял на таскании с одной
> > софтиной libstdc++ и libgcc, чтобы не собираться на всём диапазоне gcc
> > 2.95 .. gcc 3.4) - вполне экономически верное решение.
> Xorg действительно весьма творческий проект, но непонятно почему они не
> сделали тогда уж libdrm_ati по аналогии с libdrm_intel. Вечно эти
> проприатерные программисты что-то недистрибутивное придумывают :(

Когда в памяти одного процесса окажутся две разные версии libdrm, уже
не важно, как назывались библиотеки -- остаётся полагаться на случай.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] fglrx update

[Stanislav Ievlev]

On Fri, Dec 05, 2008 at 11:00:18AM +0300, Dmitry V. Levin wrote:
> On Fri, Dec 05, 2008 at 10:55:51AM +0300, Stanislav Ievlev wrote:
> > On Fri, Dec 05, 2008 at 01:25:01AM +0600, Mikhail Gusarov wrote:
> > > 
> > > Twas brillig at 22:21:25 04.12.2008 UTC+03 when a.e.nvdv@gmail.com did gyre and gimble:
> > > 
> > >  >> [18:29:23] <xxxx> The other reason is that we're supporting multiple
> > >  >> X versions. Shipping our own version of libdrm/libdri we can avoid
> > >  >> lots of conditional compilation and hacks trying to work with every
> > >  >> version of libdrm/libdri out there.
> > > 
> > >  AN> Нет слов. Никогда не буду покупать их карты.
> > > 
> > > У них есть свой резон: X.org и сопутствующие проекты последние года два
> > > сильно и быстро меняются. Так что с точки зрения проприетарного вендора
> > > (гм, у меня был момент в биографии, когда я настоял на таскании с одной
> > > софтиной libstdc++ и libgcc, чтобы не собираться на всём диапазоне gcc
> > > 2.95 .. gcc 3.4) - вполне экономически верное решение.
> > Xorg действительно весьма творческий проект, но непонятно почему они не
> > сделали тогда уж libdrm_ati по аналогии с libdrm_intel. Вечно эти
> > проприатерные программисты что-то недистрибутивное придумывают :(
> 
> Когда в памяти одного процесса окажутся две разные версии libdrm, уже
> не важно, как назывались библиотеки -- остаётся полагаться на случай.
Ну я подозреваю что интеловцы сделали всё нормально. А эти не смогли ...

Однако это всё не отменяет проблемы. 
Людей которые купили ATI в комлекте с ноутбуком достаточно много и бросать их на произвол 
судьбы не имеем права.

Костя, мог бы ты спросить этих умников, как они предполагают запуск их
поделия в системе где уже есть libdrm/libdri?

Re: [sisyphus] fglrx update

[Led]

On Friday, 05 December 2008 09:55:51 Stanislav Ievlev wrote:
> On Fri, Dec 05, 2008 at 01:25:01AM +0600, Mikhail Gusarov wrote:
> > Twas brillig at 22:21:25 04.12.2008 UTC+03 when a.e.nvdv@gmail.com did 
gyre and gimble:
> >  >> [18:29:23] <xxxx> The other reason is that we're supporting multiple
> >  >> X versions. Shipping our own version of libdrm/libdri we can avoid
> >  >> lots of conditional compilation and hacks trying to work with every
> >  >> version of libdrm/libdri out there.
> >
> >  AN> Нет слов. Никогда не буду покупать их карты.
> >
> > У них есть свой резон: X.org и сопутствующие проекты последние года два
> > сильно и быстро меняются. Так что с точки зрения проприетарного вендора
> > (гм, у меня был момент в биографии, когда я настоял на таскании с одной
> > софтиной libstdc++ и libgcc, чтобы не собираться на всём диапазоне gcc
> > 2.95 .. gcc 3.4) - вполне экономически верное решение.
>
> Xorg действительно весьма творческий проект,

Жаль, что творческие порыви у них заканчиваются на ломании интерфейсов 
библиотек какждые полгода. Лучше бы X-протокол 25-летней давности к 
сегодняшним реалиям привели.

-- 
Led

Re: [sisyphus] fglrx update

[Valery V. Inozemtsev]

[-- Attachment #1: Type: text/plain, Size: 634 bytes --]

On Thursday 04 December 2008 18:53:44 Konstantin A. Lepikhov wrote:
> [18:29:23] <xxxx> The other reason is that we're supporting multiple X
> versions. Shipping our own version of libdrm/libdri we can avoid lots of
> conditional compilation and hacks trying to work with every version of
> libdrm/libdri out there.
>
> Т.е. думайте сами, решайте сами. Видимо, придется систему костылей и
> подпорок расширять и на libdri/libdrm в случае fglrx.

случай клинический. пациент похоже не жилец

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] fglrx update

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Thu, Dec 04, 2008 at 10:35:54PM +0300, Valery V. Inozemtsev wrote:
> On Thursday 04 December 2008 18:53:44 Konstantin A. Lepikhov wrote:
> > [18:29:23] <xxxx> The other reason is that we're supporting multiple X
> > versions. Shipping our own version of libdrm/libdri we can avoid lots of
> > conditional compilation and hacks trying to work with every version of
> > libdrm/libdri out there.
> >
> > Т.е. думайте сами, решайте сами. Видимо, придется систему костылей и
> > подпорок расширять и на libdri/libdrm в случае fglrx.
> 
> случай клинический. пациент похоже не жилец

Интересно, как поведут себя системные libGL и xorg-server (слинкованные
с libdrm), если заменить системный libdrm на проприетарную версию из
fglrx?  Наверное, просто рухнут?  В таком случае fglrx'у придётся носить
с собой и их...


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] fglrx update

[Ivan Adzhubey]

On Thursday 04 December 2008 02:35:54 pm Valery V. Inozemtsev wrote:
> On Thursday 04 December 2008 18:53:44 Konstantin A. Lepikhov wrote:
> > [18:29:23] <xxxx> The other reason is that we're supporting multiple X
> > versions. Shipping our own version of libdrm/libdri we can avoid lots of
> > conditional compilation and hacks trying to work with every version of
> > libdrm/libdri out there.
> >
> > Т.е. думайте сами, решайте сами. Видимо, придется систему костылей и
> > подпорок расширять и на libdri/libdrm в случае fglrx.
>
> случай клинический. пациент похоже не жилец

Если под пациентом имеется в виду ALTLinux, то видимо таки да - не жилец. Без 
иксов.

--Иван

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

Re: [sisyphus] fglrx update

[Konstantin A. Lepikhov]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

Hi Valery!

Thursday 04, at 10:35:54 PM you wrote:

> On Thursday 04 December 2008 18:53:44 Konstantin A. Lepikhov wrote:
> > [18:29:23] <xxxx> The other reason is that we're supporting multiple X
> > versions. Shipping our own version of libdrm/libdri we can avoid lots of
> > conditional compilation and hacks trying to work with every version of
> > libdrm/libdri out there.
> >
> > Т.е. думайте сами, решайте сами. Видимо, придется систему костылей и
> > подпорок расширять и на libdri/libdrm в случае fglrx.
> 
> случай клинический. пациент похоже не жилец
Если мантейнер libdrm тоже является поциентом, то неудивительно:

rpmsodiff rpmsodiff libdrm-2.4.0-alt1.i586.rpm libdrm-2.4.0-alt4.i586.rpm:

...
        23 symbols removed
	T drmBOBusy
	T drmBOCreate
	T drmBOInfo
	T drmBOMap
	T drmBOReference
	T drmBOSetStatus
	T drmBOUnmap
	T drmBOUnreference
	T drmBOVersion
	T drmBOWaitIdle
	T drmFenceBuffers
	T drmFenceCreate
	T drmFenceEmit
	T drmFenceFlush
	T drmFenceReference
	T drmFenceSignaled
	T drmFenceUnreference
	T drmFenceUpdate
	T drmFenceWait
	T drmMMInit
	T drmMMLock
	T drmMMTakedown
	T drmMMUnlock

        1 symbols added
	T drmMsg

О чем вообще тогда речь, если в рамках _одной_ версии вот так просто
удаляются все важные символы? Причем changelog как всегда краток и
загадочен:

* Sun Oct 19 12:00:00 2008 Valery Inozemtsev <shrek@altlinux> 2.4.0-alt4
- enabled support for using udev instead of mknod

* Sun Oct 19 12:00:00 2008 Valery Inozemtsev <shrek@altlinux> 2.4.0-alt3
- 2.4.0 release

* Tue Mar 25 12:00:00 2008 Valery Inozemtsev <shrek@altlinux> 2.4.0-alt2
- GIT snapshot 2008-05-28

* Mon Nov 12 12:00:00 2007 Valery Inozemtsev <shrek@altlinux> 2.4.0-alt1
- 2.4.0

Может быть не надо надувать щеки и ругать других?

PS спасибо dfo@ за замеченный фокус в поведении libdrm.

-- 
WBR et al.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]