Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
I agree more documentation of the closed source API's would be nice.
On 9/3/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
There's already a MDLCACHE_CRITICAL_SECTION(); in C_BaseEntity::PostDataUpdate
that should take care of that one. Post a stack trace if you're certain you
haven't regressed that one.
At 2006/09/03 02:21 PM, Robbie Groenewoudt wrote:
--
[ Picked text/plain from multipart/alternative ]
My first crash with this:
void C_HL2MP_Player::Initialize( void )
{
m_headYawPoseParam = LookupPoseParameter( head_yaw );
GetPoseParameterRange( m_headYawPoseParam, m_headYawMin, m_headYawMax );
m_headPitchPoseParam = LookupPoseParameter( head_pitch );
GetPoseParameterRange( m_headPitchPoseParam, m_headPitchMin,
m_headPitchMax );
CStudioHdr *hdr = GetModelPtr();
for ( int i = 0; i hdr-GetNumPoseParameters() ; i++ )
On 9/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
New patch available:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#IsFrameLocking_assert
Since the scopes were moved higher, it's a little harder to say that the
patch is airtight. But it fixes everything trivially encountered by just
loading up HL2DM and moving around a bit.
At 2006/09/02 06:06 PM, [EMAIL PROTECTED] wrote:
Thanks, I'm going to assume this means that FrameLocking is an expensive
operation and would cause noticeable slow-down machines if done too
frequently. I haven't noticed any problems, but I'll develop another patch
with the locks up higher in the stack.
It sure would be nice to document this API, since modders can't read the
closed-source code.
So my comment in the wiki is correct though that all of those spots
represent potential crashers?
-bk
At 2006/09/02 05:40 PM, Jay Stelly wrote:
No, we just rely on virtual memory for that. This is for when you hit
the cache ceiling (which is usually 256MB depending on the physical ram
on the machine). Obviously on consoles it's lower given the usual
memory configurations there (which isn't relevant to any of you guys,
but is to us).
Also, I would definitely NOT recommend the code changes you posted on
the wiki. That will cause way too much overhead to protect against a
pointer dangling. The scope frames should be at a much higher level.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 12:17 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
So if the box is low on ram, the HL2 core will memory it's
not actively using right that moment? I think I now
understand what the issue is, although I'm confused by the
use of scope locking for something like this.
In any case I've added MDLCACHE_CRITICAL_SECTION per Jay's
instruction, and the result is several dozen fixes, added to
the KI list:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#
IsFrameLocking_assert
Confirmation from Valve would be appreciated that this is
correct with respect to the way the closed-source core works.
-bk
At 2006/08/30 09:02 PM, Jay Stelly wrote:
Since there are no explicit unlock operations on the studio
headers we
use a concept we call frame locking where they are guaranteed to
remain in memory (i.e. not get flushed for some other memory
allocation
request) as long as the frame is in scope. There's a macro for
generating these lock frames called:
MDLCACHE_CRITICAL_SECTION();
If you search, you'll see these frames declared at the top
of a bunch
of the systems (entity think, save/load, etc) So any studio headers
that are loaded in the scope of that can't be freed until
you exit that
scope. The assert is saying that you aren't within one of
those scopes
so theoretically your pointer could get freed if some other memory
request causes the cache to fill later on - so it's not safe
to hang on
to this pointer and still call memory management functions
in datacache.
It's easy enough to fix the assert by adding a frame using the macro
above to whatever entry point is causing you to page in the model.
Don't put one in GetModelPtr() however as that defeats the whole
purpose of this debug instrumentation.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aaron
Schiff
Sent: Wednesday, August 30, 2006 5:47 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] AssertOnce(
pModelCache-IsFrameLocking() );
--
[ Picked text/plain from multipart/alternative ] More like
a problem
with the calls we make to them. It seems to only show up when
initially showing a model...
On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote:
--
[ Picked text/plain from multipart/alternative ] Im also
wondering
what
Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
--
[ Picked text/plain from multipart/alternative ]
Any documentation would be nice.. I haven't seen many so far, except the
fixme!-comments
But well.. Every programmer hates to write documentation...
On 9/4/06, Nick [EMAIL PROTECTED] wrote:
I agree more documentation of the closed source API's would be nice.
On 9/3/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
There's already a MDLCACHE_CRITICAL_SECTION(); in
C_BaseEntity::PostDataUpdate that should take care of that one. Post a
stack trace if you're certain you haven't regressed that one.
At 2006/09/03 02:21 PM, Robbie Groenewoudt wrote:
--
[ Picked text/plain from multipart/alternative ]
My first crash with this:
void C_HL2MP_Player::Initialize( void )
{
m_headYawPoseParam = LookupPoseParameter( head_yaw );
GetPoseParameterRange( m_headYawPoseParam, m_headYawMin,
m_headYawMax );
m_headPitchPoseParam = LookupPoseParameter( head_pitch );
GetPoseParameterRange( m_headPitchPoseParam, m_headPitchMin,
m_headPitchMax );
CStudioHdr *hdr = GetModelPtr();
for ( int i = 0; i hdr-GetNumPoseParameters() ; i++ )
On 9/3/06, [EMAIL PROTECTED]
[EMAIL PROTECTED]
wrote:
New patch available:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#IsFrameLocking_assert
Since the scopes were moved higher, it's a little harder to say that
the
patch is airtight. But it fixes everything trivially encountered by
just
loading up HL2DM and moving around a bit.
At 2006/09/02 06:06 PM, [EMAIL PROTECTED] wrote:
Thanks, I'm going to assume this means that FrameLocking is an
expensive
operation and would cause noticeable slow-down machines if done too
frequently. I haven't noticed any problems, but I'll develop another
patch
with the locks up higher in the stack.
It sure would be nice to document this API, since modders can't read
the
closed-source code.
So my comment in the wiki is correct though that all of those spots
represent potential crashers?
-bk
At 2006/09/02 05:40 PM, Jay Stelly wrote:
No, we just rely on virtual memory for that. This is for when you
hit
the cache ceiling (which is usually 256MB depending on the physical
ram
on the machine). Obviously on consoles it's lower given the usual
memory configurations there (which isn't relevant to any of you
guys,
but is to us).
Also, I would definitely NOT recommend the code changes you posted
on
the wiki. That will cause way too much overhead to protect against
a
pointer dangling. The scope frames should be at a much higher
level.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 12:17 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking()
);
So if the box is low on ram, the HL2 core will memory it's
not actively using right that moment? I think I now
understand what the issue is, although I'm confused by the
use of scope locking for something like this.
In any case I've added MDLCACHE_CRITICAL_SECTION per Jay's
instruction, and the result is several dozen fixes, added to
the KI list:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#
IsFrameLocking_assert
Confirmation from Valve would be appreciated that this is
correct with respect to the way the closed-source core works.
-bk
At 2006/08/30 09:02 PM, Jay Stelly wrote:
Since there are no explicit unlock operations on the studio
headers we
use a concept we call frame locking where they are guaranteed
to
remain in memory (i.e. not get flushed for some other memory
allocation
request) as long as the frame is in scope. There's a macro for
generating these lock frames called:
MDLCACHE_CRITICAL_SECTION();
If you search, you'll see these frames declared at the top
of a bunch
of the systems (entity think, save/load, etc) So any studio
headers
that are loaded in the scope of that can't be freed until
you exit that
scope. The assert is saying that you aren't within one of
those scopes
so theoretically your pointer could get freed if some other
memory
request causes the cache to fill later on - so it's not safe
to hang on
to this pointer and still call memory management functions
in datacache.
It's easy enough to fix the assert by adding a frame using the
macro
above to whatever entry point is causing you to page in the
model.
Don't put one in GetModelPtr() however as that defeats the whole
purpose of this debug instrumentation.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Aaron
Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
--
[ Picked text/plain from multipart/alternative ]
My first crash with this:
void C_HL2MP_Player::Initialize( void )
{
m_headYawPoseParam = LookupPoseParameter( head_yaw );
GetPoseParameterRange( m_headYawPoseParam, m_headYawMin, m_headYawMax );
m_headPitchPoseParam = LookupPoseParameter( head_pitch );
GetPoseParameterRange( m_headPitchPoseParam, m_headPitchMin,
m_headPitchMax );
CStudioHdr *hdr = GetModelPtr();
for ( int i = 0; i hdr-GetNumPoseParameters() ; i++ )
On 9/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
New patch available:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#IsFrameLocking_assert
Since the scopes were moved higher, it's a little harder to say that the
patch is airtight. But it fixes everything trivially encountered by just
loading up HL2DM and moving around a bit.
At 2006/09/02 06:06 PM, [EMAIL PROTECTED] wrote:
Thanks, I'm going to assume this means that FrameLocking is an expensive
operation and would cause noticeable slow-down machines if done too
frequently. I haven't noticed any problems, but I'll develop another patch
with the locks up higher in the stack.
It sure would be nice to document this API, since modders can't read the
closed-source code.
So my comment in the wiki is correct though that all of those spots
represent potential crashers?
-bk
At 2006/09/02 05:40 PM, Jay Stelly wrote:
No, we just rely on virtual memory for that. This is for when you hit
the cache ceiling (which is usually 256MB depending on the physical ram
on the machine). Obviously on consoles it's lower given the usual
memory configurations there (which isn't relevant to any of you guys,
but is to us).
Also, I would definitely NOT recommend the code changes you posted on
the wiki. That will cause way too much overhead to protect against a
pointer dangling. The scope frames should be at a much higher level.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 12:17 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
So if the box is low on ram, the HL2 core will memory it's
not actively using right that moment? I think I now
understand what the issue is, although I'm confused by the
use of scope locking for something like this.
In any case I've added MDLCACHE_CRITICAL_SECTION per Jay's
instruction, and the result is several dozen fixes, added to
the KI list:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#
IsFrameLocking_assert
Confirmation from Valve would be appreciated that this is
correct with respect to the way the closed-source core works.
-bk
At 2006/08/30 09:02 PM, Jay Stelly wrote:
Since there are no explicit unlock operations on the studio
headers we
use a concept we call frame locking where they are guaranteed to
remain in memory (i.e. not get flushed for some other memory
allocation
request) as long as the frame is in scope. There's a macro for
generating these lock frames called:
MDLCACHE_CRITICAL_SECTION();
If you search, you'll see these frames declared at the top
of a bunch
of the systems (entity think, save/load, etc) So any studio headers
that are loaded in the scope of that can't be freed until
you exit that
scope. The assert is saying that you aren't within one of
those scopes
so theoretically your pointer could get freed if some other memory
request causes the cache to fill later on - so it's not safe
to hang on
to this pointer and still call memory management functions
in datacache.
It's easy enough to fix the assert by adding a frame using the macro
above to whatever entry point is causing you to page in the model.
Don't put one in GetModelPtr() however as that defeats the whole
purpose of this debug instrumentation.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aaron
Schiff
Sent: Wednesday, August 30, 2006 5:47 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] AssertOnce(
pModelCache-IsFrameLocking() );
--
[ Picked text/plain from multipart/alternative ] More like
a problem
with the calls we make to them. It seems to only show up when
initially showing a model...
On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote:
--
[ Picked text/plain from multipart/alternative ] Im also
wondering
what this is, IsFrameLocking()... Possible problem with
our models?
On 8/26/06, [EMAIL PROTECTED]
[EMAIL PROTECTED]
wrote:
AssertOnce( pModelCache-IsFrameLocking() );
This assert is always hit, both server-side
baseanimating.cpp(2352)
and client-side c_baseanimating.cpp(931) when a player joins a
server. The purpose
Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
There's already a MDLCACHE_CRITICAL_SECTION(); in C_BaseEntity::PostDataUpdate
that should take care of that one. Post a stack trace if you're certain you
haven't regressed that one.
At 2006/09/03 02:21 PM, Robbie Groenewoudt wrote:
--
[ Picked text/plain from multipart/alternative ]
My first crash with this:
void C_HL2MP_Player::Initialize( void )
{
m_headYawPoseParam = LookupPoseParameter( head_yaw );
GetPoseParameterRange( m_headYawPoseParam, m_headYawMin, m_headYawMax );
m_headPitchPoseParam = LookupPoseParameter( head_pitch );
GetPoseParameterRange( m_headPitchPoseParam, m_headPitchMin,
m_headPitchMax );
CStudioHdr *hdr = GetModelPtr();
for ( int i = 0; i hdr-GetNumPoseParameters() ; i++ )
On 9/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
New patch available:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#IsFrameLocking_assert
Since the scopes were moved higher, it's a little harder to say that the
patch is airtight. But it fixes everything trivially encountered by just
loading up HL2DM and moving around a bit.
At 2006/09/02 06:06 PM, [EMAIL PROTECTED] wrote:
Thanks, I'm going to assume this means that FrameLocking is an expensive
operation and would cause noticeable slow-down machines if done too
frequently. I haven't noticed any problems, but I'll develop another patch
with the locks up higher in the stack.
It sure would be nice to document this API, since modders can't read the
closed-source code.
So my comment in the wiki is correct though that all of those spots
represent potential crashers?
-bk
At 2006/09/02 05:40 PM, Jay Stelly wrote:
No, we just rely on virtual memory for that. This is for when you hit
the cache ceiling (which is usually 256MB depending on the physical ram
on the machine). Obviously on consoles it's lower given the usual
memory configurations there (which isn't relevant to any of you guys,
but is to us).
Also, I would definitely NOT recommend the code changes you posted on
the wiki. That will cause way too much overhead to protect against a
pointer dangling. The scope frames should be at a much higher level.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Saturday, September 02, 2006 12:17 PM
To: hlcoders@list.valvesoftware.com
Subject: RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
So if the box is low on ram, the HL2 core will memory it's
not actively using right that moment? I think I now
understand what the issue is, although I'm confused by the
use of scope locking for something like this.
In any case I've added MDLCACHE_CRITICAL_SECTION per Jay's
instruction, and the result is several dozen fixes, added to
the KI list:
http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#
IsFrameLocking_assert
Confirmation from Valve would be appreciated that this is
correct with respect to the way the closed-source core works.
-bk
At 2006/08/30 09:02 PM, Jay Stelly wrote:
Since there are no explicit unlock operations on the studio
headers we
use a concept we call frame locking where they are guaranteed to
remain in memory (i.e. not get flushed for some other memory
allocation
request) as long as the frame is in scope. There's a macro for
generating these lock frames called:
MDLCACHE_CRITICAL_SECTION();
If you search, you'll see these frames declared at the top
of a bunch
of the systems (entity think, save/load, etc) So any studio headers
that are loaded in the scope of that can't be freed until
you exit that
scope. The assert is saying that you aren't within one of
those scopes
so theoretically your pointer could get freed if some other memory
request causes the cache to fill later on - so it's not safe
to hang on
to this pointer and still call memory management functions
in datacache.
It's easy enough to fix the assert by adding a frame using the macro
above to whatever entry point is causing you to page in the model.
Don't put one in GetModelPtr() however as that defeats the whole
purpose of this debug instrumentation.
Jay
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aaron
Schiff
Sent: Wednesday, August 30, 2006 5:47 PM
To: hlcoders@list.valvesoftware.com
Subject: Re: [hlcoders] AssertOnce(
pModelCache-IsFrameLocking() );
--
[ Picked text/plain from multipart/alternative ] More like
a problem
with the calls we make to them. It seems to only show up when
initially showing a model...
On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote:
--
[ Picked text/plain from multipart/alternative ] Im also
wondering
what this is, IsFrameLocking()... Possible problem with
our models?
On 8/26/06, [EMAIL PROTECTED]
[EMAIL PROTECTED]
wrote
RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
So if the box is low on ram, the HL2 core will memory it's not actively using right that moment? I think I now understand what the issue is, although I'm confused by the use of scope locking for something like this. In any case I've added MDLCACHE_CRITICAL_SECTION per Jay's instruction, and the result is several dozen fixes, added to the KI list: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#IsFrameLocking_assert Confirmation from Valve would be appreciated that this is correct with respect to the way the closed-source core works. -bk At 2006/08/30 09:02 PM, Jay Stelly wrote: Since there are no explicit unlock operations on the studio headers we use a concept we call frame locking where they are guaranteed to remain in memory (i.e. not get flushed for some other memory allocation request) as long as the frame is in scope. There's a macro for generating these lock frames called: MDLCACHE_CRITICAL_SECTION(); If you search, you'll see these frames declared at the top of a bunch of the systems (entity think, save/load, etc) So any studio headers that are loaded in the scope of that can't be freed until you exit that scope. The assert is saying that you aren't within one of those scopes so theoretically your pointer could get freed if some other memory request causes the cache to fill later on - so it's not safe to hang on to this pointer and still call memory management functions in datacache. It's easy enough to fix the assert by adding a frame using the macro above to whatever entry point is causing you to page in the model. Don't put one in GetModelPtr() however as that defeats the whole purpose of this debug instrumentation. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Schiff Sent: Wednesday, August 30, 2006 5:47 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); -- [ Picked text/plain from multipart/alternative ] More like a problem with the calls we make to them. It seems to only show up when initially showing a model... On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Im also wondering what this is, IsFrameLocking()... Possible problem with our models? On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: AssertOnce( pModelCache-IsFrameLocking() ); This assert is always hit, both server-side baseanimating.cpp(2352) and client-side c_baseanimating.cpp(931) when a player joins a server. The purpose of this assert is unclear. Unfortunately the function it is asserting is closed-source with no documentation on its purpose either. I've added a KI recommending commenting it out for now. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
No, we just rely on virtual memory for that. This is for when you hit the cache ceiling (which is usually 256MB depending on the physical ram on the machine). Obviously on consoles it's lower given the usual memory configurations there (which isn't relevant to any of you guys, but is to us). Also, I would definitely NOT recommend the code changes you posted on the wiki. That will cause way too much overhead to protect against a pointer dangling. The scope frames should be at a much higher level. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, September 02, 2006 12:17 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); So if the box is low on ram, the HL2 core will memory it's not actively using right that moment? I think I now understand what the issue is, although I'm confused by the use of scope locking for something like this. In any case I've added MDLCACHE_CRITICAL_SECTION per Jay's instruction, and the result is several dozen fixes, added to the KI list: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List# IsFrameLocking_assert Confirmation from Valve would be appreciated that this is correct with respect to the way the closed-source core works. -bk At 2006/08/30 09:02 PM, Jay Stelly wrote: Since there are no explicit unlock operations on the studio headers we use a concept we call frame locking where they are guaranteed to remain in memory (i.e. not get flushed for some other memory allocation request) as long as the frame is in scope. There's a macro for generating these lock frames called: MDLCACHE_CRITICAL_SECTION(); If you search, you'll see these frames declared at the top of a bunch of the systems (entity think, save/load, etc) So any studio headers that are loaded in the scope of that can't be freed until you exit that scope. The assert is saying that you aren't within one of those scopes so theoretically your pointer could get freed if some other memory request causes the cache to fill later on - so it's not safe to hang on to this pointer and still call memory management functions in datacache. It's easy enough to fix the assert by adding a frame using the macro above to whatever entry point is causing you to page in the model. Don't put one in GetModelPtr() however as that defeats the whole purpose of this debug instrumentation. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Schiff Sent: Wednesday, August 30, 2006 5:47 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); -- [ Picked text/plain from multipart/alternative ] More like a problem with the calls we make to them. It seems to only show up when initially showing a model... On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Im also wondering what this is, IsFrameLocking()... Possible problem with our models? On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: AssertOnce( pModelCache-IsFrameLocking() ); This assert is always hit, both server-side baseanimating.cpp(2352) and client-side c_baseanimating.cpp(931) when a player joins a server. The purpose of this assert is unclear. Unfortunately the function it is asserting is closed-source with no documentation on its purpose either. I've added a KI recommending commenting it out for now. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
Thanks, I'm going to assume this means that FrameLocking is an expensive operation and would cause noticeable slow-down machines if done too frequently. I haven't noticed any problems, but I'll develop another patch with the locks up higher in the stack. It sure would be nice to document this API, since modders can't read the closed-source code. So my comment in the wiki is correct though that all of those spots represent potential crashers? -bk At 2006/09/02 05:40 PM, Jay Stelly wrote: No, we just rely on virtual memory for that. This is for when you hit the cache ceiling (which is usually 256MB depending on the physical ram on the machine). Obviously on consoles it's lower given the usual memory configurations there (which isn't relevant to any of you guys, but is to us). Also, I would definitely NOT recommend the code changes you posted on the wiki. That will cause way too much overhead to protect against a pointer dangling. The scope frames should be at a much higher level. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, September 02, 2006 12:17 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); So if the box is low on ram, the HL2 core will memory it's not actively using right that moment? I think I now understand what the issue is, although I'm confused by the use of scope locking for something like this. In any case I've added MDLCACHE_CRITICAL_SECTION per Jay's instruction, and the result is several dozen fixes, added to the KI list: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List# IsFrameLocking_assert Confirmation from Valve would be appreciated that this is correct with respect to the way the closed-source core works. -bk At 2006/08/30 09:02 PM, Jay Stelly wrote: Since there are no explicit unlock operations on the studio headers we use a concept we call frame locking where they are guaranteed to remain in memory (i.e. not get flushed for some other memory allocation request) as long as the frame is in scope. There's a macro for generating these lock frames called: MDLCACHE_CRITICAL_SECTION(); If you search, you'll see these frames declared at the top of a bunch of the systems (entity think, save/load, etc) So any studio headers that are loaded in the scope of that can't be freed until you exit that scope. The assert is saying that you aren't within one of those scopes so theoretically your pointer could get freed if some other memory request causes the cache to fill later on - so it's not safe to hang on to this pointer and still call memory management functions in datacache. It's easy enough to fix the assert by adding a frame using the macro above to whatever entry point is causing you to page in the model. Don't put one in GetModelPtr() however as that defeats the whole purpose of this debug instrumentation. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Schiff Sent: Wednesday, August 30, 2006 5:47 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); -- [ Picked text/plain from multipart/alternative ] More like a problem with the calls we make to them. It seems to only show up when initially showing a model... On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Im also wondering what this is, IsFrameLocking()... Possible problem with our models? On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: AssertOnce( pModelCache-IsFrameLocking() ); This assert is always hit, both server-side baseanimating.cpp(2352) and client-side c_baseanimating.cpp(931) when a player joins a server. The purpose of this assert is unclear. Unfortunately the function it is asserting is closed-source with no documentation on its purpose either. I've added a KI recommending commenting it out for now. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
New patch available: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List#IsFrameLocking_assert Since the scopes were moved higher, it's a little harder to say that the patch is airtight. But it fixes everything trivially encountered by just loading up HL2DM and moving around a bit. At 2006/09/02 06:06 PM, [EMAIL PROTECTED] wrote: Thanks, I'm going to assume this means that FrameLocking is an expensive operation and would cause noticeable slow-down machines if done too frequently. I haven't noticed any problems, but I'll develop another patch with the locks up higher in the stack. It sure would be nice to document this API, since modders can't read the closed-source code. So my comment in the wiki is correct though that all of those spots represent potential crashers? -bk At 2006/09/02 05:40 PM, Jay Stelly wrote: No, we just rely on virtual memory for that. This is for when you hit the cache ceiling (which is usually 256MB depending on the physical ram on the machine). Obviously on consoles it's lower given the usual memory configurations there (which isn't relevant to any of you guys, but is to us). Also, I would definitely NOT recommend the code changes you posted on the wiki. That will cause way too much overhead to protect against a pointer dangling. The scope frames should be at a much higher level. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, September 02, 2006 12:17 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); So if the box is low on ram, the HL2 core will memory it's not actively using right that moment? I think I now understand what the issue is, although I'm confused by the use of scope locking for something like this. In any case I've added MDLCACHE_CRITICAL_SECTION per Jay's instruction, and the result is several dozen fixes, added to the KI list: http://developer.valvesoftware.com/wiki/SDK_Known_Issues_List# IsFrameLocking_assert Confirmation from Valve would be appreciated that this is correct with respect to the way the closed-source core works. -bk At 2006/08/30 09:02 PM, Jay Stelly wrote: Since there are no explicit unlock operations on the studio headers we use a concept we call frame locking where they are guaranteed to remain in memory (i.e. not get flushed for some other memory allocation request) as long as the frame is in scope. There's a macro for generating these lock frames called: MDLCACHE_CRITICAL_SECTION(); If you search, you'll see these frames declared at the top of a bunch of the systems (entity think, save/load, etc) So any studio headers that are loaded in the scope of that can't be freed until you exit that scope. The assert is saying that you aren't within one of those scopes so theoretically your pointer could get freed if some other memory request causes the cache to fill later on - so it's not safe to hang on to this pointer and still call memory management functions in datacache. It's easy enough to fix the assert by adding a frame using the macro above to whatever entry point is causing you to page in the model. Don't put one in GetModelPtr() however as that defeats the whole purpose of this debug instrumentation. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Schiff Sent: Wednesday, August 30, 2006 5:47 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); -- [ Picked text/plain from multipart/alternative ] More like a problem with the calls we make to them. It seems to only show up when initially showing a model... On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Im also wondering what this is, IsFrameLocking()... Possible problem with our models? On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: AssertOnce( pModelCache-IsFrameLocking() ); This assert is always hit, both server-side baseanimating.cpp(2352) and client-side c_baseanimating.cpp(931) when a player joins a server. The purpose of this assert is unclear. Unfortunately the function it is asserting is closed-source with no documentation on its purpose either. I've added a KI recommending commenting it out for now. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences
Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
-- [ Picked text/plain from multipart/alternative ] Im also wondering what this is, IsFrameLocking()... Possible problem with our models? On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: AssertOnce( pModelCache-IsFrameLocking() ); This assert is always hit, both server-side baseanimating.cpp(2352) and client-side c_baseanimating.cpp(931) when a player joins a server. The purpose of this assert is unclear. Unfortunately the function it is asserting is closed-source with no documentation on its purpose either. I've added a KI recommending commenting it out for now. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ~skidz -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
-- [ Picked text/plain from multipart/alternative ] More like a problem with the calls we make to them. It seems to only show up when initially showing a model... On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Im also wondering what this is, IsFrameLocking()... Possible problem with our models? On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: AssertOnce( pModelCache-IsFrameLocking() ); This assert is always hit, both server-side baseanimating.cpp(2352) and client-side c_baseanimating.cpp(931) when a player joins a server. The purpose of this assert is unclear. Unfortunately the function it is asserting is closed-source with no documentation on its purpose either. I've added a KI recommending commenting it out for now. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ~skidz -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() );
Since there are no explicit unlock operations on the studio headers we use a concept we call frame locking where they are guaranteed to remain in memory (i.e. not get flushed for some other memory allocation request) as long as the frame is in scope. There's a macro for generating these lock frames called: MDLCACHE_CRITICAL_SECTION(); If you search, you'll see these frames declared at the top of a bunch of the systems (entity think, save/load, etc) So any studio headers that are loaded in the scope of that can't be freed until you exit that scope. The assert is saying that you aren't within one of those scopes so theoretically your pointer could get freed if some other memory request causes the cache to fill later on - so it's not safe to hang on to this pointer and still call memory management functions in datacache. It's easy enough to fix the assert by adding a frame using the macro above to whatever entry point is causing you to page in the model. Don't put one in GetModelPtr() however as that defeats the whole purpose of this debug instrumentation. Jay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Schiff Sent: Wednesday, August 30, 2006 5:47 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] AssertOnce( pModelCache-IsFrameLocking() ); -- [ Picked text/plain from multipart/alternative ] More like a problem with the calls we make to them. It seems to only show up when initially showing a model... On 8/30/06, Ryan Sheffer [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Im also wondering what this is, IsFrameLocking()... Possible problem with our models? On 8/26/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: AssertOnce( pModelCache-IsFrameLocking() ); This assert is always hit, both server-side baseanimating.cpp(2352) and client-side c_baseanimating.cpp(931) when a player joins a server. The purpose of this assert is unclear. Unfortunately the function it is asserting is closed-source with no documentation on its purpose either. I've added a KI recommending commenting it out for now. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ~skidz -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ts2do -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
