Re: Gtkradiant not working with radeon driver
On Tue, 2007-10-30 at 02:33 +, Jose Rodriguez wrote: I´m not sure what do you mean by ddx [...] The X driver. For 3D, usually only the Mesa driver is relevant. I installed the xserver-xorg-video-ati-dbg and libc6-dbg packages [...] You need to install libgl1-mesa-dri-dbg or build from mesa Git. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel hw and caching interface to TTM..
Dave Airlie wrote: Hi, So currently the TTM interface allows the user specify a cacheable allocation, and on Intel hardware this gets conflated with using the intel snooped memory type in the GART. This is bad as the intel snooped memory type comes with its own set of special rules and sucks for lots of things. However I want to be able to use the cacheable CPU memory with the GPU to a) make things go fast b) avoid lots of SMP cross-talking and cache flushing (see a) c) buffer object creation faster Cool. So this led me to the patch at: http://cgit.freedesktop.org/~airlied/drm/diff/?h=intel-hackeryid=da14a0bbb8849cdc91ca87786fde90ac36fe1198 I could add back the snooped option if we want using a driver private flag. Dave, I'd like to see the flag DRM_BO_FLAG_CACHED really mean cache-coherent memory, that is cache coherent also while visible to the GPU. There are HW implementations out there (Poulsbo at least) where this option actually seems to work, althought it's considerably slower for things like texturing. It's also a requirement for user bo's since they will have VMAs that we cant kill and remap. Could we perhaps change the flag DRM_BO_FLAG_READ_CACHED to mean DRM_BO_FLAG_MAPPED_CACHED to implement the behaviour you describe. This will also indicate that the buffer cannot be used for user-space sub-allocators, as we in that case must be able to guarantee that the CPU can access parts of the buffer while other parts are validated for the GPU. This patch evicts the buffer on mapping so the GPU doesn't see anything via the aperture or otherwise, and flushes before validating into the aperture. It doesn't contain the chipset flush patch yet which is requried to actually make it work (add agp_chipset_flush to i915_dma.c before submitting the batchbuffer) OK. This works and appears to be nice and fast, all userspace buffers can be allocated _LOCAL | _CACHED and validated to _TT later without any major cache flushing overhead when we have clflush, and without SMP overhead at all as cache flushing is cache coherent on the Intel chipsets I've played with so far (CPU coherent- not GPU) Does this mean that clflush() on one processor flushes the cache line on all processors in an SMP system? No need for preemption guarding and IPIs? I of course need to makes this code not so x86 specific, so I might add a page flush hook to the driver interface and put the flushing code in the driver side. This also leads me into backwards compatibility, the chipset flushing changes to AGP are required for all of this good stuff, options are 1) resurrect linux-agp-compat add chipset flushing code - easier 2) try and hack chipset flushing into drm_compat.c - probably more difficult that I would like to bother with.. So comments please on whether a comeback for linux-agp-compat is a good or bad thing.. Perhaps an intel-specific TTM backend? Dave. /Thomas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: Unknown symbol __you_cannot_kmalloc_that_much when compile drm against kernel 2.6.21
Jesse Barnes wrote: Sorry about that, a piece of code snuck into that commit that shouldn't have. Fixed in 6342e0507be177be309774aff0c31746beab73f6. It is OK now. Nian Jesse On Monday, October 29, 2007 1:49 am Wu, Nian wrote: Hi, Jesse, When compiled drm module against kernel 2.6.21, it complaint that : WARNING: __you_cannot_kmalloc_that_much [/GFX/build/component/Drm/drm/linux-core/i915.ko] undefined! And when started up XOrg, it reported below error and DRI was disabled: FATAL: Error inserting i915 (/lib/modules/2.6.21/kernel/drivers/char/drm/i915.ko): Unknown symbol in module, or unknown parameter (see dmesg) (EE) [drm] drmOpen failed. (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. Dmesg messages: i915: Unknown symbol __you_cannot_kmalloc_that_much - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel hw and caching interface to TTM..
Dave, I'd like to see the flag DRM_BO_FLAG_CACHED really mean cache-coherent memory, that is cache coherent also while visible to the GPU. There are HW implementations out there (Poulsbo at least) where this option actually seems to work, althought it's considerably slower for things like texturing. It's also a requirement for user bo's since they will have VMAs that we cant kill and remap. Most PCIE cards will be cache coherent, however AGP cards not so much, so need to think if a generic _CACHED makes sense especially for something like radeon, will I have to pass different flags depending on the GART type this seems like uggh.. so maybe a separate flag makes more sense.. Could we perhaps change the flag DRM_BO_FLAG_READ_CACHED to mean DRM_BO_FLAG_MAPPED_CACHED to implement the behaviour you describe. This will also indicate that the buffer cannot be used for user-space sub-allocators, as we in that case must be able to guarantee that the CPU can access parts of the buffer while other parts are validated for the GPU. Yes, to be honest sub-allocators for most use-cases should be avoided if possible, we should be able to make the kernel interface fast enough for most things if we don't have to switching caching flags on the fly at map/destroy etc.. Does this mean that clflush() on one processor flushes the cache line on all processors in an SMP system? No need for preemption guarding and IPIs? Yes this is specified to do this, tlb flushing would require ipi but we should mostly be able to avoid doing tlb flushes from what I can see, the problem I was seeing on i9xx was the chipset had its own Global Write Buffer which wasn't that well documented.. so stuff could hide in it.. So comments please on whether a comeback for linux-agp-compat is a good or bad thing.. Perhaps an intel-specific TTM backend? Actually I did a backport into a i915_compat.c and it seems like I can make that work, However something in the changes you made in your branch, broke something on me, so I'll have to spend tomorrow rebasing my tree with your patches to see what went wrong, something doesn't appear to be getting flushed at the right time. Dave. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel hw and caching interface to TTM..
Dave Airlie wrote: Dave, I'd like to see the flag DRM_BO_FLAG_CACHED really mean cache-coherent memory, that is cache coherent also while visible to the GPU. There are HW implementations out there (Poulsbo at least) where this option actually seems to work, althought it's considerably slower for things like texturing. It's also a requirement for user bo's since they will have VMAs that we cant kill and remap. Most PCIE cards will be cache coherent, however AGP cards not so much, so need to think if a generic _CACHED makes sense especially for something like radeon, will I have to pass different flags depending on the GART type this seems like uggh.. so maybe a separate flag makes more sense.. Could we perhaps change the flag DRM_BO_FLAG_READ_CACHED to mean DRM_BO_FLAG_MAPPED_CACHED to implement the behaviour you describe. This will also indicate that the buffer cannot be used for user-space sub-allocators, as we in that case must be able to guarantee that the CPU can access parts of the buffer while other parts are validated for the GPU. Yes, to be honest sub-allocators for most use-cases should be avoided if possible, we should be able to make the kernel interface fast enough for most things if we don't have to switching caching flags on the fly at map/destroy etc.. Hmm - if that was true why do we have malloc() and friends - aren't they just sub-allocators for brk() and mmap()? There is more to this than performance - applications out there can allocate extraordinarily large numbers of small textures, that can only sanely be dealt with as light-weight userspace suballocations of a sensible-sized buffer. (We don't do this yet, but will need to at some point!). The reasons for this are granularity (ie wasted space in the allocation), the memory overhead of managing all these allocations, and perhaps third performance. If you think about what goes on in a 3d driver, you are always doing sub-allocations of some sort or another, though that's more obvious when you start doing state objects that have an independent lifecycle as opposed to just emitting state linearly into a command buffer. For managing objects of a few dozen bytes, obviously you are going to want to do that in userspace. So there is a continuum where successively larger buffers increasingly justify whatever additional cost there is to go directly to the kernel to allocate them. But for sufficiently small or frequently allocated buffers, there will always be a crossover point where it is faster to do it in userspace. It certainly makes sense to speed up the kernel paths, but that won't make the crossover point go away - it'll just shift it more or less depending on how successful you are. Keith - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel hw and caching interface to TTM..
Dave Airlie wrote: Dave, I'd like to see the flag DRM_BO_FLAG_CACHED really mean cache-coherent memory, that is cache coherent also while visible to the GPU. There are HW implementations out there (Poulsbo at least) where this option actually seems to work, althought it's considerably slower for things like texturing. It's also a requirement for user bo's since they will have VMAs that we cant kill and remap. Most PCIE cards will be cache coherent, however AGP cards not so much, so need to think if a generic _CACHED makes sense especially for something like radeon, will I have to pass different flags depending on the GART type this seems like uggh.. so maybe a separate flag makes more sense.. OK. We're using this functionality in Poulsbo, so we should probably sort this out to avoid breaking things. Could we perhaps change the flag DRM_BO_FLAG_READ_CACHED to mean DRM_BO_FLAG_MAPPED_CACHED to implement the behaviour you describe. This will also indicate that the buffer cannot be used for user-space sub-allocators, as we in that case must be able to guarantee that the CPU can access parts of the buffer while other parts are validated for the GPU. Yes, to be honest sub-allocators for most use-cases should be avoided if possible, we should be able to make the kernel interface fast enough for most things if we don't have to switching caching flags on the fly at map/destroy etc.. Yes, Eric seems to have the same opinion. I'm not quite sure I understand the reasoning behind it. Is it the added complexity or something else? While it's super to have a fast kernel interface, the inherent latency and allocation granularity will probably always make a user-space sub-allocator a desirable thing. Particularly something like a slab allocator that would also to some extent avoid fragmentation. My view of TTM has changed to be a bit from the opposite side: Let's say we have a fast user-space per-client allocator. What kernel functionality would we require to make sure that it can assume it's the sole owner of the memory it manages? For a repeated usage pattern like batch-buffers we end up allocating pages from the kernel, setting up one VMA per buffer, modifying gart- and page tables and in the worst case even caching policy for each and every use. Even if this can be made reasonably fast, I think it's a CPU overhead we really shouldn't be paying?? /Thomas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel hw and caching interface to TTM..
OK. We're using this functionality in Poulsbo, so we should probably sort this out to avoid breaking things. Okay I'll try and fix it back up tomorrow.. Yes, Eric seems to have the same opinion. I'm not quite sure I understand the reasoning behind it. Is it the added complexity or something else? While it's super to have a fast kernel interface, the inherent latency and allocation granularity will probably always make a user-space sub-allocator a desirable thing. Particularly something like a slab allocator that would also to some extent avoid fragmentation. My view of TTM has changed to be a bit from the opposite side: Let's say we have a fast user-space per-client allocator. What kernel functionality would we require to make sure that it can assume it's the sole owner of the memory it manages? We have slightly different use-cases, I'm probably more targetting 3d desktop uses where sharing buffers is more important (think pixmaps etc) so making the allocator go as fast as possible make sense for this case as we need to have it in the kernel to do the sharing ... For a repeated usage pattern like batch-buffers we end up allocating pages from the kernel, setting up one VMA per buffer, modifying gart- and page tables and in the worst case even caching policy for each and every use. Even if this can be made reasonably fast, I think it's a CPU overhead we really shouldn't be paying?? Or we end up allocating a large amount of space to store on-the-fly buffers, which requires more tuning per application, some apps may not need 65k of batchbuffer space etc.. So while I see the need for suballocators (we need one for glyphs and small pixmaps on 2D side in any case) I also see the need to make things faster for the non-sub-allocated use case... So I don't think the goals of 3D driver vs 3D desktop are mutually exclusive, I think your work has fone too far towards the single app case and our work is trying to pull it back towards our use case.. Dave. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gtkradiant not working with radeon driver
On Mon, 29 Oct 2007 22:50:06 +0100
Roland Scheidegger [EMAIL PROTECTED] wrote:
Also, could you provide a backtrace
from gdb? What are the max_index and min_index values?
Er...not sure, there are a couple of values for each. Take a look
below, please.
On Tue, 30 Oct 2007 08:05:00 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Tue, 2007-10-30 at 02:33 +, Jose Rodriguez wrote:
I´m not sure what do you mean by ddx [...]
The X driver. For 3D, usually only the Mesa driver is relevant.
Oh, I didn't know. Libgl1-mesa-dri version is 7.0.1-2.
I installed the xserver-xorg-video-ati-dbg and libc6-dbg
packages [...]
You need to install libgl1-mesa-dri-dbg or build from mesa Git.
Thanks a lot, installing that package made a
change. This is what I get now:
This GDB was configured as i486-linux-gnu...
setUsing host libthread_db library /lib/libthread_db.so.1.
(gdb) set pagination 0
(gdb) run
Starting
program: /home/jcarlos/software/other/GtkRadiant_old/install/radiant.x8
6 Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 0xb718c6c0 (LWP 5135)]
radiant.x86: vbo/vbo_split_inplace.c:97: flush_vertex: Assertion
`max_index = m in_index' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb718c6c0 (LWP 5135)]
0xb741b7d6 in raise () from /lib/libc.so.6
(gdb) thread apply all bt full
Thread 1 (Thread 0xb718c6c0 (LWP 5135)):
#0 0xb741b7d6 in raise () from /lib/libc.so.6
No symbol table info available.
#1 0xb741d0f1 in abort () from /lib/libc.so.6
No symbol table info available.
#2 0xb7414b50 in __assert_fail () from /lib/libc.so.6
No symbol table info available.
#3 0xb6a745b1 in flush_vertex (split=0xbf974840) at
#vbo/vbo_split_inplace.c:97
min_index = 0
max_index = 5135
__PRETTY_FUNCTION__ = flush_vertex
#4 0xb6a74a3e in vbo_split_inplace (ctx=0x8ac8518,
#arrays=0x8b11dd8, prim=0xbf9
74ba0, nr_prims=1, ib=0x0, min_index=0, max_index=4294967295,
draw=0xb69c9970 _ tnl_draw_prims, limits=0xbf974ad8) at
vbo/vbo_split_inplace.c:255 split = {ctx = 0x8ac8518, array =
0x8b11dd8, prim = 0xbf974ba0, nr_prims = 1, ib = 0x0, min_index =
0, max_index = 4294967295, draw = 0xb69c9970 _tnl_d raw_prims,
limits = 0xbf974ad8, dstprim = {{mode = 6, indexed = 0, begin = 1,
e nd = 1, weak = 0, pad = 0, start = 0, count = 0}, {mode = 0,
indexed = 0, begin = 0, end = 0, weak = 0, pad = 0, start = 0,
count = 0} repeats 31 times}, dstp rim_nr = 1}
#5 0xb69c9ad9 in _tnl_draw_prims (ctx=0x8ac8518,
#arrays=0x8b11dd8, prim=0xbf974
ba0, nr_prims=1, ib=0x0, min_index=0, max_index=4294967295) at
tnl/t_draw.c:384 limits = {max_verts = 3000, max_indices =
4294967295, max_vb_size = 4294 967295}
tnl = (TNLcontext *) 0x8b23688
#6 0xb69c2ce5 in vbo_exec_DrawArrays (mode=6, start=0, count=0)
#at vbo/vbo_exec
_array.c:259
ctx = value optimized out
prim = {{mode = 6, indexed = 0, begin = 1, end = 1, weak =
0, pad = 0, s tart = 0, count = 0}}
#7 0x081c3026 in RenderablePatchWireframe::render
#(this=0x996ccb0, state=128) a
t radiant/patch.h:221
n = 0
#8 0x081f78a1 in Renderables_flush ([EMAIL PROTECTED],
[EMAIL PROTECTED]
, globalstate=65675, [EMAIL PROTECTED]) at
radiant/renderstate.cpp:2183 i = {_M_current = 0xa486cbc}
transform = (const Matrix4 *) 0x9d1ac68
#9 0x081f7b23 in OpenGLStateBucket::render (this=0x892cf50,
[EMAIL PROTECTED]
, globalstate=65675, [EMAIL PROTECTED]) at
radiant/renderstate.cpp:2220 No locals.
#10 0x08204e56 in OpenGLShaderCache::render (this=0x8447138,
#globalstate=65675,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED])
at radiant/rend erstate.cpp:1427
i = {_M_node = 0x892cff8}
current = {m_state = 128, m_sort = 0, m_texture = 0,
m_texture1 = 0, m_t exture2 = 0, m_texture3 = 0, m_texture4 = 0,
m_texture5 = 0, m_texture6 = 0, m_t exture7 = 0, m_colour =
{m_elements = {1, 1, 1, 1}}, m_blend_src = 770, m_blend_ dst =
771, m_depthfunc = 513, m_alphafunc = 519, m_alpharef = 0,
m_linewidth = 1 , m_pointsize = 1, m_linestipple_factor = 1,
m_linestipple_pattern = 43690, m_fo g = {mode = 2048, density = 0,
start = 0, end = 0, index = 0, colour = {m_elemen ts = {1, 1, 1,
1}}}, m_program = 0x0} pattern =
U
UUU
\000\000\000
#11 0x08270bba in XYRenderer::render (this=0xbf974fa8,
[EMAIL PROTECTED], pro
[EMAIL PROTECTED]) at radiant/xywindow.cpp:2128
No locals.
#12 0x08268bf3 in XYWnd::XY_Draw (this=0x858ff30) at
#radiant/xywindow.cpp:2286
renderer = {Renderer = {_vptr.Renderer = 0x82aa528},
m_state_stack =
{
std::_Vector_baseXYRenderer::state_type,std::allocatorXYRenderer::state_type
= {_M_impl = {std::allocatorXYRenderer::state_type =
{__gnu_cxx::new_al locatorXYRenderer::state_type = {No
data fields}, No data fields}, _M_sta
rt = 0xa211228, _M_finish = 0xa211230, _M_end_of_storage =
0xa211248}}, No data
Re: intel hw and caching interface to TTM..
Dave Airlie wrote: OK. We're using this functionality in Poulsbo, so we should probably sort this out to avoid breaking things. Okay I'll try and fix it back up tomorrow.. Yes, Eric seems to have the same opinion. I'm not quite sure I understand the reasoning behind it. Is it the added complexity or something else? While it's super to have a fast kernel interface, the inherent latency and allocation granularity will probably always make a user-space sub-allocator a desirable thing. Particularly something like a slab allocator that would also to some extent avoid fragmentation. My view of TTM has changed to be a bit from the opposite side: Let's say we have a fast user-space per-client allocator. What kernel functionality would we require to make sure that it can assume it's the sole owner of the memory it manages? We have slightly different use-cases, I'm probably more targetting 3d desktop uses where sharing buffers is more important (think pixmaps etc) so making the allocator go as fast as possible make sense for this case as we need to have it in the kernel to do the sharing ... Agreed. For a repeated usage pattern like batch-buffers we end up allocating pages from the kernel, setting up one VMA per buffer, modifying gart- and page tables and in the worst case even caching policy for each and every use. Even if this can be made reasonably fast, I think it's a CPU overhead we really shouldn't be paying?? Or we end up allocating a large amount of space to store on-the-fly buffers, which requires more tuning per application, some apps may not need 65k of batchbuffer space etc.. So while I see the need for suballocators (we need one for glyphs and small pixmaps on 2D side in any case) I also see the need to make things faster for the non-sub-allocated use case... So I don't think the goals of 3D driver vs 3D desktop are mutually exclusive, I think your work has fone too far towards the single app case and our work is trying to pull it back towards our use case.. Indeed. There are certainly different use-cases. In some cases a sub-allocator is beneficial and in some cases we gain more by not using them. I had a concern that they would be considered generally useless and that the needed kernel support would go away. /Thomas Dave. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12795] since Merge remote branch 'origin/master' into buffer-objects driver don't work
http://bugs.freedesktop.org/show_bug.cgi?id=12795 --- Comment #2 from [EMAIL PROTECTED] 2007-10-30 06:01 PST --- Is there any relation to bug #5714? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gtkradiant not working with radeon driver
Jose Rodriguez wrote:
On Mon, 29 Oct 2007 22:50:06 +0100
Roland Scheidegger [EMAIL PROTECTED] wrote:
Also, could you provide a backtrace
from gdb? What are the max_index and min_index values?
Er...not sure, there are a couple of values for each. Take a look
below, please.
#5 0xb69c9ad9 in _tnl_draw_prims (ctx=0x8ac8518,
#arrays=0x8b11dd8, prim=0xbf974
ba0, nr_prims=1, ib=0x0, min_index=0, max_index=4294967295) at
tnl/t_draw.c:384 limits = {max_verts = 3000, max_indices =
4294967295, max_vb_size = 4294 967295}
tnl = (TNLcontext *) 0x8b23688
#6 0xb69c2ce5 in vbo_exec_DrawArrays (mode=6, start=0, count=0)
#at vbo/vbo_exec
_array.c:259
ctx = value optimized out
prim = {{mode = 6, indexed = 0, begin = 1, end = 1, weak =
0, pad = 0, s tart = 0, count = 0}}
#7 0x081c3026 in RenderablePatchWireframe::render
#(this=0x996ccb0, state=128) a
t radiant/patch.h:221
n = 0
Hmm, so max_index is -1. Apparently gtkradiant has called drawArrays
with a count of 0 (which is legal though pretty much a no-op), it seems
we don't handle that correctly. (calculating start + count - 1 is a
problem there...). I'd guess the solution for that is checking for count
== 0 and returning early in vbo_exec_DrawArrays in this case. Maybe the
same problem can be found in other places, haven't really looked at it
(e.g. the drawelements functions).
Roland
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12795] since Merge remote branch 'origin/master' into buffer-objects driver don't work
http://bugs.freedesktop.org/show_bug.cgi?id=12795 --- Comment #3 from [EMAIL PROTECTED] 2007-10-30 07:24 PST --- (In reply to comment #2) Is there any relation to bug #5714? I don't know, may be in this bug , this merge require xorg-server = 1.4 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12877] Textures(?) in WoW breaking up until X-server is restarted
http://bugs.freedesktop.org/show_bug.cgi?id=12877 --- Comment #8 from [EMAIL PROTECTED] 2007-10-30 14:34 PST --- (In reply to comment #5) If this is a new issue you could try figuring out which commit caused it with git-bisect. I'm not sure that this is Mesa's fault because I've just compiled Mesa 7.0.1 and rebooted, and the same problem has started again! Could there be something in the DRM module causing this? That might at least explain how the problem can affect celestia after Warcraft. I am running Linux 2.6.23.1: [drm] Initialized drm 1.1.0 20060810 [drm] Initialized radeon 1.28.0 20060524 on minor 0 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13012] New: unresolved symbol __driCreateNewScreen_20050727
http://bugs.freedesktop.org/show_bug.cgi?id=13012
Summary: unresolved symbol __driCreateNewScreen_20050727
Product: Mesa
Version: CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Drivers/DRI/i915
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
Using Mesa from git commit d2f19a554a9089fddb5e978e3a732bbf71d77f93 X.Org 7.3
from openSUSE BuildService, drm from git commit
79744d730c90019edd367eee4a8ec1fa22d53402 and kernel 2.6.23.1 (with or without
drm modules from git) AIGLX cannot start and gives the following error message:
(EE) AIGLX error: dlsym for __driCreateNewScreen_20050727 failed
(/usr/lib/dri/i915_dri.so: undefined symbol: __driCreateNewScreen_20050727)
(EE) AIGLX: reverting to software rendering
In the MESA GIT tree I found that the links in
src/mesa/drivers/dri/i9{1,6}5/server/ are not correct (one level missing). This
concerns intel_dri.c, and three other files in the 965 directory. But changing
these links did not change anything.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13012] unresolved symbol __driCreateNewScreen_20050727
http://bugs.freedesktop.org/show_bug.cgi?id=13012 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #1 from [EMAIL PROTECTED] 2007-10-30 15:52 PST --- It's not loading because the module versions are incompatible. You need to build X from git master to use Mesa from git master. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13012] unresolved symbol __driCreateNewScreen_20050727
http://bugs.freedesktop.org/show_bug.cgi?id=13012 --- Comment #2 from [EMAIL PROTECTED] 2007-10-30 19:17 PST --- (In reply to comment #1) It's not loading because the module versions are incompatible. You need to build X from git master to use Mesa from git master. Hi one question is not the opposite ? You need to build Mesa from git master to build X from git master. I don't had time to test it, but with xorg-server 1.4 I will try use mega git master , like , we do normally , DRI development normally is based on a X server stable . the opposite is not true (I think) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
