Re: [Mesa3d-dev] a nits in intel/radeon 3D driver
Michel Dänzer 写道:
> On Wed, 2007-12-26 at 08:00 +0800, minskey guo wrote:
>
>> Hi, guys,
>>
>> In intelWaitIrq() of intel_ioctl.c file, there is the following
>> code:
>>
>> void intelWaitIrq( intelContextPtr intel, int seq )
>> {
>> ...
>> do {
>> ret = drmCommandWrite( intel->driFd, DRM_I830_IRQ_WAIT, &intel->iw,
>> sizeof(intel->iw) );
>> } while (ret == -EAGAIN || ret == -EINTR);
>> ...
>> }
>>
>>
>> But the kernel i915 DRM driver doesn't return EAGAIN for
>> ioctl DRM_I830_IRQ_WAIT. Refer to i915_wait_irq() in file
>> i915_irq.c and DRM_WAIT_ON macro in drm_os_linux.h
>>
>> >From the macro of DRM_WAIT_ON, I think i915_wait_irq()/
>> ioctl DRM_I830_IRQ_WAIT can get return value of -EBUYS
>> or -EINTR only, no -EAGAIN.
>>
>>
>> So, I guess that the checking for -EAGAIN should be replaced
>> with the checking for -EBUSY in intelWaitIrq() of intel_ioctl.c,
>> Is my understanding right ?
>>
>
> No. The ioctl will only return -EBUSY after a 3 second timeout, which
> usually means the GPU has locked up, and retrying is pointless.
>
>
Generally, in my understanding, if GPU gets lock, there must be
something wrong, software or hardware. If it is software flaw,
we could improve it. If hardware flaw, maybe we could reset the
GPU. From ATI while paper, ATI radeon driver for windows Vista
has a reset unit, which will reset the GPU if necessary.
Is there any better ways to solve this issue ? If we are using
3D desktop, the whole desktop will exit when EBUSY is encountered,
it is difficult for end users to accept this.
thanks,
-minskey
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 13310] separate stencil implemented incorrect if the the primitive is BACK_FACE
http://bugs.freedesktop.org/show_bug.cgi?id=13310 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|mesa3d- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- 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. You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11893] can not get point parameters when use soft rendering
http://bugs.freedesktop.org/show_bug.cgi?id=11893 [EMAIL PROTECTED] changed: What|Removed |Added Priority|medium |low -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11877] texture_srgb glGetTexImage failed for internalFormat GL_SRGB_EXT
http://bugs.freedesktop.org/show_bug.cgi?id=11877 [EMAIL PROTECTED] changed: What|Removed |Added Component|Drivers/DRI/i965|Mesa core -- 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. You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11827] point applied incorrect texture when point_sprite enabled
http://bugs.freedesktop.org/show_bug.cgi?id=11827 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|mesa3d- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- 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. You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11541] [wine] Americas Army wine (intel driver) bug
http://bugs.freedesktop.org/show_bug.cgi?id=11541 [EMAIL PROTECTED] changed: What|Removed |Added Priority|medium |low Summary|Americas Army wine (intel |[wine] Americas Army wine |driver) bug |(intel driver) bug -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11050] Y coordinate should be round down when draw points
http://bugs.freedesktop.org/show_bug.cgi?id=11050 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #2 from [EMAIL PROTECTED] 2008-01-03 23:04 PST --- update status. -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 10999] GL_EXT_paletted_texture is not support without 3D driver
http://bugs.freedesktop.org/show_bug.cgi?id=10999 [EMAIL PROTECTED] changed: What|Removed |Added Priority|medium |low -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 10987] vector_program implement wrong when calculate state.light.half
http://bugs.freedesktop.org/show_bug.cgi?id=10987 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|mesa3d- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- 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. You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 10984] wrong error state returned by Occlusion query APIs
http://bugs.freedesktop.org/show_bug.cgi?id=10984 [EMAIL PROTECTED] changed: What|Removed |Added Priority|medium |low -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 10972] Wrong processing of unsigned color value
http://bugs.freedesktop.org/show_bug.cgi?id=10972 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|mesa3d- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- 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. You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Vertex processing in Gallium
Brian Paul wrote: > On 1/3/08, Ian Romanick <[EMAIL PROTECTED]> wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Since it looks like the TG folks are knee-deep in the fragment shading >> side of things, I'm going to start tackling the vertex processing. I'm >> looking at the vertex processing code in Gallium, and I honestly can't >> make heads or tails of it. I grok some of the individual bits, but the >> bigger picture escapes me. > > Don't feel bad, it's not exactly simple stuff. > > >> Could someone give me an overview of what happens when an app calls >> glDrawElements, for example? > > glDrawElements basically maps to the pipe->draw_elements() method. > Before it's called though, the state tracker code needs to tell the > gallium context two things: > > 1. The vertex format (which attributes, number of components and > datatypes). This is described with the pipe_vertex_element type and > calls to pipe->set_vertex_element(). > > 2. The location of the vertex arrays in memory (in buffer objects). > The Mesa vbo module puts the array data into VBOs and the state > tracker tells the gallium context about the buffers with the > pipe_vertex_buffer type and calls to pipe->set_vertex_buffer(). > > > When pipe->draw_elements() is called that dispatches into the device > driver. If you have full TnL hardware, you'll basically use the > vertex format/buffer info to program the hardware and let it rip. > > For non-TnL hardware, the 'pipe/draw/' utility module comes into play. > It does sw-based vertex transformation, primitive assembly, clipping, > etc. emitting screen-coord points/lines/triangles at the end. > > The draw module transforms 4 vertices at a time (like we do "quads" of > fragments) to allow SOA (or AOS) processing. > > There's also a vertex cache/buffer (32 verts, I think) and primitive > (point/line/tri) cache for efficient primitive assembly, etc. > > When the prim cache (or vertex cache) is full, we begin rendering a > batch of primitives (points/lines/tris) by passing them through the > "prim pipeline" which is a sequence of stages like clipping, > front-back face determination, culling, glPolygonMode, > glPolygonOffset, etc. The last stage of this pipeline (which actually > renders the prim) is not in the 'draw' module. It's provided by the > device driver (see sp_prim_setup.c or cell_render.c, for example). > > Does that help? Maybe I should put this into a comment... > Better still, put it into the wiki... Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 10960] Wrong color for vertex array
http://bugs.freedesktop.org/show_bug.cgi?id=10960 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 9151] fragment.position does not include y coord in fragment programs
http://bugs.freedesktop.org/show_bug.cgi?id=9151 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|ASSIGNED|NEW -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11580] depth test not pass if no depth buffer
http://bugs.freedesktop.org/show_bug.cgi?id=11580 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|mesa3d- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | -- 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. You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Vertex processing in Gallium
On 1/3/08, Ian Romanick <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Since it looks like the TG folks are knee-deep in the fragment shading > side of things, I'm going to start tackling the vertex processing. I'm > looking at the vertex processing code in Gallium, and I honestly can't > make heads or tails of it. I grok some of the individual bits, but the > bigger picture escapes me. Don't feel bad, it's not exactly simple stuff. > Could someone give me an overview of what happens when an app calls > glDrawElements, for example? glDrawElements basically maps to the pipe->draw_elements() method. Before it's called though, the state tracker code needs to tell the gallium context two things: 1. The vertex format (which attributes, number of components and datatypes). This is described with the pipe_vertex_element type and calls to pipe->set_vertex_element(). 2. The location of the vertex arrays in memory (in buffer objects). The Mesa vbo module puts the array data into VBOs and the state tracker tells the gallium context about the buffers with the pipe_vertex_buffer type and calls to pipe->set_vertex_buffer(). When pipe->draw_elements() is called that dispatches into the device driver. If you have full TnL hardware, you'll basically use the vertex format/buffer info to program the hardware and let it rip. For non-TnL hardware, the 'pipe/draw/' utility module comes into play. It does sw-based vertex transformation, primitive assembly, clipping, etc. emitting screen-coord points/lines/triangles at the end. The draw module transforms 4 vertices at a time (like we do "quads" of fragments) to allow SOA (or AOS) processing. There's also a vertex cache/buffer (32 verts, I think) and primitive (point/line/tri) cache for efficient primitive assembly, etc. When the prim cache (or vertex cache) is full, we begin rendering a batch of primitives (points/lines/tris) by passing them through the "prim pipeline" which is a sequence of stages like clipping, front-back face determination, culling, glPolygonMode, glPolygonOffset, etc. The last stage of this pipeline (which actually renders the prim) is not in the 'draw' module. It's provided by the device driver (see sp_prim_setup.c or cell_render.c, for example). Does that help? Maybe I should put this into a comment... -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Vertex processing in Gallium
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since it looks like the TG folks are knee-deep in the fragment shading side of things, I'm going to start tackling the vertex processing. I'm looking at the vertex processing code in Gallium, and I honestly can't make heads or tails of it. I grok some of the individual bits, but the bigger picture escapes me. Could someone give me an overview of what happens when an app calls glDrawElements, for example? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHfXxaX1gOwKyEAw8RAlSlAJwO8stl1xCBMeerZJijF0iO4Lqh9ACfSuRT NJ1MrQd4Uklbr1Ho95fDHAI= =giPB -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 9681] rendering errors on unichrome
http://bugs.freedesktop.org/show_bug.cgi?id=9681 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium softpipe TGSI_OPCODE_END
On Thursday 03 January 2008 11:15:28 am Jerome Glisse wrote: > Hi Brian, > > I believe you did break softpipe with your change from TGSI_OPCODE_RET > to TGSI_OPCODE_END (commit: 1575763a6f57d1f13c707b709f188b0617c8955a) > pipe/tgsi/exec/tgsi_sse2.c assert on unknown instruction for this opcode. > If i add TGSI_OPCODE_END to do as TGSI_OPCODE_RET i don't get assertion > anymore but rendering is bit broken red & green color are wrong (tested > with glxgears). So maybe is not the proper fix as i am not yet familiar > with gallium. Anythough on that ? nah, the fix is correct. we want the programs always ending with an end. there's a big semantic difference between end and ret from the perspective of the driver. it's just that the sse code is currently behind and is lacking quite a few things. i'd suggest exporting GALLIUM_NOSSE for now. z - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Issues with Gallium on Cell
On Jan 3, 2008 1:08 AM, Brian Paul <[EMAIL PROTECTED]> wrote: > Is it possible the SPU code is getting compiled for 64-bits? The ppu > code gets compiled with -m32 but spu-gcc doesn't seem to like that flag. > I don't see another option for specifying 32 vs. 64-bit. > > Try running 'file' on the spu .o files. Here, I get: > > pipe/cell/spu/g3d_spu-embed.o: ELF 32-bit MSB relocatable, PowerPC or > cisco 4500, version 1 (SYSV), not stripped > pipe/cell/spu/main.o: ELF 32-bit MSB relocatable, version 1 > (SYSV), not stripped > pipe/cell/spu/tri.o: ELF 32-bit MSB relocatable, version 1 > (SYSV), not stripped I am suddenly wondering whether SPU 64 bit code exists. The SPU ABI seems to say no (cf. http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/02E544E65760B0BF87257060006F8F20/$file/SPU_ABI-Specification_1.8.pdf). So the problem might be that the pointer parameters passed to the SPU from the PPU are either 32 or 64 bit (for instance argp passed to SPU's main). It's been too long since I played with the PS3 and have things mixed up... Laurent - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium softpipe TGSI_OPCODE_END
Hi Brian, I believe you did break softpipe with your change from TGSI_OPCODE_RET to TGSI_OPCODE_END (commit: 1575763a6f57d1f13c707b709f188b0617c8955a) pipe/tgsi/exec/tgsi_sse2.c assert on unknown instruction for this opcode. If i add TGSI_OPCODE_END to do as TGSI_OPCODE_RET i don't get assertion anymore but rendering is bit broken red & green color are wrong (tested with glxgears). So maybe is not the proper fix as i am not yet familiar with gallium. Anythough on that ? Cheers, Jerome Glisse <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11174] Regression (missing / black vertices) between 6.4.2 and 6.5.1 (with trackballs)
http://bugs.freedesktop.org/show_bug.cgi?id=11174 --- Comment #13 from [EMAIL PROTECTED] 2008-01-03 07:52 PST --- Created an attachment (id=13489) --> (http://bugs.freedesktop.org/attachment.cgi?id=13489&action=view) PATCH: fix black rendered vertices with trackballs And as promised a patch against trackballs "fixing"? the problem. -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11174] Regression (missing / black vertices) between 6.4.2 and 6.5.1 (with trackballs)
http://bugs.freedesktop.org/show_bug.cgi?id=11174 --- Comment #12 from [EMAIL PROTECTED] 2008-01-03 07:51 PST --- Created an attachment (id=13488) --> (http://bugs.freedesktop.org/attachment.cgi?id=13488&action=view) PATCH: fix a regression between 6.5 and 6.5.1 where some vertices in trackballs went black Note this is the fix (revert of a commit) for the regression between 6.5 and 6.5.1 ported to 7.0.2. Even though this does not fix the issue with 7.0.2 I still believe this should be applied as the removed code is an old ugly hack to fix bug 6991 (according to the log of the commit this reverts). I'm not intimate enough with any of the mesa code to make this assessment for sure though. Note that the removed code is the last user of the dummy_attrib and temp_attrib context members, so those can be removed too if this gets removed. I tried ppracer with this patch and it still works fine, so the removed code isn't necessary anymore for bug 6991 atleast. -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 11174] Regression (missing / black vertices) between 6.4.2 and 6.5.1 (with trackballs)
http://bugs.freedesktop.org/show_bug.cgi?id=11174 --- Comment #11 from [EMAIL PROTECTED] 2008-01-03 07:33 PST --- Okay, I've bitten the bullet and spend an entire day git bisecting this. Actually there are 2 regression moments where the trackballs has black vertices problem get introduced, the first one between 6.5.0 and 6.5.1, I've managed to find this with git-bisect and made a patch which fixes 6.5.1, then there is another regression between 6.5.1 (with attached fix) and current master. bisecting this led me too the vbo merger, after which all I got where either crashing or non building revisions. Today I've spend an hour or so trying to fix this by looking at how trackballs does this, this has lead to a patch to trackballs which fixes (or workarounds?) this. I'm not sure if trackballs is to blame though, as it works fine with intel cards (7.0.2) and with the software renderer. I'll also attach that patch, perhaps it sheds some light on this. -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 12652] RV370 [FireGL V3100 (PCIE)] Xorg Crash with Option "DRI" "false"
http://bugs.freedesktop.org/show_bug.cgi?id=12652 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #11862|application/x-trash |text/plain mime type|| -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
