Re: [Mesa-dev] [PATCH] intel: Change vendor string to Intel(R) Open Source Technology Center.
On Thu, May 31, 2012 at 8:19 PM, Kenneth Graunke kenn...@whitecape.orgwrote: Tungsten Graphics has not existed for several years, and the majority of ongoing development and support is done by Intel. I chose to include Open Source Technology Center to distinguish it from, say, the closed source Windows OpenGL driver. The one downside to this patch is that applications that pattern match against Intel may start applying workarounds meant for the Windows driver. However, it does seem like the right thing to do. This does change oglconform behavior. Acked-by: Eric Anholt e...@anholt.net Acked-by: Ian Romanick ian.d.roman...@intel.com Cc: Eugeni Dodonov eug...@dodonov.net Signed-off-by: Kenneth Graunke kenn...@whitecape.org Acked-by: Eugeni Dodonov eugeni.dodo...@intel.com Just to confirm my thoughts - this change would go in the 8.1 release as the earliest, correct? -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/1] intel: add PCI IDs for Ivy Bridge GT2 server variant
Those IDs are used by Bromolow. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- include/pci_ids/i965_pci_ids.h |1 + src/mesa/drivers/dri/intel/intel_chipset.h |4 +++- src/mesa/drivers/dri/intel/intel_context.c |1 + 3 files changed, 5 insertions(+), 1 deletion(-) diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h index a291509..e38f8d2 100644 --- a/include/pci_ids/i965_pci_ids.h +++ b/include/pci_ids/i965_pci_ids.h @@ -25,6 +25,7 @@ CHIPSET(0x0162, IVYBRIDGE_GT2, ivb_gt2) CHIPSET(0x0156, IVYBRIDGE_M_GT1, ivb_gt1) CHIPSET(0x0166, IVYBRIDGE_M_GT2, ivb_gt2) CHIPSET(0x015a, IVYBRIDGE_S_GT1, ivb_gt1) +CHIPSET(0x016a, IVYBRIDGE_S_GT2, ivb_gt2) CHIPSET(0x0402, HASWELL_GT1, hsw_gt1) CHIPSET(0x0412, HASWELL_GT2, hsw_gt2) CHIPSET(0x0406, HASWELL_M_GT1, hsw_gt1) diff --git a/src/mesa/drivers/dri/intel/intel_chipset.h b/src/mesa/drivers/dri/intel/intel_chipset.h index 424c70c..c1d904e 100644 --- a/src/mesa/drivers/dri/intel/intel_chipset.h +++ b/src/mesa/drivers/dri/intel/intel_chipset.h @@ -85,6 +85,7 @@ #define PCI_CHIP_IVYBRIDGE_M_GT10x0156 /* Mobile */ #define PCI_CHIP_IVYBRIDGE_M_GT20x0166 #define PCI_CHIP_IVYBRIDGE_S_GT10x015a /* Server */ +#define PCI_CHIP_IVYBRIDGE_S_GT20x016a #define PCI_CHIP_HASWELL_GT10x0402 /* Desktop */ #define PCI_CHIP_HASWELL_GT20x0412 @@ -153,7 +154,8 @@ devid == PCI_CHIP_IVYBRIDGE_S_GT1) #define IS_IVB_GT2(devid) (devid == PCI_CHIP_IVYBRIDGE_GT2 || \ -devid == PCI_CHIP_IVYBRIDGE_M_GT2) +devid == PCI_CHIP_IVYBRIDGE_M_GT2 || \ +devid == PCI_CHIP_IVYBRIDGE_S_GT2) #define IS_IVYBRIDGE(devid) (IS_IVB_GT1(devid) || IS_IVB_GT2(devid)) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index ff2b7fe..0a813a4 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -183,6 +183,7 @@ intelGetString(struct gl_context * ctx, GLenum name) chipset = Intel(R) Ivybridge Mobile; break; case PCI_CHIP_IVYBRIDGE_S_GT1: + case PCI_CHIP_IVYBRIDGE_S_GT2: chipset = Intel(R) Ivybridge Server; break; case PCI_CHIP_HASWELL_GT1: -- 1.7.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] dri: Make reverting to software direct rendering a critical error.
On Fri, Feb 3, 2012 at 23:14, Carl Worth cwo...@cworth.org wrote: Something has gone wrong if we have to revert to software rendering. The user really should be made aware of this, (and instructed to set LIBGL_DEBUG for more details). --- src/glx/dri_glx.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) For the series: Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com Reverting to software rendering (or indirect rendering) is usually a symptom of something being very very wrong, but right now we do not inform the users about this clearly enough. So in some cases, what happens is the reaction like everything still works, but slower - which adds some additional steps to the issue triaging. So I am all for this change. -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] intel: verify if hardware has LLC support
Rely on libdrm HAS_LLC parameter to verify if hardware supports it. In case the libdrm version does not supports this check, fallback to older way of detecting it which assumed that GPUs newer than GEN6 have it. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- src/mesa/drivers/dri/intel/intel_context.c |1 + src/mesa/drivers/dri/intel/intel_context.h |1 + src/mesa/drivers/dri/intel/intel_screen.c |8 src/mesa/drivers/dri/intel/intel_screen.h |2 ++ 4 files changed, 12 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c index 81ba6a1..377bcbc 100644 --- a/src/mesa/drivers/dri/intel/intel_context.c +++ b/src/mesa/drivers/dri/intel/intel_context.c @@ -628,6 +628,7 @@ intelInitContext(struct intel_context *intel, intel-has_separate_stencil = intel-intelScreen-hw_has_separate_stencil; intel-must_use_separate_stencil = intel-intelScreen-hw_must_use_separate_stencil; intel-has_hiz = intel-intelScreen-hw_has_hiz; + intel-has_llc = intel-intelScreen-hw_has_llc; memset(ctx-TextureFormatSupported, 0, sizeof(ctx-TextureFormatSupported)); diff --git a/src/mesa/drivers/dri/intel/intel_context.h b/src/mesa/drivers/dri/intel/intel_context.h index 4d4e030..150e55f 100644 --- a/src/mesa/drivers/dri/intel/intel_context.h +++ b/src/mesa/drivers/dri/intel/intel_context.h @@ -213,6 +213,7 @@ struct intel_context bool has_separate_stencil; bool must_use_separate_stencil; bool has_hiz; + bool has_llc; int urb_size; diff --git a/src/mesa/drivers/dri/intel/intel_screen.c b/src/mesa/drivers/dri/intel/intel_screen.c index 063bbe7..60781e5 100644 --- a/src/mesa/drivers/dri/intel/intel_screen.c +++ b/src/mesa/drivers/dri/intel/intel_screen.c @@ -735,6 +735,14 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp) intelScreen-hw_has_hiz = intelScreen-gen = 6; intelScreen-dri2_has_hiz = INTEL_DRI2_HAS_HIZ_UNKNOWN; +#if defined(I915_PARAM_HAS_LLC) + intelScreen-hw_has_llc = + intel_get_boolean(intelScreen-driScrnPriv, + I915_PARAM_HAS_LLC); +#else + intelScreen-hw_has_llc = intelScreen-gen = 6; +#endif + intel_override_hiz(intelScreen); intel_override_separate_stencil(intelScreen); diff --git a/src/mesa/drivers/dri/intel/intel_screen.h b/src/mesa/drivers/dri/intel/intel_screen.h index 6c6b516..a6baf16 100644 --- a/src/mesa/drivers/dri/intel/intel_screen.h +++ b/src/mesa/drivers/dri/intel/intel_screen.h @@ -116,6 +116,8 @@ struct intel_screen bool kernel_has_gen7_sol_reset; + bool hw_has_llc; + bool no_vbo; dri_bufmgr *bufmgr; struct _mesa_HashTable *named_regions; -- 1.7.8.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] intel: check for LLC support when reading maps
This checks for advertised LLC support by the GPU instead of relying on
the GPU generation for detection.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index eae79c1..5290da4 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -1052,7 +1052,7 @@ intel_miptree_map(struct intel_context *intel,
intel_miptree_map_s8(intel, mt, map, level, slice);
} else if (mt-stencil_mt) {
intel_miptree_map_depthstencil(intel, mt, map, level, slice);
- } else if (intel-gen = 6
+ } else if (intel-has_llc
!(mode GL_MAP_WRITE_BIT)
!mt-compressed
mt-region-tiling == I915_TILING_X) {
--
1.7.8.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Remove the INTEL_OLD_VS option.
On Tue, Jan 17, 2012 at 10:57, Kenneth Graunke kenn...@whitecape.orgwrote: Now that we no longer generate Mesa IR from GLSL IR, it's impossible to use the old vertex shader backend for GLSL programs. There's simply no Mesa IR to codegen from. Any attempt to do so would result in immediate GPU hangs, presumably due to the driver uploading an empty program with no EOT message. Signed-off-by: Kenneth Graunke kenn...@whitecape.org Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] i965/gen7: Enable transform feedback as long as kernel support is present.
On Mon, Jan 2, 2012 at 17:37, Eric Anholt e...@anholt.net wrote: - if (intel-gen == 6 || (intel-gen == 7 override_version = 30)) + if (intel-gen == 6 || + (intel-gen == 7 intel-intelScreen-kernel_has_gen7_sol_reset)) ctx-Extensions.EXT_transform_feedback = true; If the kernel patch in previous series would return ... value = IS_GEN7(dev); ... the line above could be simplified to: if (intel-gen == 6 || intel-intelScreen-kernel_has_gen7_sol_reset) But on the other hand, it would work either way. The check for GEN7 in kernel looks cleaner and more logically correct to me, but in any case: Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Revert intel: Drop the immediate validation of the texture object in TFP.
On Tue, Nov 1, 2011 at 16:58, Chad Versace c...@chad-versace.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2011 09:33 AM, Eric Anholt wrote: This reverts commit abaebcee787eeb8a89bf7a82ed4d1532fcde5e39. The assertion I made was that the zero-copy code in validation would zero copy. Of course, I deleted that check back in January because the two sites that would trigger it (glTexImage() and this one) both immediately bound their mt to the object, making the other check pointless. Removes two extra blits in glx-tfp. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42152 --- src/mesa/drivers/dri/intel/intel_tex_image.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) This fixes a bug with the Android Gingerbread home screen and application menu. Tested-by: Chad Versace c...@chad-versace.us Tested-by: Eugeni Dodonov eugeni.dodo...@intel.com -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ralloc: Add new [v]asprintf_rewrite_tail functions.
On Tue, Oct 25, 2011 at 00:33, Kenneth Graunke kenn...@whitecape.orgwrote: This can be useful if you want to create a bunch of temporary strings with a common prefix. For example, when iterating over uniform structure fields, one might want to create temporary strings like pallete.primary, palette.outline, and pallette.shadow. This could be done by overwriting the '.' with a null-byte and calling ralloc_asprintf_append, but that incurs the cost of strlen(pallete) every time...when this is already known. These new functions allow you rewrite the tail of the string, given a starting index. If the starting index is the length of the string, this is equivalent to appending. Signed-off-by: Kenneth Graunke kenn...@whitecape.org Looks useful, and removal of extra strlen is nice bonus. Reviewed-By: Eugeni Dodonov eugeni.dodo...@intel.com -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] implicit declaration of function wl_drm_create
2011/10/18 chris wwzbw...@163.com Dear Could anyone tell me where is the wl_drm_create function defined? I can't find it anywhere, no definition can be found. No google information can be searched! Why? It comes from wayland: http://cgit.freedesktop.org/wayland Check out the wayland and wayland-demos projects. -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC 0/3] Fix several segmentation faults related to depth buffer
On Mon, Sep 5, 2011 at 16:37, Alon Levy al...@redhat.com wrote: Fixes three segmentation faults where it is wrongly assumed the depth buffer's renderbuffer's region is not NULL. 735794 - verified to be fixed by these three patches (these three apply to 7.11 almost cleanly, just the second requires minor changes). Related RHBZs (maybe solved as well, didn't reproduce): 734183 - [abrt] gnome-shell-3.1.4-2.gite7b9933.fc16: prepare_depthbuffer 717140 -[abrt] compiz-0.9.4-2.fc15: prepare_depthbuffer Alon Levy (3): i965: prepare_depthbuffer: fix segfault, rhbz#735794 i965: prepare_depthbuffer: don't update NULL region'ed surface, rhbz#735794 i965: emit_depthbuffer: fix segfault, rhbz#735794 src/mesa/drivers/dri/i965/brw_misc_state.c |7 +-- src/mesa/drivers/dri/i965/brw_wm_surface_state.c |3 +++ 2 files changed, 8 insertions(+), 2 deletions(-) Hi Alon, those patches fix the crash you are having, but I am wondering why the crash happened in the first place. E.g., we should not get to the situation where region is NULL under normal cases. From what it looks like, it could happen when GPU was hung for example. Could you open a bug on freedesktop.org bugzilla and attach dmesg and /sys/kernel/debug/dri/0/i915_error_state, so we could look into it further? -- Eugeni Dodonov ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: Give an explanation why we are exiting for debugging.
This could happen in 3 different cases, and ERRNO can explain what
happened. First case would be EIO (gpu hang), second EINVAL (something is
wrong inside the batch), and we also discovered that sometimes it happens
with ENOSPACE. All of those cases are different it it could be worth to at
least know what happened.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index db4343b..73367f3 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -138,6 +138,7 @@ do_flush_locked(struct intel_context *intel)
}
if (ret != 0) {
+ _mesa_warning(NULL, do_flush_locked: %d\n, ret);
exit(1);
}
intel-vtbl.new_batch(intel);
--
1.7.6.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: fix build error
On Sat, Sep 3, 2011 at 11:29, Liu Aleaxander aleaxan...@gmail.com wrote:
On Sat, Sep 3, 2011 at 10:24 PM, Paul Berry stereotype...@gmail.com
wrote:
On 3 September 2011 07:07, Liu Aleaxander aleaxan...@gmail.com wrote:
From f02de851ba728642e26cce6fe76e5482619813e7 Mon Sep 17 00:00:00 2001
From: Yuanhan Liu yuanhan@linux.intel.com
Date: Sun, 4 Sep 2011 06:02:14 +0800
Subject: [PATCH] intel: fix build error
Fix a build error introduced by commit 6862b54f:
i965_dri.so.tmp: undefined reference to `strerr'
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index c4bb836..98ae4e9 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -138,7 +138,7 @@ do_flush_locked(struct intel_context *intel)
}
if (ret != 0) {
- fprintf(stderr, intel_do_flush_locked failed: %s\n,
strerr(ret));
+ fprintf(stderr, intel_do_flush_locked failed: %s\n,
strerror(ret));
exit(1);
}
intel-vtbl.new_batch(intel);
--
1.7.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
I was just about to start tracking down this failure. Thanks.
Reviewed-by: Paul Berry stereotype...@gmail.com
I'm guessing you don't have commit access since I don't see your name in
the
commit history, so I'll go ahead and push the patch.
Yes, please.
Thanks - I fixed this locally but forgot to push yesterday.
This serves as a mental note to myself that even one-line patches could go
wrong :(. Sorry.
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: Give an explanation why we are exiting for debugging.
From: Eugeni Dodonov eugeni.dodo...@intel.com
This could happen in 3 different cases, and ERRNO can explain what
happened. First case would be EIO (gpu hang), second EINVAL (something is
wrong inside the batch), and we also discovered that sometimes it happens
with ENOSPACE. All of those cases are different it it could be worth to at
least know what happened.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index db4343b..73367f3 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -138,6 +138,7 @@ do_flush_locked(struct intel_context *intel)
}
if (ret != 0) {
+ _mesa_warning(NULL, do_flush_locked: %d\n, ret);
exit(1);
}
intel-vtbl.new_batch(intel);
--
1.7.6.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Give an explanation why we are exiting for debugging.
On Fri, Sep 2, 2011 at 15:53, Eric Anholt e...@anholt.net wrote:
On Fri, 2 Sep 2011 12:33:44 -0300, Eugeni Dodonov eug...@dodonov.net
wrote:
From: Eugeni Dodonov eugeni.dodo...@intel.com
This could happen in 3 different cases, and ERRNO can explain what
happened. First case would be EIO (gpu hang), second EINVAL (something is
wrong inside the batch), and we also discovered that sometimes it happens
with ENOSPACE. All of those cases are different it it could be worth to
at
least know what happened.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
src/mesa/drivers/dri/intel/intel_batchbuffer.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index db4343b..73367f3 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -138,6 +138,7 @@ do_flush_locked(struct intel_context *intel)
}
if (ret != 0) {
+ _mesa_warning(NULL, do_flush_locked: %d\n, ret);
exit(1);
}
intel-vtbl.new_batch(intel);
I would make it
fprintf(stderr, intel_batchbuffer_flush failed: %s\n, strerror(ret));
You want the output even if built without Mesa debugging enabled, and
strings are nicer than numbers.
Indeed, thanks for the idea!
--
Eugeni Dodonov
http://eugeni.dodonov.net/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] DEATH to old drivers!
On Wed, Aug 24, 2011 at 19:41, Luc Verhaegen l...@skynet.be wrote: On Wed, Aug 24, 2011 at 03:34:44PM -0700, Ian Romanick wrote: I'll also point out that DRI2 isn't the only problem. There are a lot of refactors and optimizations that I'd like to do that will benefit more modern cards. However, due to missing (hardware) features and lack of a maintainer, these older drivers make this somewhere between impossible and excruciating. That's what I'm really trying to accomplish. I want to reduce the ongoing maintenance of drivers that are actively being developed. So mesa will only either support full cpu rendering, or only rendering on those chips who have those features that infrastructure developers care for today. This will narrow down the already limited working linux hardware timeframe further. I think you missing a point there. Those drivers will work (if it can be called work :)) with older mesa versions, nothing stops you from downgrading mesa on relict systems which only has museum cards. But the state is that no new development nor support nor maintainance nor even touching happens with those drivers at all for the past years, so they are just sitting idle there. If someone (and has such cards, and believe that they should be maintained) volunteeres to maintain them and bring them back to shape, I believe that this someone will be very *very* welcomed to do so. Otherwise, I agree that those drivers should be dropped from never releases. That's how life works... -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Version 7.11 is missing on freedesktop bugzilla
Hi, The 7.11 version of Mesa is missing on freedesktop bugzilla, could someone add it please? -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix format not a string literal error with -Werror=format-security
From: Eugeni Dodonov eug...@mandriva.com
A trivial fix for error: format not a string literal and no format
arguments with compiling with -Werror=format-security flags.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 09033ae..7c73a8f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -100,7 +100,7 @@ fs_visitor::fail(const char *format, ...)
this-fail_msg = msg;
if (INTEL_DEBUG DEBUG_WM) {
- fprintf(stderr, msg);
+ fprintf(stderr, %s, msg);
}
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
