[r300] nasty bug found
Hi. I noticed that Vladimirs adition to struct r300_state caused arbvptorus to get broken pretty badly. This is pretty much similar to the bug where vb mode color buffer clears were broken. Iv been trying to figure out this for a while now with no success and I was thinking if anyone else would like to give it a shot. I traced its causer down the structures to struct r300_dma before struct r300_dma_region current;. This doesnt exactly mean that its in dma code but at least its a start. Unfortunately i havent found anything useful in compiler warnings and im currectly lacking ideas of how to find it... -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found
Aapo Tahkola wrote: Hi. I noticed that Vladimirs adition to struct r300_state caused arbvptorus to get broken pretty badly. This is pretty much similar to the bug where vb mode color buffer clears were broken. Iv been trying to figure out this for a while now with no success and I was thinking if anyone else would like to give it a shot. I traced its causer down the structures to struct r300_dma before struct r300_dma_region current;. This doesnt exactly mean that its in dma code but at least its a start. Unfortunately i havent found anything useful in compiler warnings and im currectly lacking ideas of how to find it... I would like to give it a try, but I need a simple program that triggers it. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found
> Aapo Tahkola wrote: >> Hi. >> >> I noticed that Vladimirs adition to struct r300_state caused arbvptorus >> to >> get broken pretty badly. This is pretty much similar to the bug where vb >> mode color buffer clears were broken. >> Iv been trying to figure out this for a while now with no success and I >> was thinking if anyone else would like to give it a shot. >> I traced its causer down the structures to struct r300_dma before struct >> r300_dma_region current;. This doesnt exactly mean that its in dma code >> but at least its a start. >> >> Unfortunately i havent found anything useful in compiler warnings and im >> currectly lacking ideas of how to find it... >> > I would like to give it a try, but I need a simple program that triggers > it. Mesa/progs/tests/arbvptorus.c is pretty much as simple as it can get. You could comment instructions after the first four DP4s and calls to glProgramLocalParameter4fARB later. Its pretty strange that when removing usage of vertex program from the example these problems go away. I didnt test with per-vertex colors though. By replacing "glutSolidTorus(0.75, 2.0, 10, 20)" with a "glutSolidTeapot(4);" you should see some errors when resizing the window. I think this is a pretty good sign in sense that fixing this might actually affect general stability of vb mode. (i had similar issues and lockups when trying to make fire_EB work) You can temporarily "fix" this by moving "int dummy;" in struct r300_dma below current as said in comments. > > > Rune Petersen -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found
On Thu, 24 Feb 2005, Aapo Tahkola wrote: Hi. I noticed that Vladimirs adition to struct r300_state caused arbvptorus to get broken pretty badly. This is pretty much similar to the bug where vb mode color buffer clears were broken. Iv been trying to figure out this for a while now with no success and I was thinking if anyone else would like to give it a shot. I traced its causer down the structures to struct r300_dma before struct r300_dma_region current;. This doesnt exactly mean that its in dma code but at least its a start. Unfortunately i havent found anything useful in compiler warnings and im currectly lacking ideas of how to find it... Does the bug still show up with immediate mode ? I had some success running 3d apps under valgrind before. best Vladimir Dergachev -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found
> > > On Thu, 24 Feb 2005, Aapo Tahkola wrote: > >> Hi. >> >> I noticed that Vladimirs adition to struct r300_state caused arbvptorus >> to >> get broken pretty badly. This is pretty much similar to the bug where vb >> mode color buffer clears were broken. >> Iv been trying to figure out this for a while now with no success and I >> was thinking if anyone else would like to give it a shot. >> I traced its causer down the structures to struct r300_dma before struct >> r300_dma_region current;. This doesnt exactly mean that its in dma code >> but at least its a start. >> >> Unfortunately i havent found anything useful in compiler warnings and im >> currectly lacking ideas of how to find it... > > Does the bug still show up with immediate mode ? I had some success > running 3d apps under valgrind before. This bug *completely* disappeared after I builded xorg 6.8.2 and fetched programs/Xserver/hw/xfree86/drivers/ati and programs/Xserver/hw/xfree86/drivers/i2c from cvs on top of it today. After doing that I had some oddish issues with glxgears giving only ~20fps (yes I know it was accelerated as I saw those little white lines and debug info). After rebuilding kernel with profiling support in attempts to find it, it was gone(frames boosted up too). I tried to make it appear again by reinstalling 6.8.1(with very old ddx patch) and by rebuilding without profiling with no success. I have six different compiler versions and I often swap between em to get program x to compile. So I suppose compiling kernel and drm with different gcc versions could of been the problem.. > >best > >Vladimir Dergachev > >> >> -- >> Aapo Tahkola -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] nasty bug found and fixed
Ok. I said that this bug doesnt exist and it was just my problem ... I changed my mind as it appeared again after rebuilding just about everything and tracked it down after long battle. This was caused by missing curly braces around texcoord VAP input configuration and resulted in all 8 texture units to be configured whenever vertex programs were used. However there is one thing I dont understand about this: How did badly configuring VAP input caused vertex programs to get broken when dummy var was added into struct r300_dma or struct r300_state ? AFAIK, even if textures would be enabled for no reason there should be enough checks in r300_setup_textures and other places not to cause bad pointers to read from there. There was a bug that could of caused this: #define ALLOC_STATE( ATOM, CHK, SZ, NM, IDX ) \ ... r300->hw.ATOM.cmd = (uint32_t*)CALLOC(SZ * sizeof(uint32_t)); \ ... caller: ALLOC_STATE( tex.filter, variable, mtu+1, "tex_filter", 0 ); result: r300->hw.ATOM.cmd = (uint32_t*)CALLOC(mtu+1 * sizeof(uint32_t)); \ This have been fixed some time ago though. Further more I modified verify_r300ResetHwState earlier to test that each state atom can actually hold all data its ment to hold, so these type of bugs should be gone. Could it be because R300_MAX_AOS_ARRAYS is only 8 whereas 9 would of needed ? Im not sure if trying to figure this out like this is worth the effort though as we can probably figure out any outstanding problems with textures by writing test programs. Some shots: http://nu.rasterburn.org/~aet/arbvptorus_1.png http://nu.rasterburn.org/~aet/arbvptorus_2.png -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found and fixed
Hi, Nice catch! Aapo Tahkola wrote: Ok. I said that this bug doesnt exist and it was just my problem ... I changed my mind as it appeared again after rebuilding just about everything and tracked it down after long battle. This was caused by missing curly braces around texcoord VAP input configuration and resulted in all 8 texture units to be configured whenever vertex programs were used. However there is one thing I dont understand about this: How did badly configuring VAP input caused vertex programs to get broken when dummy var was added into struct r300_dma or struct r300_state ? I think the dummy only worked for you. It didn't help me. this also fixed software fallback for me. just to be sure: when you run arbvptorus (unmodified) do you get the texobj=NULL warning? Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found and fixed
> Aapo Tahkola wrote:
>> Ok. I said that this bug doesnt exist and it was just my problem ...
>> I changed my mind as it appeared again after rebuilding just about
>> everything and tracked it down after long battle. This was caused by
>> missing curly braces around texcoord VAP input configuration and
>> resulted
>> in all 8 texture units to be configured whenever vertex programs were
>> used.
>>
>> However there is one thing I dont understand about this:
>> How did badly configuring VAP input caused vertex programs to get broken
>> when dummy var was added into struct r300_dma or struct r300_state ?
>
> I think the dummy only worked for you. It didn't help me.
> this also fixed software fallback for me.
>
> just to be sure:
> when you run arbvptorus (unmodified) do you get the texobj=NULL warning?
They dont show up today and they arent in yesterdays logs.
Not even "Mismatch between"-warn.
I must say that iv removed last instruction("MOV result.texcoord,
vertex.texcoord;\n") from arbvptorus.c long time ago from my local version
as it shouldnt be there.
Here are the logs done by tweaking arbvptorus to draw only 30 frames:
http://nu.rasterburn.org/~aet/log.14 (broken)
http://nu.rasterburn.org/~aet/log.15 (working)
>
>
> Rune Petersen
>
--
Aapo Tahkola
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found and fixed
Aapo Tahkola wrote:
Aapo Tahkola wrote:
I think the dummy only worked for you. It didn't help me.
this also fixed software fallback for me.
just to be sure:
when you run arbvptorus (unmodified) do you get the texobj=NULL warning?
They dont show up today and they arent in yesterdays logs.
Not even "Mismatch between"-warn.
I must say that iv removed last instruction("MOV result.texcoord,
vertex.texcoord;\n") from arbvptorus.c long time ago from my local version
as it shouldnt be there.
Here are the logs done by tweaking arbvptorus to draw only 30 frames:
http://nu.rasterburn.org/~aet/log.14 (broken)
http://nu.rasterburn.org/~aet/log.15 (working)
Bad news:
That extra instruction causes texobj=NULL and therefore texture corruption.
Rune Petersen
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] nasty bug found and fixed
> > Bad news: > That extra instruction causes texobj=NULL and therefore texture > corruption. Looks like it indeed. This is caused by incorrectly enabling texture units based on inputs. Something like if(ctx->Texture.Unit[i].Enabled == 0) continue; in r300_setup_textures fixes it but performance loss is pretty great. I think this is because maos code fills dma regions with bad data as it never actually checks that user passed texcoords. AFAIK cases where program didnt pass vertex elements but vertex programs input wants it should either be left uncofigured or filled with default vector with no walk. Anyhow this is still a bit open as mesa doesnt configure render inputs based on vertex programs(my opinion is that it shouldnt either) and that too many test programs arent available. > > > Rune Petersen > -- Aapo Tahkola --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
