[Mesa3d-dev] [Bug 5785] larger textures sizes should be announced with DRI drivers
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5785 --- Additional Comments From [EMAIL PROTECTED] 2006-02-02 07:21 --- Also keep in mind that the size of the GART table may be limited so that you may not be able to map all physical memory into the GART. Basically the GART table size is determined at kernel/2D driver initialization time. I'm not sure if there are any physical hardware limitations to the GART table size (depending on the AGP chipset or PCI(e) SG implementation). -- Configure bugmail: https://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. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 5791] New: segfault when building vertex program with sse codegen
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5791 Summary: segfault when building vertex program with sse codegen Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] When trying to run quake4 with software vertex programs, I get a segfault, here's the backtrace: #0 0x00656e69 in ?? () #1 0x3cabee97 in build_vertex_program (cp=0xaf83e7c0) at tnl/t_vb_arbprogram_sse.c:1139 #2 0x3cabefbe in _tnl_sse_codegen_vertex_program (p=0x1152d850) at tnl/t_vb_arbprogram_sse.c:1201 #3 0x3cabc55f in compile_vertex_program (program=0x9efff38, try_codegen=115 's') at tnl/t_vb_arbprogram.c:1130 #4 0x3cabcbf0 in validate_vertex_program (ctx=0x9ac3140, stage=0x47) at tnl/t_vb_arbprogram.c:1420 #5 0x3cab5da1 in _tnl_run_pipeline (ctx=0x9ac3140) at tnl/t_pipeline.c:144 #6 0x3ca28b23 in r200WrapRunPipeline (ctx=0x9ac3140) at r200_state.c:2465 #7 0x3cb5743f in _tnl_draw_range_elements (ctx=0x9ac3140, mode=4, max_index=643, index_count=71, indices=0x47) at tnl/t_array_api.c:105 #8 0x3cb579ba in _tnl_DrawElements (mode=4, count=2964, type=5125, indices=0x282) at tnl/t_array_api.c:373 The corresponding DISASSEM output was this: 0x44cfe80a: DP4 OUT4, IN0, STATE_VAR:1 0x44cfe86c: DP4 RES, IN0, STATE_VAR:2 0x44cfe8bd: MSK OUT4.y, RES signal caught: Segmentation fault This happens with q4 demo and arb_vertex_program set to true (and texture_units set to 6 on a r200). It only happens if linux-dri-x86 target is used. The weird thing is, I get a pretty similar crash running the arbvptorus demo but only if I set MESA_EXPERIMENTAL. But in this case, MESA_EXPERIMENTAL is NOT set, and gdb tells me try_codegen is 114. So either there is an initialization issue or there was some memory corruption. And btw it looks like MESA_NO_SSE is not honored for this stuff (though since you're supposed to enable it manually at this stage that's probably not a problem). -- Configure bugmail: https://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. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 5785] larger textures sizes should be announced with DRI drivers
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5785 --- Additional Comments From [EMAIL PROTECTED] 2006-02-02 05:00 --- (In reply to comment #1) > With the new memory manager that Keith is writing, this won't be an issue. We > should always be able to map any texture into the GART, so the allocations > will > never fail. I'm not sure that this solves this completely. Or is it possible to map any ram to GART? The maximum size could get pretty big (for instance, on the r200, with cubemaps you'd need about 720MB to map everything in the worst case). -- Configure bugmail: https://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. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 5785] larger textures sizes should be announced with DRI drivers
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5785 --- Additional Comments From [EMAIL PROTECTED] 2006-02-02 04:07 --- The texture size limits advertised by all of the drivers is very conservative. This is an issue that has come up a few times before. There's a trade off. We can advertise the actual hardware limits or we can advertise the limits that we can guarantee will work. We're stuck with either having to fallback to software if an app tries to use too much texture memory at once or artificially limit the available texture sizes. This technique was introduced back in the Quake 2 days. There were some low-memory cards that could end up on a software path with Quake 2's default settings when the full texture sizes were advertised. With the new memory manager that Keith is writing, this won't be an issue. We should always be able to map any texture into the GART, so the allocations will never fail. In the mean time, it might be best to add a config option "Conservative Texture Limits" that defaults to on. -- Configure bugmail: https://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. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 5780] import of vertex arrays causes assertion failure
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5780 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-02-02 03:46 --- I checked in the fixed assertion. -- Configure bugmail: https://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. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 5780] import of vertex arrays causes assertion failure
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5780 --- Additional Comments From [EMAIL PROTECTED] 2006-02-02 03:14 --- Yes, on a 2nd look I thought that too. There is in fact the same assertion in import_texcoord, which seems the right place for that since there it really shouldn't get called when there are less texture units available. -- Configure bugmail: https://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. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 5785] New: larger textures sizes should be announced with DRI drivers
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5785 Summary: larger textures sizes should be announced with DRI drivers Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Mesa core AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] currently, driCalculateMaxTextureLevels will set the max texture sizes so that the textures always will fit into the texture heap(s). This means worst case, i.e. all texture units have a texture bound, with no texture compression, maximum width and height, maximum bit depth, and all mipmaps. It would probably be better to announce larger sizes (maybe hw max or at least something less strict, i.e. only 1 texture with otherwise worst-case needs to fit). For instance, on my r200 with 64MB (and some ddx hack so a bit less ram is wasted for 2d), max cube map size is 256. It turns out that quake4 absolutely needs cube maps with a size of 1024, otherwise the outdoor scenes (sky) will look pretty black (even with low quality, this is probably an app error, it fails to check the limits, it might be possible to tweak this via console, though I've yet to figure out how to get a console in the q4 demo...). And the actual ram quake4 needs for these cube maps isn't _that_ much, as they are compressed probably only around 9MB (haven't checked what dxt format) for all faces. -- Configure bugmail: https://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. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 5780] import of vertex arrays causes assertion failure
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=5780 --- Additional Comments From [EMAIL PROTECTED] 2006-02-02 02:23 --- My first inclination is to say the assertion should really be: ASSERT(unit < MAX_TEXTURE_COORD_UNITS); I know we check against ctx->Const.MaxTextureCoordUnits in a few other places so I don't think loosening the above assertion is too risky. -- Configure bugmail: https://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. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
